Re: [mtd/sbc_gxx] kernel BUG at include/linux/mtd/map.h:148!
Hi Michal,
Your patch fixes the problem.
Tested-by: Jet Chen
Thanks,
-Jet
On 03/31/2014 10:35 PM, Michal Marek wrote:
On Mon, Mar 31, 2014 at 07:34:12PM +0800, Fengguang Wu wrote:
CC Michal and kbuild list.
On Thu, Mar 27, 2014 at 04:51:53PM -0600, Bjorn Helgaas wrote:
[+cc David, Brian]
On Thu, Mar 27, 2014 at 8:01 AM, Fengguang Wu wrote:
FYI, here is a very old warning, too old to be bisected.
[5.282127] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled,
supports DPO and FUA
[5.286079] SBC-GXx flash: IO:0x258-0x259 MEM:0xdc000-0xd
[5.288723] [ cut here ]
[5.289649] kernel BUG at include/linux/mtd/map.h:148!
I think the problem is that your randconfig happens to have none of
CONFIG_MTD_MAP_BANK_WIDTH_* set (you should have played the lottery
today!), and the default implementation of map_bankwidth() in that
case is just "BUG()":
$ grep MTD_MAP config-3.14.0-rc8-wl-03045-gdf16ea4
# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_2 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
I don't know enough Kconfig or MTD to fix this.
Michal, the problem we run into is, how to select one of the above
CONFIG_MTD_MAP_BANK_WIDTH_xx in "make randconfig".
You can't enforce this in Kconfig. What you can do is to make the logic
more fool-proof and fall back to some sensible default if none of the
CONFIG_MTD_MAP_BANK_WIDTH_* options is enabled. Like this
From 76e66ceea7e2ffbb1d39c01af2eaf6f2b66c2be3 Mon Sep 17 00:00:00 2001
From: Michal Marek
Date: Mon, 31 Mar 2014 16:25:32 +0200
Subject: [PATCH] mtd: Fall back to MTD_MAP_BANK_WIDTH_1 if none is specified
This is mainly to fix make randconfig errors.
Signed-off-by: Michal Marek
---
drivers/mtd/chips/Kconfig | 8
include/linux/mtd/map.h | 4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig
index e4696b3..219de49 100644
--- a/drivers/mtd/chips/Kconfig
+++ b/drivers/mtd/chips/Kconfig
@@ -115,6 +115,14 @@ config MTD_MAP_BANK_WIDTH_32
If you wish to support CFI devices on a physical bus which is
256 bits wide, say 'Y'.
+config HAVE_MTD_MAP_BANK_WIDTH_1
+ bool
+ default MTD_MAP_BANK_WIDTH_1 || (!MTD_MAP_BANK_WIDTH_2 && !MTD_MAP_BANK_WIDTH_4 &&
!MTD_MAP_BANK_WIDTH_8 && !MTD_MAP_BANK_WIDTH_16 && !MTD_MAP_BANK_WIDTH_32)
+
+if HAVE_MTD_MAP_BANK_WIDTH_1 && !MTD_MAP_BANK_WIDTH_1
+comment "no buswidth selected, using 8-bit as a fallback "
+endif
+
config MTD_CFI_I1
bool "Support 1-chip flash interleave" if MTD_CFI_GEOMETRY
default y
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 5f487d7..d4f4f49 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -32,7 +32,7 @@
#include
#include
-#ifdef CONFIG_MTD_MAP_BANK_WIDTH_1
+#ifdef CONFIG_HAVE_MTD_MAP_BANK_WIDTH_1
#define map_bankwidth(map) 1
#define map_bankwidth_is_1(map) (map_bankwidth(map) == 1)
#define map_bankwidth_is_large(map) (0)
@@ -156,7 +156,7 @@ static inline int map_bankwidth(void *map)
static inline int map_bankwidth_supported(int w)
{
switch (w) {
-#ifdef CONFIG_MTD_MAP_BANK_WIDTH_1
+#ifdef CONFIG_HAVE_MTD_MAP_BANK_WIDTH_1
case 1:
#endif
#ifdef CONFIG_MTD_MAP_BANK_WIDTH_2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic
Hi, Claudiu Please help to review this patch. This patch is for kernel 2.6.x. Thanks a lot. Hi, Willy Please help to merge this patch to longterm: 2.6.32.61 since this problem also occurs on this kernel. Thanks a lot. Based on kernel 2.6.x, gianfar nic driver can not work well. The root cause is that tx vlan of gianfar can not handle VLAN tag 0. So on kernel 3.0+, this tx vlan feature is disabled. But on kernel 2.6.x, this feature is still enabled. This patch will disable this feature of gianfar nic driver. If this feature is enabled, gianfar nic can not support vlan packets and non-vlan packets at the same time. The following steps will reproduce this problem. The steps are as below. 1. boot two freescale-p2020 boards with linux kernel 2.6.x, then connected 2 gfar-enet nic cards with a direct network line; 2. On board 1, checked the driver of eth0 ethtool -i eth0 driver: gfar-enet version: 1.3 firmware-version: N/A bus-info: N/A On board 2, I checked the driver of eth1 ethtool -i eth1 driver: gfar-enet version: 1.3 firmware-version: N/A bus-info: N/A 3. Then configure the ip address on the above 2 nic cards. On board 1, ifconfig eth0 192.168.1.13/24 up On board 2, ifconfig eth1 192.168.1.196/24 up 4. We can access the other board on one board. For example, on board 1, we can ping board 2. root@p2020rdb:/root> ping 192.168.1.196 PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data. 64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms 64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms 5. We configure vlan on these 2 boards. VLAN tag 0 On board 1, modprobe 8021q vconfig add eth0 4091 ifconfig eth0.4091 10.1.1.13/24 up On board 2, modprobe 8021q vconfig add eth1 4091 ifconfig eth1.4091 10.1.1.196/24 up 6. We can access the other board on one board through vlan. For example, on board 1, we can ping board 2 through vlan nic. root@p2020rdb:/root> ping 10.1.1.196 PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data. 64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms 64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms But we can not access the other board on one board through raw nic. For example, on board, we can not ping board 2. root@p2020rdb:/root> ping 192.168.1.196 From 192.168.1.196 icmp_seq=1 Destination Host Unreachable From 192.168.1.196 icmp_seq=2 Destination Host Unreachable From 192.168.1.196 icmp_seq=3 Destination Host Unreachable Best Regards! Zhu Yanjun On 03/25/2014 01:08 PM, zhuyj wrote: Hi, Sandeep Gopalpet I am a developer. Now I confronted an interesting phenomena. When I used linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw and vlan packets on gfar-enet nic. But with e1000e nic, we can make vlan and raw packets work well. I looked into the source code and find that maybe it is related with hardware insert and remove vlan head. But I have no the specifications of gfar-enet nic. Would you like to give some document or some guides? Thanks a lot. Zhu Yanjun The steps are as below. 1. I boot two freescale-p2020 boards with linux kernel 2.6.34.15, then I connected 2 gfar-enet nic cards with a direct network line; 2. On board 1, I checked the driver of eth0 ethtool -i eth0 driver: gfar-enet version: 1.3 firmware-version: N/A bus-info: N/A On board 2, I checked the driver of eth1 ethtool -i eth1 driver: gfar-enet version: 1.3 firmware-version: N/A bus-info: N/A 3. Then I configure the ip address on the above 2 nic cards. On board 1, ifconfig eth0 192.168.1.13/24 up On board 2, ifconfig eth1 192.168.1.196/24 up 4. We can access the other board on one board. For example, on board 1, we can ping board 2. root@p2020rdb:/root> ping 192.168.1.196 PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data. 64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms 64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms 5. We configure vlan on these 2 boards. VLAN tag 0 On board 1, modprobe 8021q vconfig add eth0 4091 ifconfig eth0.4091 10.1.1.13/24 up On board 2, modprobe 8021q vconfig add eth1 4091 ifconfig eth1.4091 10.1.1.196/24 up 6. We can access the other board on one board through vlan. For example, on board 1, we can ping board 2 through vlan nic. root@p2020rdb:/root> ping 10.1.1.196 PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data. 64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms 64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms But we can not access the other board on one board through raw nic. For example, on board, we can not ping board 2. root@p2020rdb:/root> ping 192.168.1.196 From 192.168.1.196 icmp_seq=1 Destination Host Unreachable From 192.168.1.196 icmp_seq=2 Destination Host Unreachable From 192.168.1.196 icmp_seq=3 Destination Host Unreachable >From afd48fa3ad5b15d519adeb19b2a9c00051327c68 Mon Sep 17 00:00:00 2001 From: Zhu Yanjun Date: Thu, 3 Apr 2014 16:41:13 +0800 Subject: [PATCH 1/1] gianfar: disable TX vlan based on kernel 2.6.x Since
Re: [PATCH net-next v3 2/2] xen-netback: Grant copy the header instead of map and memcpy
On Thu, 2014-04-03 at 09:07 +0100, Paul Durrant wrote: > > -Original Message- > > From: Zoltan Kiss > > Sent: 02 April 2014 18:05 > > To: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org > > Cc: Paul Durrant; net...@vger.kernel.org; linux-kernel@vger.kernel.org; > > Jonathan Davies; Zoltan Kiss > > Subject: [PATCH net-next v3 2/2] xen-netback: Grant copy the header > > instead of map and memcpy > > > > An old inefficiency of the TX path that we are grant mapping the first slot, > > and then copy the header part to the linear area. Instead, doing a grant > > copy > > for that header straight on is more reasonable. Especially because there are > > ongoing efforts to make Xen avoiding TLB flush after unmap when the page > > were > > not touched in Dom0. In the original way the memcpy ruined that. > > The key changes: > > - the vif has a tx_copy_ops array again > > - xenvif_tx_build_gops sets up the grant copy operations > > - we don't have to figure out whether the header and first frag are on the > > same > > grant mapped page or not > > Note, we only grant copy PKT_PROT_LEN bytes from the first slot, the rest > > (if > > any) will be on the first frag, which is grant mapped. If the first slot is > > smaller than PKT_PROT_LEN, then we grant copy that, and later > > __pskb_pull_tail > > will pull more from the frags (if any) > > > > Signed-off-by: Zoltan Kiss > > Looks good to me. > > Reviewed-by: Paul Durrant Me too: Acked-by: Ian Campbell -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] MIPS: Loongson: No need to select GENERIC_HARDIRQS_NO__DO_IRQ
Commit 0e476d91244e ("MIPS: Loongson: Add Loongson-3 Kconfig options")
added "select GENERIC_HARDIRQS_NO__DO_IRQ". But the Kconfig symbol
GENERIC_HARDIRQS_NO__DO_IRQ was already removed in v2.6.38, so that
select is a nop. Drop it.
Signed-off-by: Paul Bolle
---
Tested with git grep only.
arch/mips/loongson/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/loongson/Kconfig b/arch/mips/loongson/Kconfig
index 7397be2..603d79a 100644
--- a/arch/mips/loongson/Kconfig
+++ b/arch/mips/loongson/Kconfig
@@ -64,7 +64,6 @@ config LEMOTE_MACH3A
bool "Lemote Loongson 3A family machines"
select ARCH_SPARSEMEM_ENABLE
select GENERIC_ISA_DMA_SUPPORT_BROKEN
- select GENERIC_HARDIRQS_NO__DO_IRQ
select BOOT_ELF32
select BOARD_SCACHE
select CSRC_R4K
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/10] ARM: EXYNOS: Add support for mapping PMU base address via DT
On 02/04/14 14:15, Michal Simek wrote: >> There were some patches posted for syscon to make it available in earlier >> system initialization stage: https://lkml.org/lkml/2014/2/19/218 > > I haven't finished this yet. I have to look at it again. Thanks for the information, I assume this would be also useful on the Exynos SoC series, so I'd be happy to see continuation of those works. -- Thanks, 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/
Re: [PATCH] drivercore: deferral race condition fix
On Wed, Apr 02, 2014 at 04:18:57PM -0700, Greg Kroah-Hartman wrote: > On Wed, Apr 02, 2014 at 09:38:06AM +0300, Peter Ujfalusi wrote: > > Do you want me to resend this patch in hope that it is going to be taken or > > do > > you have other method in mind to deal with the situation I have described > > and > > fixed with this patch? > Can you resend, I've totally lost the idea of the original patch. And > if others agree with it, getting acks from them (like Grant) would be > great. Acked-by: Mark Brown FWIW. It's not the most elegant thing ever but then nor is deferred probing. signature.asc Description: Digital signature
Re: [PATCH net-next v3 1/2] xen-netback: Rename map ops
On Wed, 2014-04-02 at 18:04 +0100, Zoltan Kiss wrote: > Rename identifiers to state explicitly that they refer to map ops. > > Signed-off-by: Zoltan Kiss > --- > v3: > - rename xenvif_tx_create_gop to xenvif_tx_create_map_op You can retain my ack from v2. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers/staging/vt6655/iwctl.c fix a sparse warning
On Thu, Mar 27, 2014 at 08:28:44PM -0700, Jimmy Li wrote: > You are right, I found that variable buf also don't make sense here, > maybe this could be more clear. > > param = kzalloc(sizeof(struct viawget_wpa_param), GFP_KERNEL); > if (param == NULL) > return -ENOMEM; > > removing two unnecessary variable, buf and blen. > > In this situation, I should send a new patch v2 for it base on the > previous path? or send a new patch include all changes? We throw away the original patch and you send a v2. Use the subject: [PATCH v2] drivers/staging/vt6655/iwctl.c fix a sparse warning Under the Signed-off-by line put: Signed-off-by: you --- v2: additional cleanups as well. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: document the berlin enable-method property
On Thu, Apr 03, 2014 at 09:08:15AM +0100, Antoine Ténart wrote: > Signed-off-by: Antoine Ténart > --- > Documentation/devicetree/bindings/arm/cpus.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt > b/Documentation/devicetree/bindings/arm/cpus.txt > index 333f4aea3029..a9e42a2dbc99 100644 > --- a/Documentation/devicetree/bindings/arm/cpus.txt > +++ b/Documentation/devicetree/bindings/arm/cpus.txt > @@ -185,6 +185,8 @@ nodes to be present and contain the properties described > below. > "qcom,gcc-msm8660" > "qcom,kpss-acc-v1" > "qcom,kpss-acc-v2" > + "marvell,88de31-smp" - cpu-core handling for Berlin > + SoC from Marvell starting with 88de31 It would probably be best to add an enable-method directory and document what each of these mean (what's expected of the platform, what steps an OS should make to bring up and/or tear down CPUs). While it's nice to factor this out of the kernel, I'd like this to be better-defined such that it's clear what the expectations of each enable-method are. That ways it iss possible for OSs other than Linux to make use of the enable-method information (as it won't be an opaque reference to Linux internals), and we can have a clear definition of each enable-method independent of any implementation details. Going forward I would like to see fewer implementation-specific protocols for bringing up secondaries, and a move to fewer more standardised mechanisms like PSCI. I realise that might not be possible in all cases, but it would be nice to avoid a proliferation of enable-methods with single users. Cheers, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/5] tracing: Add 'hash' event trigger command
Hi Tom, (2014/03/27 13:54), Tom Zanussi wrote: > Hash triggers allow users to continually hash events which can then be > dumped later by simply reading the trigger file. This is done > strictly via one-liners and without any kind of programming language. > > The syntax follows the existing trigger syntax: > > # echo hash:key(s):value(s)[:sort_keys()][ if filter] > event/trigger > > The values used as keys and values are just the fields that define the > trace event and available in the event's 'format' file. For example, > the kmalloc event: > > root@ie:/sys/kernel/debug/tracing/events/kmem/kmalloc# cat format > name: kmalloc > ID: 370 > format: > field:unsigned short common_type; offset:0; size:2; > signed:0; > field:unsigned char common_flags; offset:2; size:1; > signed:0; > field:unsigned char common_preempt_count; offset:3; > size:1;signed:0; > field:int common_pid; offset:4; size:4; signed:1; > > field:unsigned long call_site; offset:8; size:4; signed:0; > field:const void * ptr; offset:12; size:4; signed:0; > field:size_t bytes_req; offset:16; size:4; signed:0; > field:size_t bytes_alloc; offset:20; size:4; signed:0; > field:gfp_t gfp_flags; offset:24; size:4; signed:0; > > The key can be made up of one or more of these fields and any number of > values can specified - these are automatically tallied in the hash entry > any time the event is hit. Stacktraces can also be used as keys. > > For example, the following uses the stacktrace leading up to a kmalloc > as the key for hashing kmalloc events. For each hash entry a tally of > the bytes_alloc field is kept. Dumping out the trigger shows the sum > of bytes allocated for each execution path that led to a kmalloc: > > # echo 'hash:call_site:bytes_alloc' > > /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger > # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger I like the basic idea :) but I'm confused the interface what you're introduced. I suppose that the "trigger" file is for control triggers on the event, so that user can check what trigger rules are set on the event and remove it. But in this patch, that is also used for a data path. I'd like to suggest adding new "hash" file under events/GROUP/EVENT/, which is only for dumping the hash data, and keep the "trigger" as a control path. This makes users easier to build their own tools on the ftrace facility. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology 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: [PATCH 1/1] AArch64: TCR_TG1_64K incorrectly sets TCR_EL1 bits [31:30]
On Wed, Apr 02, 2014 at 06:21:29PM +0100, Joe Sylve wrote: > That makes sense and I agree, it's better to fix it now so that it > will be easier to add 16K paging later (on a side note is there any > reason not to add it now if someone was willing to do the work?). See another thread with the Samsung folks about the adding 4-levels of page tables. We need a bit of refactoring first to decouple the page size from the number of levels, after that 16K would be relatively easy (it's easy now as well but I don't see the point on doing it before the refactoring). > There was talk in another thread about the possibility of adding a > pagetable-4K-hwdef.h and pagetable-64K-hwdef.h. I think this is > another example of why that might be a good idea as this stuff could > be moved out of proc.S as to be bit more clean: > > +#ifdef CONFIG_ARM64_64K_PAGES > +#define TCR_TG_FLAGS TCR_TG0_64K | TCR_TG1_64K > +#else > +#define TCR_TG_FLAGS TCR_TG0_4K | TCR_TG1_4K > +#endif Yes, we could do this when we create the pgtable-*k-hwdef.h files. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] mm/compaction: clean up unused code lines
This commit removes code lines currently not in use or never called.
Signed-off-by: Heesub Shin
Cc: Dongjun Shin
Cc: Sunghwan Yun
---
mm/compaction.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 9635083..1ef9144 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -208,12 +208,6 @@ static bool compact_checklock_irqsave(spinlock_t *lock,
unsigned long *flags,
return true;
}
-static inline bool compact_trylock_irqsave(spinlock_t *lock,
- unsigned long *flags, struct compact_control *cc)
-{
- return compact_checklock_irqsave(lock, flags, false, cc);
-}
-
/* Returns true if the page is within a block suitable for migration to */
static bool suitable_migration_target(struct page *page)
{
@@ -728,7 +722,6 @@ static void isolate_freepages(struct zone *zone,
continue;
/* Found a block suitable for isolating free pages from */
- isolated = 0;
/*
* As pfn may not start aligned, pfn+pageblock_nr_page
@@ -1160,9 +1153,6 @@ static void __compact_pgdat(pg_data_t *pgdat, struct
compact_control *cc)
if (zone_watermark_ok(zone, cc->order,
low_wmark_pages(zone), 0, 0))
compaction_defer_reset(zone, cc->order, false);
- /* Currently async compaction is never deferred. */
- else if (cc->sync)
- defer_compaction(zone, cc->order);
}
VM_BUG_ON(!list_empty(>freepages));
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] mm/compaction: fix to initialize free scanner properly
Free scanner does not works well on systems having zones which do not
span to pageblock-aligned boundary.
zone->compact_cached_free_pfn is reset when the migration and free
scanner across or compaction restarts. After the reset, if end_pfn of
the zone was not aligned to pageblock_nr_pages, free scanner tries to
isolate free pages from the middle of pageblock to the end, which can
be very small range.
Signed-off-by: Heesub Shin
Cc: Dongjun Shin
Cc: Sunghwan Yun
---
mm/compaction.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 1ef9144..fefe1da 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -983,7 +983,7 @@ static int compact_zone(struct zone *zone, struct
compact_control *cc)
*/
cc->migrate_pfn = zone->compact_cached_migrate_pfn;
cc->free_pfn = zone->compact_cached_free_pfn;
- if (cc->free_pfn < start_pfn || cc->free_pfn > end_pfn) {
+ if (cc->free_pfn < start_pfn || cc->free_pfn >= end_pfn) {
cc->free_pfn = end_pfn & ~(pageblock_nr_pages-1);
zone->compact_cached_free_pfn = cc->free_pfn;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: document the berlin enable-method property
Jisheng, On 03/04/2014 10:22, Jisheng Zhang wrote: Hi, On Thu, 3 Apr 2014 01:08:15 -0700 Antoine Ténart wrote: Signed-off-by: Antoine Ténart --- Documentation/devicetree/bindings/arm/cpus.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 333f4aea3029..a9e42a2dbc99 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@ nodes to be present and contain the properties described below. "qcom,gcc-msm8660" "qcom,kpss-acc-v1" "qcom,kpss-acc-v2" + "marvell,88de31-smp" - cpu-core handling for why not "marvell,berlin-smp"? We have SMP on the BG2 and the BG2Q currently. Future boards may not be compatible with this method (BG3 ?), I think "marvell,berlin-smp" is too generic. We could use "marvell,88de31xx-smp" as Alexandre suggested. Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 04/41] intel_idle: Fixed C6 state on Avoton/Rangeley processors
From: Bockholdt Arne
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 22e580d07f6529a395c129575127ea6d860aed3a upstream.
Corrected the MWAIT flag for C-State C6 on Intel Avoton/Rangeley processors.
Signed-off-by: Arne Bockholdt
Acked-by: Len Brown
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jiri Slaby
---
drivers/idle/intel_idle.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 000d370519d9..53235814ea0f 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -329,7 +329,7 @@ static struct cpuidle_state atom_cstates[CPUIDLE_STATE_MAX]
= {
{
.enter = NULL }
};
-static struct cpuidle_state avn_cstates[CPUIDLE_STATE_MAX] = {
+static struct cpuidle_state avn_cstates[] __initdata = {
{
.name = "C1-AVN",
.desc = "MWAIT 0x00",
@@ -340,7 +340,7 @@ static struct cpuidle_state avn_cstates[CPUIDLE_STATE_MAX]
= {
{
.name = "C6-AVN",
.desc = "MWAIT 0x51",
- .flags = MWAIT2flg(0x58) | CPUIDLE_FLAG_TIME_VALID |
CPUIDLE_FLAG_TLB_FLUSHED,
+ .flags = MWAIT2flg(0x51) | CPUIDLE_FLAG_TIME_VALID |
CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 15,
.target_residency = 45,
.enter = _idle },
--
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] arm64: Fix duplicated Kconfig entries again
On Thu, Apr 03, 2014 at 09:41:57AM +0100, Viresh Kumar wrote: > On Thu, Apr 3, 2014 at 2:05 PM, Hanjun Guo wrote: > > How about the following patch? if it is ok, I will resend it. > > http://www.spinics.net/lists/arm-kernel/msg319545.html I can see commit 62d1a3ba5adc5653d43f6cd3a90758bb6ad5d5bd (arm64: Fix duplicated Kconfig entries again) already in mainline, so problem solved. Thanks Josh ;) -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update
On 04/02/2014 08:59 AM, Michael wang wrote: > During the testing, we encounter below WARN followed by Oops: > > WARNING: at kernel/sched/core.c:6218 > ... > NIP [c0101660] .build_sched_domains+0x11d0/0x1200 > LR [c0101358] .build_sched_domains+0xec8/0x1200 > PACATMSCRATCH [8000f032] > Call Trace: > [c0001b103850] [c0101358] .build_sched_domains+0xec8/0x1200 > [c0001b1039a0] [c010aad4] > .partition_sched_domains+0x484/0x510 > [c0001b103aa0] [c016d0a8] .rebuild_sched_domains+0x68/0xa0 > [c0001b103b30] [c005cbf0] .topology_work_fn+0x10/0x30 > ... > Oops: Kernel access of bad area, sig: 11 [#1] > ... > NIP [c045c000] .__bitmap_weight+0x60/0xf0 > LR [c010132c] .build_sched_domains+0xe9c/0x1200 > PACATMSCRATCH [80029032] > Call Trace: > [c0001b1037a0] [c0288ff4] > .kmem_cache_alloc_node_trace+0x184/0x3a0 > [c0001b103850] [c010132c] .build_sched_domains+0xe9c/0x1200 > [c0001b1039a0] [c010aad4] > .partition_sched_domains+0x484/0x510 > [c0001b103aa0] [c016d0a8] .rebuild_sched_domains+0x68/0xa0 > [c0001b103b30] [c005cbf0] .topology_work_fn+0x10/0x30 > ... > > This was caused by that 'sd->groups == NULL' after building groups, which > was caused by the empty 'sd->span'. > > The cpu's domain contain nothing because the cpu was assigned to wrong > node inside arch_update_cpu_topology() by calling update_lookup_table() > with the uninitialized param, in the case when there is nothing to be > update. > I think we need to verify this theory. Here are my thoughts: If we get a topology update notification from the hypervisor, and then the update happens to be nothing new (as in, new_node == old_node for the given cpu), then updated_cpus mask will not have any cpus set in it (like you noted below). In that scenario, the following sequence will take place: Inside arch_cpu_update_topology(), the 'updates' has been kzalloc()'ed. So updates[0] will have all its fields set to 0, such as ->cpu, ->new_nid etc. When we invoke stop_machine() the first time like this: stop_machine(update_cpu_topology, [0], _cpus); stop-machine will notice that updated_cpus mask does not have any cpus set in it, so it will nominate cpumask_first(cpu_online_mask) to run the update_cpu_topology() function, which means that CPU0 will run it. So, when CPU0 runs update_cpu_topology(), it will find that cpu == update->cpu since both are 0, and will invoke unmap_cpu_from_node() and then calls map_cpu_to_node(), with update->new_nid == 0. Now, the interesting thing to note here is that, if CPU0's node was already set as node0, *nothing* should go wrong, since its just a redundant update. However, if CPU0's original node mapping was something different, or if node0 doesn't even exist in the machine, then the system can crash. Have you verified that CPU0's node mapping is different from node 0? That is, boot the kernel with "numa=debug" in the kernel command line and it will print out the cpu-to-node associativity during boot. That way you can figure out what was the original associativity that was set. This will confirm the theory that the hypervisor sent a redundant update, but because of the weird pre-allocation using kzalloc that we do inside arch_update_cpu_topology(), we wrongly updated CPU0's mapping as CPU0 <-> Node0. Regards, Srivatsa S. Bhat > Thus we should stop the updating in such cases, this patch will achieve > this and fix the issue. > > CC: Benjamin Herrenschmidt > CC: Paul Mackerras > CC: Nathan Fontenot > CC: Stephen Rothwell > CC: Andrew Morton > CC: Robert Jennings > CC: Jesse Larrew > CC: "Srivatsa S. Bhat" > CC: Alistair Popple > Signed-off-by: Michael Wang > --- > arch/powerpc/mm/numa.c |9 + > 1 file changed, 9 insertions(+) > > diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c > index 30a42e2..6757690 100644 > --- a/arch/powerpc/mm/numa.c > +++ b/arch/powerpc/mm/numa.c > @@ -1591,6 +1591,14 @@ int arch_update_cpu_topology(void) > cpu = cpu_last_thread_sibling(cpu); > } > > + /* > + * The 'cpu_associativity_changes_mask' could be cleared if > + * all the cpus it indicates won't change their node, in > + * which case the 'updated_cpus' will be empty. > + */ > + if (!cpumask_weight(_cpus)) > + goto out; > + > stop_machine(update_cpu_topology, [0], _cpus); > > /* > @@ -1612,6 +1620,7 @@ int arch_update_cpu_topology(void) > changed = 1; > } > > +out: > kfree(updates); > return changed; > } > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please
Re: [PATCH regression] net: phy: fix initialization (config_init) for Marvel 88E1116R PHYs
On 04/03/2014 09:17 AM, Alexander Holler wrote: > Am 03.04.2014 00:27, schrieb Sebastian Hesselbarth: >> On 04/03/2014 12:12 AM, Alexander Holler wrote: I am curious, how you determined above commit to be the cause of the regression you are seeing. Can you bisect, if you didn't already? >>> >>> There was no bisecting necessary. I've just looked at what changed in >>> mv643xx_eth since 3.13 and the first commit I've reverted was already a >>> hit. Reading a bit source revealed the differences between the old reset >>> and the newly used one and ended up with my patch (first try) and was a >>> hit too. >> >> Honestly, your own fix changes a different driver than mv643xx_eth. > > It changes stuff which now (through the mentioned commit) gets used > through the change in mv643xx_eth. Sigh. You have proven youself that the commit isn't the root cause of the issue you are seeing. Nor is "fixing" 88e1116r init sequence a reasonable fix. >> There is a lot of changes from v3.13 to v3.14 and bisecting really >> helps to pin-point the one offending patch. As you can see from my >> tests with Dockstar, poking in the PHY driver may not be the right >> place to fix it. >> >>> Actually I assumed the reset needs longer than the 500ms, but as the >>> printks revealed, the reset is much faster. >>> So the problem seems to be the much increased time (1s) the newly used >>> reset function idles in mdelay. >> >> You assume that the PHY issue comes from waiting for too long _after_ >> the reset? And again, the very same PHY on Dockstar is not affected. > > Guess with which hardware I'm experiencing this problem? Hint: > http://ahsoftware.de/dockstar/ ;) I don't know, but now I guess it is Dockstar. >>> But I think I have found the real reason. and the change of the reset >>> just increased the chance the problem is hit (here with 100% success or >>> fail rate however you want to name it). >>> >>> Just give me a day or two to find the time to verify my assumption (I >>> don't want to speculate) and maybe find a real fix for the problem. Of >>> course, I still like my patch because it greatly decreases the time >>> necessary for a reset (and the chance to hit the problem). >> >> Well, you can share your idea anytime. You already speculated that PHY >> reset on 88e1116r is broken but it seems that is not true. The more >> you share of your issue and the tries to fix it, the more likely is it >> we can follow your patch immediately. > > Sorry, but wild speculating doesn't help always. Otherwise I could > mention several dozen possible reasons, starting from broken memory or > other hw up to some memory corruption elsewhere in the kernel. > > But I already have given a hint before, try what happens if you enable > netconsole (compiled in) through the kernel commandline > (netconsole=...). Maybe the ethernet on your dockstar will get stuck too. If it is related to netconsole, I would guess it is more platforms affected than just Dockstar? If you share the idea, we can try to find a way to allow netconsole on more than just that mv643xx_eth/88e116r combination. >> Again, if you really want to find the real patch breaking Sheevaplug, >> use git bisect. > > That's silly if I already know a/the change which brings the problem to > light. If I revert the mentioned commit the problem disapears. So why > should I go through the pain to bisect stuff? I already have found the > knob to kill the ethernet on that machine. Really, I can tell you two fixes for it right away: don't use netconsole or remove Marvell PHY support. But neither is really helping here. If you share your ideas early, it is at least two more who are looking at it. This is just a suggestion, you are free to take it though. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arm64: Fix duplicated Kconfig entries again
On Thu, Apr 3, 2014 at 2:05 PM, Hanjun Guo wrote: > How about the following patch? if it is ok, I will resend it. http://www.spinics.net/lists/arm-kernel/msg319545.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 v2] staging: comedi: s626: use comedi_timeout() on remaining loops
On Tue, Mar 25, 2014 at 10:43:58PM -0500, Chase Southwood wrote:
> There were just a handful of more while loops in this file that needed
> timeouts, and this patch takes care of them. One new callback is
> introduced, and all of the proper comedi_timeout() calls are then used.
>
> Signed-off-by: Chase Southwood
> ---
> 2: s626_i2c_handshake_eoc() can be used in s626_initialize() as noted by
> Ian. So, s626_initialize_eoc() has been removed, and its uses swapped
> for s626_i2c_handshake_eoc().
>
> drivers/staging/comedi/drivers/s626.c | 34 ++
> 1 file changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/comedi/drivers/s626.c
> b/drivers/staging/comedi/drivers/s626.c
> index 95fadf3..865cf93 100644
> --- a/drivers/staging/comedi/drivers/s626.c
> +++ b/drivers/staging/comedi/drivers/s626.c
> @@ -295,10 +295,24 @@ static void s626_debi_replace(struct comedi_device
> *dev, unsigned int addr,
>
> /* ** EEPROM ACCESS FUNCTIONS ** */
>
> +static int s626_i2c_handshake_eoc(struct comedi_device *dev,
> + struct comedi_subdevice *s,
> + struct comedi_insn *insn,
> + unsigned long context)
> +{
> + unsigned int status;
This should probably be bool.
> +
> + status = s626_mc_test(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
> + if (status)
> + return 0;
> + return -EBUSY;
> +}
> +
> static uint32_t s626_i2c_handshake(struct comedi_device *dev, uint32_t val)
> {
> struct s626_private *devpriv = dev->private;
> unsigned int ctrl;
> + uint32_t ret;
This should be int. I get really suspicious when people start using
uint32_t types. Why does it have to be 32 bits? Unsigned is wrong as
well.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: Fix duplicated Kconfig entries again
Hi Rafael, Sorry the late reply. On 2014-3-27 23:18, Rafael J. Wysocki wrote: [...] >>> Just had a look at the linux-next tree and looks like the original commit: >>> "cpufreq: enable ARM drivers on arm64" is pulled by both Catalin and Rafael >>> which has resulted in the fixup patch[1] not removing the duplicate entry >>> cleanly. >>> >>> If not too late it better to ask either Rafael or Catalin to drop both >>> patches >>> from their tree, instead of creating 4 patches in total to enable cpufreq :) >> >> Rafael is on vacation now. >> >> Catalin, could you please handle this? > > Well, not really, I'm at a conference now. Oops... > > Anyway, I'd rather not drop anything, but if you send me a revert, I can > apply it. Mark Brown sent another patch to fix this problem, and that patch already merged into mainline, but the problem is still there, so I think a single revert will not help. How about the following patch? if it is ok, I will resend it. After commit 74397174989e5 (arm64: Fix duplicated Kconfig entries), I still get a duplicate Power management options section in linux-next git repo, may be due to some merge conflicts, anyway, fix that in this patch. Signed-off-by: Hanjun Guo --- Based on linux-next repo, weird, did I miss something? --- arch/arm64/Kconfig | 12 1 file changed, 12 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index d9f23ad..6085dca 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -317,24 +317,12 @@ config ARCH_SUSPEND_POSSIBLE config ARM64_CPU_SUSPEND def_bool PM_SLEEP -endmenu - -menu "CPU Power Management" - source "drivers/cpuidle/Kconfig" source "drivers/cpufreq/Kconfig" endmenu -menu "Power management options" - -source "kernel/power/Kconfig" - -source "drivers/cpufreq/Kconfig" - -endmenu - source "net/Kconfig" source "drivers/Kconfig" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND: RFC PATCH 3/3] pcie: keystone: add pcie driver based on designware core driver
Am Mittwoch, den 02.04.2014, 13:17 -0400 schrieb Murali Karicheri:
> Arnd,
>
> Thanks for reviewing the RFC patch. Please see below my response.
>
> On 3/25/2014 3:44 AM, Arnd Bergmann wrote:
> > On Monday 24 March 2014 20:35:26 Murali Karicheri wrote:
[...]
>
> >> + ks_pcie->clk = devm_clk_get(>dev, "pcie");
> >> + if (IS_ERR(ks_pcie->clk)) {
> >> + dev_err(>dev, "Failed to get pcie rc clock\n");
> >> + return PTR_ERR(ks_pcie->clk);
> >> + }
> >> + ret = clk_prepare_enable(ks_pcie->clk);
> >> + if (ret)
> >> + return ret;
> > Could you move the clock handling into the generic dw-pcie code?
>
> Could be. But currently only pci-exynos.c is using a clock name
> "pcie".pci-imx6.c uses pcie_axi" and
> will have to be fixed so that we can move this code to the generic
> dw-pcie code. Sean Cross is the
> author for pci-imx6.c.
>
> Sean,
>
> Is "pcie_axi" is the pcie hw clock? If so, can you rename this to "pcie"
> so that my patch can move the
> clock handling code to pcie designware code?
>
My series "i.MX6 PCIe binding change and MSI support" already changes
the clock name. So we could consolidate the clock handling once this is
in. Only difference is that the i.MX6 needs an additional PHY clock.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: fpgaboot: clean up Makefile
This Makefile tries to set the DEBUG macro but it uses an unknown Kconfig macro to do so. Since no code appears to even care about the DEBUG macro this line can safely be removed. Signed-off-by: Paul Bolle --- Completely untested. By the way, do de...@driverdev.osuosl.org and de...@linuxdriverproject.org deliver to the same list? drivers/staging/gs_fpgaboot/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/gs_fpgaboot/Makefile b/drivers/staging/gs_fpgaboot/Makefile index 34cb606..d2f0211 100644 --- a/drivers/staging/gs_fpgaboot/Makefile +++ b/drivers/staging/gs_fpgaboot/Makefile @@ -1,4 +1,2 @@ gs_fpga-y += gs_fpgaboot.o io.o obj-$(CONFIG_GS_FPGABOOT) += gs_fpga.o - -ccflags-$(CONFIG_GS_FPGA_DEBUG):= -DDEBUG -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: document the berlin enable-method property
On 03/04/2014 at 10:08:15 +0200, Antoine Ténart wrote : Please write a quick commit message. > Signed-off-by: Antoine Ténart > --- > Documentation/devicetree/bindings/arm/cpus.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt > b/Documentation/devicetree/bindings/arm/cpus.txt > index 333f4aea3029..a9e42a2dbc99 100644 > --- a/Documentation/devicetree/bindings/arm/cpus.txt > +++ b/Documentation/devicetree/bindings/arm/cpus.txt > @@ -185,6 +185,8 @@ nodes to be present and contain the properties described > below. > "qcom,gcc-msm8660" > "qcom,kpss-acc-v1" > "qcom,kpss-acc-v2" > + "marvell,88de31-smp" - cpu-core handling for Berlin > + SoC from Marvell starting with 88de31 I would also go for something else, marvell,88de31xx-smp or marvell,berlin-smp. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
Hi On 04/03/2014 12:29 AM, Julius Werner wrote: Hi Mathias, The patch looks fine. Mathias is taking over for xHCI driver maintainership in 3.15. He's currently handling queuing bug fix patches for 3.14 while I finish queueing feature patches for 3.15. Mathias, will you test and queue this up for 3.14? Did you pick this patch up anywhere yet or are there still issues with it? I just want to make sure it doesn't slip through the cracks. (Maybe I just didn't see it yet... are you still queueing patches in sarah/xhci.git or do you have your own repository somewhere?) Patch applies fine and I'll send it forward to Greg once 3.15-rc1 is out. I'm not using Sarah's tree, but setting up my own tree on kernel.org (Just got access). I got a temporary one on github if you want to take a look, but it's a short term thing and it may change without warning. g...@github.com:matnyman/xhci.git -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ASoC: dapm: Add support for multi register mux
On 04/03/2014 05:11 AM, Arun Shamanna Lakshmi wrote:
This looks essentially good to me. A few minor issues, once those are fixed
things should be good to go.
[...]
struct snd_soc_dapm_update {
struct snd_kcontrol *kcontrol;
- int reg;
- int mask;
- int val;
+ int reg[3];
+ int mask[3];
+ int val[3];
Make the 3 a define and check against it in the put handler.
+ int num_regs;
unsigned int
};
[...]
+/*
+ * Soc Enum Type
+ *
+ * @NONE:soc_enum type for SINGLE, DOUBLE or VIRTUAL mux
+ * @ONEHOT: soc_enum type for one hot encoding mux
+ */
This should be kernel doc style so
/**
* enum snd_soc_enum_type - Type of the ASoC enum control
* @SND_SOC_ENUM_NONE: ...
* ...
*/
+enum snd_soc_enum_type {
+ SND_SOC_ENUM_NONE = 0,
I'm not sure if NONE is the right term. Maybe BINARY is better.
+ SND_SOC_ENUM_ONEHOT = 1,
+};
+
[...]
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index c8a780d..19b004a 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -511,13 +511,26 @@ static int dapm_connect_mux(struct snd_soc_dapm_context
*dapm,
const struct snd_kcontrol_new *kcontrol)
{
struct soc_enum *e = (struct soc_enum *)kcontrol->private_value;
- unsigned int val, item;
+ unsigned int val, item, bit_pos = -1;
default for bit_pos should probably be 0.
[...]
@@ -1575,8 +1588,12 @@ static void dapm_widget_update(struct snd_soc_card *card)
if (!w)
return;
- ret = soc_widget_update_bits_locked(w, update->reg, update->mask,
- update->val);
+ /* dapm update for multiple registers */
+ for (i = 0; i < update->num_regs; i++) {
+ ret |= soc_widget_update_bits_locked(w, update->reg[i],
+ update->mask[i], update->val[i]);
I'd prefer
ret = soc_widget_update_bits_locked(...);
if (ret < 0)
break;
+ }
+
if (ret < 0)
dev_err(w->dapm->dev, "ASoC: %s DAPM update failed: %d\n",
w->name, ret);
[...]
@@ -2984,6 +3002,112 @@ int snd_soc_dapm_put_enum_double(struct snd_kcontrol
*kcontrol,
EXPORT_SYMBOL_GPL(snd_soc_dapm_put_enum_double);
/**
+ * snd_soc_dapm_get_enum_onehot - dapm enumerated onehot mixer get callback
+ * @kcontrol: mixer control
+ * @ucontrol: control element information
+ *
+ * Callback to get the value of a dapm enumerated onehot encoded mixer control
+ *
+ * Returns 0 for success.
+ */
+int snd_soc_dapm_get_enum_onehot(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_soc_dapm_kcontrol_codec(kcontrol);
+ struct soc_enum *e = (struct soc_enum *)kcontrol->private_value;
+ unsigned int reg_val, val, bit_pos = -1, reg_idx;
Here as well, default for bit_pos should be 0.
+
+ for (reg_idx = 0; reg_idx < e->num_regs; reg_idx++) {
+ reg_val = snd_soc_read(codec, e->reg[reg_idx]);
+ val = reg_val & e->mask[reg_idx];
+ if (val != 0) {
+ bit_pos = __ffs(val) + (8 * codec->val_bytes * reg_idx);
+ break;
+ }
+ }
+
+ ucontrol->value.enumerated.item[0] =
+ snd_soc_enum_val_to_item(e, bit_pos);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(snd_soc_dapm_get_enum_onehot);
+
+/**
+ * snd_soc_dapm_put_enum_onehot - dapm enumerated onehot mixer put callback
+ * @kcontrol: mixer control
+ * @ucontrol: control element information
+ *
+ * Callback to put the value of a dapm enumerated onehot encoded mixer control
+ *
+ * Returns 0 for success.
+ */
+int snd_soc_dapm_put_enum_onehot(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_soc_dapm_kcontrol_codec(kcontrol);
+ struct snd_soc_card *card = codec->card;
+ struct soc_enum *e = (struct soc_enum *)kcontrol->private_value;
+ unsigned int *item = ucontrol->value.enumerated.item;
+ unsigned int change = 0, reg_idx = 0, value, bit_pos;
+ struct snd_soc_dapm_update update;
+ int ret = 0, reg_val = 0, i, update_idx = 0;
+
+ if (item[0] >= e->items)
+ return -EINVAL;
+
+ value = snd_soc_enum_item_to_val(e, item[0]);
+
+ if (value >= 0) {
value is unsigned int, so this is never false.
+ /* get the register index and value to set */
+ reg_idx = value / (8 * codec->val_bytes);
+ bit_pos = value % (8 * codec->val_bytes);
+ reg_val = BIT(bit_pos);
+ }
+
+ for (i = 0; i < e->num_regs; i++) {
+ if (i == reg_idx) {
+ change = snd_soc_test_bits(codec, e->reg[i],
+ e->mask[i], reg_val);
change |=
Re: [PATCH 2/3] ARM: dts: document the berlin enable-method property
Hi, On Thu, 3 Apr 2014 01:08:15 -0700 Antoine Ténart wrote: > Signed-off-by: Antoine Ténart > --- > Documentation/devicetree/bindings/arm/cpus.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt > b/Documentation/devicetree/bindings/arm/cpus.txt index > 333f4aea3029..a9e42a2dbc99 100644 --- > a/Documentation/devicetree/bindings/arm/cpus.txt +++ > b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@ nodes > to be present and contain the properties described below. "qcom,gcc-msm8660" > "qcom,kpss-acc-v1" > "qcom,kpss-acc-v2" > + "marvell,88de31-smp" - cpu-core handling for why not "marvell,berlin-smp"? 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] mm: msync: require either MS_ASYNC or MS_SYNC
[CC += Peter Zijlstra] [CC += bug-readl...@gnu.org -- maintainers, it _may_ be desirable to fix your msync() call] Richard, On Thu, Apr 3, 2014 at 1:44 AM, Richard Hansen wrote: > On 2014-04-02 07:45, Steven Whitehouse wrote: >> Hi, >> >> On Wed, 2014-04-02 at 04:10 -0700, Christoph Hellwig wrote: >>> On Tue, Apr 01, 2014 at 02:25:45PM -0400, Richard Hansen wrote: For the flags parameter, POSIX says "Either MS_ASYNC or MS_SYNC shall be specified, but not both." [1] There was already a test for the "both" condition. Add a test to ensure that the caller specified one of the flags; fail with EINVAL if neither are specified. >>> >>> This breaks various (sloppy) existing userspace > > Agreed, but this shouldn't be a strong consideration. The kernel should > let userspace apps worry about their own bugs, not provide crutches. > >>> for no gain. > > I disagree. Here is what we gain from this patch (expanded from my > previous email): > > * Clearer intentions. Looking at the existing code and the code > history, the fact that flags=0 behaves like flags=MS_ASYNC appears > to be a coincidence, not the result of an intentional choice. Maybe. You earlier asserted that the semantics when flags==0 may have been different, prior to Peter Zijstra's patch, https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=204ec841fbea3e5138168edbc3a76d46747cc987 . It's not clear to me that that is the case. But, it would be wise to CC the developer, in case he has an insight. > * Clearer semantics. What does it mean for msync() to be neither > synchronous nor asynchronous? > > * Met expectations. An average reader of the POSIX spec or the > Linux man page would expect msync() to fail if neither flag is > specified. > > * Defense against potential future security vulnerabilities. By > explicitly requiring one of the flags, a future change to msync() > is less likely to expose an unintended code path to userspace. > > * flags=0 is reserved. By making it illegal to omit both flags > we have the option of making it legal in the future for some > expanded purpose. (Unlikely, but still.) > > * Forced app portability. Other operating systems (e.g., NetBSD) > enforce POSIX, so an app developer using Linux might not notice the > non-conformance. This is really the app developer's problem, not > the kernel's, but it's worth considering given msync()'s behavior > is currently unspecified. There is no doubt that the situation on Linux is an unfortunate mess from history (and is far from the only one, see https://lwn.net/Articles/588444/). And I think everyone would agree that all of the above would be nice to have, if there was no cost to having them. But, there is a major cost: the pain of breaking those sloppy user-space applications. And in fact some casual grepping suggests that many applications would break, since, for example, libreadline contains (in histfile.c) an msync() call that omits both MS_SYNC and MS_ASYNC (I have not looked into the details of what that piece of code does). But, even if you could find and fix every application that misuses msync(), new kernels with your proposed changes would still break old binaries. Linus has made it clear on numerous occasions that kernel changes must not break user space. So, the change you suggest is never going to fly (and Christoph's NAK at least saves Linus yelling at you ;-).) > Here is a link to a discussion on the bup mailing list about > msync() portability. This is the conversation that motivated this > patch. > > http://article.gmane.org/gmane.comp.sysutils.backup.bup/3005 > > Alternatives: > > * Do nothing. Leave the behavior of flags=0 unspecified and let > sloppy userspace continue to be sloppy. Easiest, but the intended > behavior remains unclear and it risks unintended behavior changes > the next time msync() is overhauled. > > * Leave msync()'s current behavior alone, but document that MS_ASYNC > is the default if neither is specified. This is backward- > compatible with sloppy userspace, but encourages non-portable uses > of msync() and would preclude using flags=0 for some other future > purpose. > > * Change the default to MS_SYNC and document this. This is perhaps > the most conservative option, but it alters the behavior of existing > sloppy userspace and also has the disadvantages of the previous > alternative. > > Overall, I believe the advantages of this patch outweigh the > disadvantages, given the alternatives. I think the only reasonable solution is to better document existing behavior and what the programmer should do. With that in mind, I've drafted the following text for the msync(2) man page: NOTES According to POSIX, exactly one of MS_SYNC and MS_ASYNC must be specified in flags. However, Linux permits a call to msync() that specifies
Re: [PATCH 7/9] driver: staging: wlan-ng: Fixed white spaces issues
Yes I see the error. I have tried to build the wlan-ng driver using make
M=drivers/staging/wlan-ng/ but it built nothing, so I went one step up
and built make M=drivers/staging/ as a whole and it built fine, I think
I am missing something here, how do I specify this module for the build
to test my changes?
On 04/03/2014 09:45 AM, Dan Carpenter wrote:
On Thu, Apr 03, 2014 at 09:13:29AM +0200, Sherif Shehab Aldin wrote:
static void hfa384x_usbctlx_resptimerfn(unsigned long data)
{
- hfa384x_t *hw = (hfa384x_t *) data;
+ hfa384x_t *hw = (hfa384x_t *)
unsigned long flags;
spin_lock_irqsave(>ctlxq.lock, flags);
This breaks the build.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 09/11] ARM: mvebu: Register notifier callback for the cpuidle transition
On 03/28/2014 12:13 PM, Gregory CLEMENT wrote:
In order to have well encapsulated code, we use notifier callbacks for
CPU_PM_ENTER and CPU_PM_EXIT inside the mvebu power management code.
Signed-off-by: Gregory CLEMENT
Acked-by: Daniel Lezcano
---
arch/arm/mach-mvebu/pmsu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
index 968c8c02c126..9ea2bb44d573 100644
--- a/arch/arm/mach-mvebu/pmsu.c
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -18,6 +18,7 @@
#define pr_fmt(fmt) "mvebu-pmsu: " fmt
+#include
#include
#include
#include
@@ -263,4 +264,21 @@ static noinline void armada_370_xp_pmsu_idle_restore(void)
writel(reg, pmsu_mp_base + PMSU_STATUS_AND_MASK(hw_cpu));
}
+static int armada_370_xp_cpu_pm_notify(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ if (action == CPU_PM_ENTER) {
+ unsigned int hw_cpu = cpu_logical_map(smp_processor_id());
+ mvebu_pmsu_set_cpu_boot_addr(hw_cpu, armada_370_xp_cpu_resume);
+ } else if (action == CPU_PM_EXIT) {
+ armada_370_xp_pmsu_idle_restore();
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block armada_370_xp_cpu_pm_notifier = {
+ .notifier_call = armada_370_xp_cpu_pm_notify,
+};
+
early_initcall(armada_370_xp_pmsu_init);
--
Facebook |
Twitter |
Re: [PATCH v6 10/11] cpuidle: mvebu: Add initial CPU idle support for Armada 370/XP SoC
On 03/28/2014 12:13 PM, Gregory CLEMENT wrote:
Add the wfi, cpu idle and cpu deep idle power states support for the
Armada XP SoCs.
All the latencies and the power consumption values used at the
"armada_370_xp_idle_driver" structure are preliminary and will be
modified in the future after running some measurements and analysis.
Based on the work of Nadav Haklai.
Signed-off-by: Nadav Haklai
Signed-off-by: Gregory CLEMENT
Acked-by: Daniel Lezcano
---
drivers/cpuidle/Kconfig.arm | 5 ++
drivers/cpuidle/Makefile| 1 +
drivers/cpuidle/cpuidle-armada-370-xp.c | 93 +
3 files changed, 99 insertions(+)
create mode 100644 drivers/cpuidle/cpuidle-armada-370-xp.c
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 97ccc31dbdd8..5bb94780d377 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -1,6 +1,11 @@
#
# ARM CPU Idle drivers
#
+config ARM_ARMADA_370_XP_CPUIDLE
+ bool "CPU Idle Driver for Armada 370/XP family processors"
+ depends on ARCH_MVEBU
+ help
+ Select this to enable cpuidle on Armada 370/XP processors.
config ARM_BIG_LITTLE_CPUIDLE
bool "Support for ARM big.LITTLE processors"
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index f71ae1b373c5..9902d052bd87 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
##
# ARM SoC drivers
+obj-$(CONFIG_ARM_ARMADA_370_XP_CPUIDLE) += cpuidle-armada-370-xp.o
obj-$(CONFIG_ARM_BIG_LITTLE_CPUIDLE) += cpuidle-big_little.o
obj-$(CONFIG_ARM_HIGHBANK_CPUIDLE)+= cpuidle-calxeda.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUIDLE)+= cpuidle-kirkwood.o
diff --git a/drivers/cpuidle/cpuidle-armada-370-xp.c
b/drivers/cpuidle/cpuidle-armada-370-xp.c
new file mode 100644
index ..6b98608c222e
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-armada-370-xp.c
@@ -0,0 +1,93 @@
+/*
+ * Marvell Armada 370 and Armada XP SoC cpuidle driver
+ *
+ * Copyright (C) 2013 Marvell
2014 ?
+ *
+ * Nadav Haklai
+ * Gregory CLEMENT
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Maintainer: Gregory CLEMENT
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ARMADA_370_XP_MAX_STATES 3
+#define ARMADA_370_XP_FLAG_DEEP_IDLE 0x1
+
+static int (*armada_370_xp_cpu_suspend)(int);
+
+static int armada_370_xp_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ int ret;
+ bool deepidle = false;
+ cpu_pm_enter();
+
+ if (drv->states[index].flags & ARMADA_370_XP_FLAG_DEEP_IDLE)
+ deepidle = true;
+
+ ret = armada_370_xp_cpu_suspend(deepidle);
+ if (ret)
+ return ret;
+
+ cpu_pm_exit();
+
+ return index;
+}
+
+static struct cpuidle_driver armada_370_xp_idle_driver = {
+ .name = "armada_370_xp_idle",
+ .states[0] = ARM_CPUIDLE_WFI_STATE,
+ .states[1] = {
+ .enter = armada_370_xp_enter_idle,
+ .exit_latency = 10,
+ .power_usage= 50,
+ .target_residency = 100,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = "MV CPU IDLE",
+ .desc = "CPU power down",
+ },
+ .states[2] = {
+ .enter = armada_370_xp_enter_idle,
+ .exit_latency = 100,
+ .power_usage= 5,
+ .target_residency = 1000,
+ .flags = CPUIDLE_FLAG_TIME_VALID |
+ ARMADA_370_XP_FLAG_DEEP_IDLE,
+ .name = "MV CPU DEEP IDLE",
+ .desc = "CPU and L2 Fabric power down",
+ },
+ .state_count = ARMADA_370_XP_MAX_STATES,
+};
+
+static int armada_370_xp_cpuidle_probe(struct platform_device *pdev)
+{
+
+ armada_370_xp_cpu_suspend = (void *)(pdev->dev.platform_data);
+ return cpuidle_register(_370_xp_idle_driver, NULL);
+}
+
+static struct platform_driver armada_370_xp_cpuidle_plat_driver = {
+ .driver = {
+ .name = "cpuidle-armada-370-xp",
+ .owner = THIS_MODULE,
+ },
+ .probe = armada_370_xp_cpuidle_probe,
+};
+
+module_platform_driver(armada_370_xp_cpuidle_plat_driver);
+
+MODULE_AUTHOR("Gregory CLEMENT ");
+MODULE_DESCRIPTION("Armada 370/XP cpu
[PATCH] rtlwifi: btcoexist: remove undefined Kconfig macros
There are references to four undefined Kconfig macros in the code.
Commit 8542373dccd2 ("Staging: rtl8812ae: remove undefined Kconfig
macros") removed identical references from that staging driver, but
they resurfaced in rtlwifi. Remove these again as the checks for them
still will always evaluate to false.
Signed-off-by: Paul Bolle
---
Tested by grepping the tree only.
A follow up could now remove both "enum btc_chip_interface" and
"chip_interface", couldn't it?
drivers/net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c
b/drivers/net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c
index b6722de6..33da3df 100644
--- a/drivers/net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -625,17 +625,7 @@ bool exhalbtc_initlize_variables(struct rtl_priv *adapter)
else
btcoexist->binded = true;
-#if (defined(CONFIG_PCI_HCI))
- btcoexist->chip_interface = BTC_INTF_PCI;
-#elif (defined(CONFIG_USB_HCI))
- btcoexist->chip_interface = BTC_INTF_USB;
-#elif (defined(CONFIG_SDIO_HCI))
- btcoexist->chip_interface = BTC_INTF_SDIO;
-#elif (defined(CONFIG_GSPI_HCI))
- btcoexist->chip_interface = BTC_INTF_GSPI;
-#else
btcoexist->chip_interface = BTC_INTF_UNKNOWN;
-#endif
if (NULL == btcoexist->adapter)
btcoexist->adapter = adapter;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] grant-table, xen-netback: Introduce helper functions for grant copy operations
> -Original Message-
> From: Zoltan Kiss
> Sent: 02 April 2014 18:06
> To: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org;
> konrad.w...@oracle.com; boris.ostrov...@oracle.com; David Vrabel
> Cc: Stefano Stabellini; Paul Durrant; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Jonathan Davies; Zoltan Kiss
> Subject: [PATCH] grant-table, xen-netback: Introduce helper functions for
> grant copy operations
>
> Create helper functions for grant copy operations and use them in netback.
>
> Signed-off-by: Zoltan Kiss
> ---
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-
> netback/netback.c
> index 8d3bb4a..874df60 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -275,23 +275,29 @@ static void xenvif_gop_frag_copy(struct xenvif *vif,
> struct sk_buff *skb,
> bytes = MAX_BUFFER_OFFSET - npo->copy_off;
>
> copy_gop = npo->copy + npo->copy_prod++;
> - copy_gop->flags = GNTCOPY_dest_gref;
> - copy_gop->len = bytes;
>
> if (foreign_vif) {
> - copy_gop->source.domid = foreign_vif->domid;
> - copy_gop->source.u.ref = foreign_gref;
> - copy_gop->flags |= GNTCOPY_source_gref;
> + gnttab_set_copy_op_ref_to_ref(copy_gop,
> + foreign_gref,
> + npo->copy_gref,
> + foreign_vif->domid,
> + offset,
> + vif->domid,
> + npo->copy_off,
> + bytes,
> + GNTCOPY_dest_gref |
> + GNTCOPY_source_gref);
Can't you lose the flags here (and in the other variants)? Since they are
implied by the variant of the function they could just be hardcoded there,
couldn't they?
Paul
> } else {
> - copy_gop->source.domid = DOMID_SELF;
> - copy_gop->source.u.gmfn =
> - virt_to_mfn(page_address(page));
> + gnttab_set_copy_op_gmfn_to_ref(copy_gop,
> +
> virt_to_mfn(page_address(page)),
> +npo->copy_gref,
> +DOMID_SELF,
> +offset,
> +vif->domid,
> +npo->copy_off,
> +bytes,
> +GNTCOPY_dest_gref);
> }
> - copy_gop->source.offset = offset;
> -
> - copy_gop->dest.domid = vif->domid;
> - copy_gop->dest.offset = npo->copy_off;
> - copy_gop->dest.u.ref = npo->copy_gref;
>
> npo->copy_off += bytes;
> meta->size += bytes;
> @@ -1297,18 +1303,16 @@ static void xenvif_tx_build_gops(struct xenvif
> *vif,
> XENVIF_TX_CB(skb)->pending_idx = pending_idx;
>
> __skb_put(skb, data_len);
> - vif->tx_copy_ops[*copy_ops].source.u.ref = txreq.gref;
> - vif->tx_copy_ops[*copy_ops].source.domid = vif->domid;
> - vif->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
> -
> - vif->tx_copy_ops[*copy_ops].dest.u.gmfn =
> - virt_to_mfn(skb->data);
> - vif->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
> - vif->tx_copy_ops[*copy_ops].dest.offset =
> - offset_in_page(skb->data);
> -
> - vif->tx_copy_ops[*copy_ops].len = data_len;
> - vif->tx_copy_ops[*copy_ops].flags =
> GNTCOPY_source_gref;
> +
> + gnttab_set_copy_op_ref_to_gmfn(
> >tx_copy_ops[*copy_ops],
> +txreq.gref,
> +virt_to_mfn(skb->data),
> +vif->domid,
> +txreq.offset,
> +DOMID_SELF,
> +offset_in_page(skb->data),
> +data_len,
> +GNTCOPY_source_gref);
>
> (*copy_ops)++;
>
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index a5af2a2..90a2f4c 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -140,6 +140,59 @@ void
> gnttab_grant_foreign_transfer_ref(grant_ref_t, domid_t domid,
>
How to pass I2C platform_data under ACPI
Hi All,
I am trying to enable a i2c client driver under ACPI. The device is being
enumerated behind adapter device and I am getting IRQ resource as well.
The problem I have now is, how do I pass the platform data to driver?
struct i2c_board_info {
chartype[I2C_NAME_SIZE];
unsigned short flags;
unsigned short addr;
void*platform_data; ===> how can I initialize this
filed.
struct dev_archdata *archdata;
struct device_node *of_node;
struct acpi_dev_node acpi_node;
int irq;
};
In non ACPI environment I used to initialize the platform_data under board or
platforms files. Under ACPI how do I do that?
Thanks,
Ram
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] ARM: berlin: convert smp to CPU_METHOD_OF_DECLARE
The newly introduced CPU_METHOD_OF_DECLARE (6c3ff8b11a16) [1] allows to get rid of the board file reference to smp ops. This serie converts the Berlin SoC smp to use this and allows to set the enable-method in the device tree. This serie applies on top of Sebastian's topic/smp-bg3-bg2q branch [2] rebased on top of linux-next. Tested on the Berlin BG2Q. [1] https://patchwork.kernel.org/patch/3399311/ [2] https://github.com/shesselba/linux-berlin/tree/topic/smp-bg2-bg2q Antoine Ténart (3): ARM: berlin: use CPU_METHOD_OF_DECLARE for smp ARM: dts: document the berlin enable-method property ARM: dts: berlin: add enable-method property in cpus node for smp Documentation/devicetree/bindings/arm/cpus.txt | 2 ++ arch/arm/boot/dts/berlin2.dtsi | 1 + arch/arm/boot/dts/berlin2q.dtsi| 1 + arch/arm/mach-berlin/berlin.c | 1 - arch/arm/mach-berlin/common.h | 2 -- arch/arm/mach-berlin/platsmp.c | 3 ++- 6 files changed, 6 insertions(+), 4 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication
On 03/28/2014 11:44 AM, Hongbo Zhang wrote:
On 03/11/2014 07:06 PM, Vinod Koul wrote:
On Thu, Jan 16, 2014 at 01:47:22PM +0800, hongbo.zh...@freescale.com
wrote:
From: Hongbo Zhang
There are several places where descriptors are freed using identical
code.
This patch puts this code into a function to reduce code duplication.
Signed-off-by: Hongbo Zhang
Signed-off-by: Qiang Liu
---
drivers/dma/fsldma.c | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 95236e6..ad73538 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -418,6 +418,21 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
}
/**
+ * fsl_dma_free_descriptor - Free descriptor from channel's DMA pool.
+ * @chan : Freescale DMA channel
+ * @desc: descriptor to be freed
+ */
+static void fsl_dma_free_descriptor(struct fsldma_chan *chan,
+struct fsl_desc_sw *desc)
+{
+list_del(>node);
+#ifdef FSL_DMA_LD_DEBUG
+chan_dbg(chan, "LD %p free\n", desc);
+#endif
why not wrap the define stuff in the defination of chan_dbg rather
than its
usage :(
OK, I will fix it by another separate patch.
Thanks.
Think it again, I'd like to remove the FSL_DMA_LD_DEBUG usage, because
the chan_dbg is a wrapper of dev_dbg, we do have macro to switch on/off
dev_dbg, and most of other codes are calling chan_dbg directly without
FSL_DMA_LD_DEBUG, the FSL_DMA_LD_DEBUG only shows up 3 times unnecessarily.
___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: dts: berlin: add enable-method property in cpus node for smp
Signed-off-by: Antoine Ténart
---
arch/arm/boot/dts/berlin2.dtsi | 1 +
arch/arm/boot/dts/berlin2q.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 4d85312dc17a..596f6bd07677 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -21,6 +21,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "marvell,88de31-smp";
cpu@0 {
compatible = "marvell,pj4b";
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 86d8a2c49f38..5e8161aa21a3 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -17,6 +17,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "marvell,88de31-smp";
cpu@0 {
compatible = "arm,cortex-a9";
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: dts: document the berlin enable-method property
Signed-off-by: Antoine Ténart --- Documentation/devicetree/bindings/arm/cpus.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 333f4aea3029..a9e42a2dbc99 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@ nodes to be present and contain the properties described below. "qcom,gcc-msm8660" "qcom,kpss-acc-v1" "qcom,kpss-acc-v2" + "marvell,88de31-smp" - cpu-core handling for Berlin + SoC from Marvell starting with 88de31 - cpu-release-addr Usage: required for systems that have an "enable-method" -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: berlin: use CPU_METHOD_OF_DECLARE for smp
Get rid of the smp ops in the machine descriptor and select the cpu
enable method in the device tree.
Signed-off-by: Antoine Ténart
---
arch/arm/mach-berlin/berlin.c | 1 -
arch/arm/mach-berlin/common.h | 2 --
arch/arm/mach-berlin/platsmp.c | 3 ++-
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-berlin/berlin.c b/arch/arm/mach-berlin/berlin.c
index 1bbca793174d..3cc3e706719e 100644
--- a/arch/arm/mach-berlin/berlin.c
+++ b/arch/arm/mach-berlin/berlin.c
@@ -38,5 +38,4 @@ static const char * const berlin_dt_compat[] = {
DT_MACHINE_START(BERLIN_DT, "Marvell Berlin")
.dt_compat = berlin_dt_compat,
.init_machine = berlin_init_machine,
- .smp= smp_ops(berlin_smp_ops),
MACHINE_END
diff --git a/arch/arm/mach-berlin/common.h b/arch/arm/mach-berlin/common.h
index 57c97669af0a..8d585e2481f9 100644
--- a/arch/arm/mach-berlin/common.h
+++ b/arch/arm/mach-berlin/common.h
@@ -13,6 +13,4 @@
extern void berlin_secondary_startup(void);
-extern struct smp_operations berlin_smp_ops;
-
#endif
diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
index 5c83941b0918..86fe697577fd 100644
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -132,8 +132,9 @@ static void __init berlin_smp_prepare_cpus(unsigned int
max_cpus)
iounmap(gpr_base);
}
-struct smp_operations berlin_smp_ops __initdata = {
+static struct smp_operations berlin_smp_ops __initdata = {
.smp_prepare_cpus = berlin_smp_prepare_cpus,
.smp_secondary_init = berlin_secondary_init,
.smp_boot_secondary = berlin_boot_secondary,
};
+CPU_METHOD_OF_DECLARE(berlin_smp, "marvell,88de31-smp", _smp_ops);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next v3 1/2] xen-netback: Rename map ops
> -Original Message-
> From: Zoltan Kiss
> Sent: 02 April 2014 18:05
> To: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org
> Cc: Paul Durrant; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Jonathan Davies; Zoltan Kiss
> Subject: [PATCH net-next v3 1/2] xen-netback: Rename map ops
>
> Rename identifiers to state explicitly that they refer to map ops.
>
> Signed-off-by: Zoltan Kiss
Reviewed-by: Paul Durrant
> ---
> v3:
> - rename xenvif_tx_create_gop to xenvif_tx_create_map_op
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-
> netback/netback.c
> index ae34f5f..8f468ab 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -819,13 +819,13 @@ struct xenvif_tx_cb {
>
> #define XENVIF_TX_CB(skb) ((struct xenvif_tx_cb *)(skb)->cb)
>
> -static inline void xenvif_tx_create_gop(struct xenvif *vif,
> - u16 pending_idx,
> - struct xen_netif_tx_request *txp,
> - struct gnttab_map_grant_ref *gop)
> +static inline void xenvif_tx_create_map_op(struct xenvif *vif,
> + u16 pending_idx,
> + struct xen_netif_tx_request *txp,
> + struct gnttab_map_grant_ref *mop)
> {
> - vif->pages_to_map[gop-vif->tx_map_ops] = vif-
> >mmap_pages[pending_idx];
> - gnttab_set_map_op(gop, idx_to_kaddr(vif, pending_idx),
> + vif->pages_to_map[mop-vif->tx_map_ops] = vif-
> >mmap_pages[pending_idx];
> + gnttab_set_map_op(mop, idx_to_kaddr(vif, pending_idx),
> GNTMAP_host_map | GNTMAP_readonly,
> txp->gref, vif->domid);
>
> @@ -879,7 +879,7 @@ static struct gnttab_map_grant_ref
> *xenvif_get_requests(struct xenvif *vif,
>shinfo->nr_frags++, txp++, gop++) {
> index = pending_index(vif->pending_cons++);
> pending_idx = vif->pending_ring[index];
> - xenvif_tx_create_gop(vif, pending_idx, txp, gop);
> + xenvif_tx_create_map_op(vif, pending_idx, txp, gop);
> frag_set_pending_idx([shinfo->nr_frags],
> pending_idx);
> }
>
> @@ -899,7 +899,7 @@ static struct gnttab_map_grant_ref
> *xenvif_get_requests(struct xenvif *vif,
>shinfo->nr_frags++, txp++, gop++) {
> index = pending_index(vif->pending_cons++);
> pending_idx = vif->pending_ring[index];
> - xenvif_tx_create_gop(vif, pending_idx, txp, gop);
> + xenvif_tx_create_map_op(vif, pending_idx, txp,
> gop);
> frag_set_pending_idx([shinfo->nr_frags],
>pending_idx);
> }
> @@ -939,9 +939,9 @@ static inline void xenvif_grant_handle_reset(struct
> xenvif *vif,
>
> static int xenvif_tx_check_gop(struct xenvif *vif,
> struct sk_buff *skb,
> -struct gnttab_map_grant_ref **gopp)
> +struct gnttab_map_grant_ref **gopp_map)
> {
> - struct gnttab_map_grant_ref *gop = *gopp;
> + struct gnttab_map_grant_ref *gop_map = *gopp_map;
> u16 pending_idx = XENVIF_TX_CB(skb)->pending_idx;
> struct skb_shared_info *shinfo = skb_shinfo(skb);
> struct pending_tx_info *tx_info;
> @@ -950,11 +950,11 @@ static int xenvif_tx_check_gop(struct xenvif *vif,
> struct sk_buff *first_skb = NULL;
>
> /* Check status of header. */
> - err = gop->status;
> + err = gop_map->status;
> if (unlikely(err))
> xenvif_idx_release(vif, pending_idx,
> XEN_NETIF_RSP_ERROR);
> else
> - xenvif_grant_handle_set(vif, pending_idx , gop->handle);
> + xenvif_grant_handle_set(vif, pending_idx , gop_map-
> >handle);
>
> /* Skip first skb fragment if it is on same page as header fragment. */
> start = (frag_get_pending_idx(>frags[0]) == pending_idx);
> @@ -967,10 +967,12 @@ check_frags:
> tx_info = >pending_tx_info[pending_idx];
>
> /* Check error status: if okay then remember grant handle.
> */
> - newerr = (++gop)->status;
> + newerr = (++gop_map)->status;
>
> if (likely(!newerr)) {
> - xenvif_grant_handle_set(vif, pending_idx , gop-
> >handle);
> + xenvif_grant_handle_set(vif,
> + pending_idx,
> + gop_map->handle);
> /* Had a previous error? Invalidate this fragment. */
> if (unlikely(err))
> xenvif_idx_unmap(vif, pending_idx);
> @@ -1022,7 +1024,7 @@ check_frags:
> }
> }
>
> - *gopp = gop + 1;
> + *gopp_map = gop_map + 1;
> return
RE: [PATCH net-next v3 2/2] xen-netback: Grant copy the header instead of map and memcpy
> -Original Message-
> From: Zoltan Kiss
> Sent: 02 April 2014 18:05
> To: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org
> Cc: Paul Durrant; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Jonathan Davies; Zoltan Kiss
> Subject: [PATCH net-next v3 2/2] xen-netback: Grant copy the header
> instead of map and memcpy
>
> An old inefficiency of the TX path that we are grant mapping the first slot,
> and then copy the header part to the linear area. Instead, doing a grant copy
> for that header straight on is more reasonable. Especially because there are
> ongoing efforts to make Xen avoiding TLB flush after unmap when the page
> were
> not touched in Dom0. In the original way the memcpy ruined that.
> The key changes:
> - the vif has a tx_copy_ops array again
> - xenvif_tx_build_gops sets up the grant copy operations
> - we don't have to figure out whether the header and first frag are on the
> same
> grant mapped page or not
> Note, we only grant copy PKT_PROT_LEN bytes from the first slot, the rest (if
> any) will be on the first frag, which is grant mapped. If the first slot is
> smaller than PKT_PROT_LEN, then we grant copy that, and later
> __pskb_pull_tail
> will pull more from the frags (if any)
>
> Signed-off-by: Zoltan Kiss
Looks good to me.
Reviewed-by: Paul Durrant
> ---
> v2:
> - extend commit message
> - add patch to rename map ops
>
> v3:
> - remove unrelated refactoring
> - remove stale newline
> - fix sanity check at the end of build_gops
> - change debug message in tx_submit
> - remove unnecessary 'else' from tx_action
>
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-
> netback/common.h
> index 89b2d42..c995532 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -119,6 +119,7 @@ struct xenvif {
> struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
> grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
>
> + struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
> struct gnttab_map_grant_ref tx_map_ops[MAX_PENDING_REQS];
> struct gnttab_unmap_grant_ref
> tx_unmap_ops[MAX_PENDING_REQS];
> /* passed to gnttab_[un]map_refs with pages under (un)mapping */
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-
> netback/netback.c
> index 8ce93ff..a6cacf1 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -939,35 +939,37 @@ static inline void xenvif_grant_handle_reset(struct
> xenvif *vif,
>
> static int xenvif_tx_check_gop(struct xenvif *vif,
> struct sk_buff *skb,
> -struct gnttab_map_grant_ref **gopp_map)
> +struct gnttab_map_grant_ref **gopp_map,
> +struct gnttab_copy **gopp_copy)
> {
> struct gnttab_map_grant_ref *gop_map = *gopp_map;
> u16 pending_idx = XENVIF_TX_CB(skb)->pending_idx;
> struct skb_shared_info *shinfo = skb_shinfo(skb);
> - struct pending_tx_info *tx_info;
> int nr_frags = shinfo->nr_frags;
> - int i, err, start;
> + int i, err;
> struct sk_buff *first_skb = NULL;
>
> /* Check status of header. */
> - err = gop_map->status;
> - if (unlikely(err))
> + err = (*gopp_copy)->status;
> + (*gopp_copy)++;
> + if (unlikely(err)) {
> + if (net_ratelimit())
> + netdev_dbg(vif->dev,
> +"Grant copy of header failed! status: %d
> pending_idx% %u ref: %u\n",
> +(*gopp_copy)->status,
> +pending_idx,
> +(*gopp_copy)->source.u.ref);
> xenvif_idx_release(vif, pending_idx,
> XEN_NETIF_RSP_ERROR);
> - else
> - xenvif_grant_handle_set(vif, pending_idx , gop_map-
> >handle);
> -
> - /* Skip first skb fragment if it is on same page as header fragment. */
> - start = (frag_get_pending_idx(>frags[0]) == pending_idx);
> + }
>
> check_frags:
> - for (i = start; i < nr_frags; i++) {
> + for (i = 0; i < nr_frags; i++, gop_map++) {
> int j, newerr;
>
> pending_idx = frag_get_pending_idx(>frags[i]);
> - tx_info = >pending_tx_info[pending_idx];
>
> /* Check error status: if okay then remember grant handle.
> */
> - newerr = (++gop_map)->status;
> + newerr = gop_map->status;
>
> if (likely(!newerr)) {
> xenvif_grant_handle_set(vif,
> @@ -980,18 +982,20 @@ check_frags:
> }
>
> /* Error on this fragment: respond to client with an error. */
> + if (net_ratelimit())
> + netdev_dbg(vif->dev,
> +"Grant map of %d. frag failed! status: %d
> pending_idx% %u ref: %u\n",
> +i,
> +
Re: [PATCH] sched: update_rq_clock() must skip ONE update
On Tue, 2014-04-01 at 11:55 +0200, Ingo Molnar wrote:
> * Mike Galbraith wrote:
>
> > On Mon, 2014-03-31 at 11:37 -0700, Linus Torvalds wrote:
> > > On Mon, Mar 31, 2014 at 11:27 AM, Mike Galbraith
> > > wrote:
> > > >
> > > > Oh, I didn't cc you because I wanted it applied instantly as ultra
> > > > critical, only because the chain of events might be of interest.
> > >
> > > Ok. That was my main worry, since I was in the process or releasing
> > > 3.14, and I just couldn't tell if the patch was something I should
> > > worry about or not.
> > >
> > > And it seems that not applying it was the right thing, which is all
> > > that matters by now.
> >
> > Yes. Jocular red flag was to Peter and Ingo. I don't try to bypass
> > them, that would be plain rude. I've been known to help maintainers
> > a little, but I don't ever try to call the shots. They do that
> > well.
>
> Btw., in general feel free to Cc: Linus if a fix looks truly urgent,
> as neither Peter nor me might be around on a weekend, shortly before a
> release.
Still not urgent, but now verified to have fixed the large IO beast boot
problem. 'course that implies that disk discovery may generate truly
magnificent wakeup latency.. for the throttle to helpfully double.
---cut here---
Prevent large wakeup latencies from being accounted to the wrong task.
Cc:
Signed-off-by: Mike Galbraith
---
kernel/sched/core.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -118,7 +118,12 @@ void update_rq_clock(struct rq *rq)
{
s64 delta;
- if (rq->skip_clock_update > 0)
+ /*
+* Set during wakeup to indicate we are on the way to schedule().
+* Decrement to ensure that a very large latency is not accounted
+* to the wrong task.
+*/
+ if (rq->skip_clock_update-- > 0)
return;
delta = sched_clock_cpu(cpu_of(rq)) - rq->clock;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] blkdev: use an efficient way to check merge flags
On Thu, Apr 3, 2014 at 2:13 AM, Jan Kara wrote:
> OK, but have you checked the generated code is actually any better? This
> is something I'd expect a compiler might be able to optimize anyway. And the
> original code looks more readable to me.
Hi, Jan,
I've disassemble the code on my x86_64 box
(it's inline though, I just look at its call site),
and found that this patch DOES make it more efficient.
Orig asm snippt with
patch asm snippt
mov%edx,%ecx mov%rdx,%r9
xor%r8d,%ecx xor%r8d,%r8d
test $0x80,%cl and$0x380,%r9d
jne14c5 test $0x380,%ecx
and$0x3,%ch sete %r8b
jne14c5 cmp%r8,%r9
je 14b5
This saves a branch.
Furthermore, I found that gcc is smart enough to try to optimize the
code, so if we do
like this, it will generate the most optimal and smallest code :
static inline bool blk_check_merge_flags(unsigned int flags1,
¦unsigned int flags2)
{
return ((flags1 ^ flags2) &
(REQ_DISCARD | REQ_SECURE | REQ_WRITE_SAME))
== 0;
}
this gives out :
mov%edx,%r8d
xor%ecx,%r8d
and$0x380,%r8d
jne14a5
But yes, it compromises readibility.
Regards,
Jianyu Zhan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ttyprintk: Fix wrong tty_unregister_driver() call in the error path
On 04/03/2014 08:10 AM, Takashi Iwai wrote:
> At Wed, 02 Apr 2014 14:24:33 +0200,
> Jean Delvare wrote:
>>
>> Le Wednesday 02 April 2014 à 12:29 +0200, Takashi Iwai a écrit :
>>> ttyprintk driver calls tty_unregister_driver() wrongly in the error
>>> path of tty_register_driver(). Also, setting ttyprintk_driver to NULL
>>> is utterly superfluous, so let's get rid of it, too.
>>>
>>> Reported-by: Jean Delvare
>>> Signed-off-by: Takashi Iwai
>>> ---
>>> drivers/char/ttyprintk.c | 2 --
>>> 1 file changed, 2 deletions(-)
>>>
>>> diff --git a/drivers/char/ttyprintk.c b/drivers/char/ttyprintk.c
>>> index daea84c41743..2a39c5790364 100644
>>> --- a/drivers/char/ttyprintk.c
>>> +++ b/drivers/char/ttyprintk.c
>>> @@ -210,10 +210,8 @@ static int __init ttyprintk_init(void)
>>> return 0;
>>>
>>> error:
>>> - tty_unregister_driver(ttyprintk_driver);
>>> put_tty_driver(ttyprintk_driver);
>>> tty_port_destroy(_port.port);
>>> - ttyprintk_driver = NULL;
>>> return ret;
>>> }
>>> device_initcall(ttyprintk_init);
>>
>> Reviewed-by: Jean Delvare
>
> Meanwhile, I found that tty_unregister_driver() was added
> intentionally in the commit f06fb543c1d0,
> TTY: ttyprintk, unregister tty driver on failure
>
> When the tty_printk driver fails to create a node in sysfs, the
> system
> crashes. It is because the driver registers a tty driver and frees
> it
> without deregistering it first. The fix is easy: add a call to
> tty_unregister_driver to the fail path.
>
> But, I failed to see why this is needed in the current code.
>
> Jiri, is your fix still valid at all?
The code was different. There was also device_create after
tty_register_driver. I must admit that I don't know why I didn't change
'goto error' in the tty_register_driver fail path.
ret = tty_register_driver(ttyprintk_driver);
if (ret < 0) {
printk(KERN_ERR "Couldn't register ttyprintk driver\n");
goto error;
}
/* create our unnumbered device */
rp = device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 3), NULL,
ttyprintk_driver->name);
if (IS_ERR(rp)) {
printk(KERN_ERR "Couldn't create ttyprintk device\n");
ret = PTR_ERR(rp);
goto error;
}
So yes, there should be no tty_unregister_driver in the fail path when
device_create is gone now.
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
3.15-rc0: warn_on in suspend_test.c
Hi! Wakeup took longer than usual, and then I got: usb 2-1: reset low-speed USB device number 2 using uhci_hcd usb 5-1: reset low-speed USB device number 2 using uhci_hcd usb 1-8: reset high-speed USB device number 6 using ehci-pci usb 1-8: device descriptor read/64, error -110 usb 1-8: device descriptor read/64, error -110 usb 1-8: reset high-speed USB device number 6 using ehci-pci PM: resume of devices complete after 43288.193 msecs PM: resume devices took 43.392 seconds [ cut here ] WARNING: CPU: 1 PID: 7045 at kernel/power/suspend_test.c:53 suspend_test_finish+0x84/0x90() Component: resume devices, time: 43392 Modules linked in: CPU: 1 PID: 7045 Comm: pm-suspend Tainted: GW3.14.0+ #332 Hardware name: /DG41MJ, BIOS MJG4110H.86A.0006.2009.1223.1155 12/23/2009 0035 c08a9e30 c47dd48b c49d015e c08a9e60 c40384ea c49d0145 c08a9e8c 1b85 c49d015e 0035 c407b734 c407b734 a980 c49d00ea c08a9eb0 c08a9e78 c403858e 0009 c08a9e70 c49d0145 c08a9e8c c08a9e9c c407b734 Call Trace: [] dump_stack+0x41/0x52 [] warn_slowpath_common+0x7a/0xa0 [] ? suspend_test_finish+0x84/0x90 [] ? suspend_test_finish+0x84/0x90 [] warn_slowpath_fmt+0x2e/0x30 [] suspend_test_finish+0x84/0x90 [] suspend_devices_and_enter+0x159/0x2e0 [] ? printk+0x38/0x3a [] pm_suspend+0x201/0x240 [] state_store+0x8d/0x90 [] ? wakeup_count_show+0x40/0x40 [] kobj_attr_store+0x20/0x30 [] sysfs_kf_write+0x3b/0x50 [] kernfs_fop_write+0xb5/0x110 [] ? sysfs_file_ops+0x50/0x50 [] vfs_write+0x9e/0x190 [] ? kernfs_vma_page_mkwrite+0x80/0x80 [] ? __fdget+0xd/0x10 [] SyS_write+0x56/0xc0 [] ? __close_fd+0x6b/0x90 [] sysenter_do_call+0x12/0x31 ---[ end trace df8f3e773ca202a7 ]--- Now.. usb-to-video convertor was plugged in, so maybe that's responsible? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: Fwd: [SMACK]Problem with user naespace
My comments below.
Best regards
Jacek Pielaszkiewicz
Samsung R Institute Poland
Samsung Electronics
Email: j.pielasz...@samsung.com
> -Original Message-
> From: Serge E. Hallyn [mailto:se...@hallyn.com]
> Sent: Saturday, March 29, 2014 5:16 PM
> To: Jacek Pielaszkiewicz
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: Fwd: [SMACK]Problem with user naespace
>
> Quoting Jacek Pielaszkiewicz (j.pielasz...@samsung.com):
> >
> > Hi
> >
> > I have problem with starting lxc containers when SMACK is enabled
> > on the host. The issue appears when systemd try start user session in
> > the container. In such case systemd reports error that has not
> > permissions to set SMACK label. In my test configuration lxc
> container
> > has full separation (all namespaces are enabled - including user
> namespace).
> > The issue is common. The problem is due to lack of permissions of
> > the task to write into /proc/self/sttr/current file even the task has
> > active CAP_MAC_ADMIN capability. Regarding to may tests the issue is
> > connected to user namespace.
> >
> > I have prepared patch (see below). The patch was tested and
> > created on kernel 3.10.
> >
> > From 1d42d88fccafb7a9fa279588bc827163484a7852 Mon Sep 17 00:00:00
> 2001
> > From: Jacek Pielaszkiewicz
> > Date: Mon, 24 Mar 2014 14:11:58 +0100
> > Subject: [PATCH] [PATCH] Enable user namespace in SMACK
> >
> > SMACK: Enable user namespace
> >
> > - Bug/Issue:
> > The issue has been found when we tried to setup lxc container.
> > We tried to setup the container with active all linux namespaces
> > (including user namespace). On the host as LSM was enabled SMACK.
> >
> > We have found that "systemd" was not able to setup user sessiondue to
> > lack of permissions to write into /proc/self/attr/currentfile.
> >
> > We have found general issue that any privileged process with enabled
> > CAP_MAC_ADMIN cannot write into /proc/self/attr/currentfile.
> >
> > - Cause:
> > SMACK to check the task capabilities uses capable().
> >
> > - Solution:
> > The fix replaces usage capable() by ns_capable().
> >
> > Becuase SMACK uses globally defined rules usage ns_capable() was
> > limited to places where requested by task operation are connected to
> > himself. All operation that modify global SMACK rules remain
> unchanged
> > - SMACK still to test capabilities calls capable(). It means that
> > operation on smackfs remain unchanged - operation are allowed only by
> > host.
> >
> > Change-Id: I0bb28fa02943dd7ccb38dda2c8a37dcce2d551b2
> > Signed-off-by: Jacek Pielaszkiewicz
> > ---
> > security/smack/smack.h| 13 +
> > security/smack/smack_access.c | 2 +-
> > security/smack/smack_lsm.c| 16
> > 3 files changed, 22 insertions(+), 9 deletions(-)
> >
> > diff --git a/security/smack/smack.h b/security/smack/smack.h index
> > d072fd3..9f9d5e7 100644
> > --- a/security/smack/smack.h
> > +++ b/security/smack/smack.h
> > @@ -319,6 +319,19 @@ static inline int smack_privileged(int cap) }
> >
> > /*
> > + * Is the task privileged and allowed to privileged
> > + * by the onlycap rule in user namespace.
> > + */
> > +static inline int smack_privileged_ns(int cap) {
> > + if (!ns_capable(current_user_ns(), cap))
> > + return 0;
>
> As I responded on lxc-devel (sorry I had apparently missed this
> original mail),
>
> This is an often seen, but very wrong, idiom. This check means
> nothing, because any unprivileged user can create a new userns and pass
> this check.
I spent two days thinking how to fix the issue. I also discussed the issue
with
my colleagues. The issue seems not to be trivial.
Generally the SMACK is not ready to support namespaces and definitely
it was designed to work on host only (in root namespace only).
Of course you are right - patch like my cause that any unprivileged process
in his own user namespace can set any label, what from practical
point of view means that "SMACK" is disabled.
>From my perspective the issue is caused by changed that was implemented
in kernel 3.8. From this version and later any process can creates own
user namespace. In the older kernels it was limited to privileged processes.
Perhaps this change should be rollback?
I will be grateful for some ideas how the issue should be resolved.
>
> You're on the right track, but to do this right you'll need to do a bit
> more work. For privilege over an inode, there is inode_capable().
> For the network access, check the userns of the struct net owning the
> socket. etc.
>
> > + if (smack_onlycap == NULL || smack_onlycap ==
> smk_of_current())
> > + return 1;
> > + return 0;
> > +}
> > +
> > +/*
> > * logging functions
> > */
> > #define SMACK_AUDIT_DENIED 0x1
> > diff --git a/security/smack/smack_access.c
> > b/security/smack/smack_access.c index 14293cd..07d25f5 100644
> > --- a/security/smack/smack_access.c
> > +++ b/security/smack/smack_access.c
> > @@ -230,7
Re: [PATCH 2/9] driver: staging: wlan-ng: Removed unnecessary typedefs from hfa384x_usb.c
On Thu, Apr 03, 2014 at 09:11:59AM +0200, Sherif Shehab Aldin wrote:
> Removed unnecessary typedefs from hfa384x_usb.c
>
> Signed-off-by: Sherif Shehab Aldin
> ---
> drivers/staging/wlan-ng/hfa384x_usb.c | 38
> -
> 1 file changed, 18 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
> b/drivers/staging/wlan-ng/hfa384x_usb.c
> index 4c828c2..2a44c79 100644
> --- a/drivers/staging/wlan-ng/hfa384x_usb.c
> +++ b/drivers/staging/wlan-ng/hfa384x_usb.c
> @@ -643,8 +643,8 @@ usbctlx_get_status(const hfa384x_usb_cmdresp_t *cmdresp,
> result->resp2 = le16_to_cpu(cmdresp->resp2);
>
> pr_debug("cmdresult:status=0x%04x resp0=0x%04x resp1=0x%04x
> resp2=0x%04x\n",
> - result->status, result->resp0,
> - result->resp1, result->resp2);
> + result->status, result->resp0,
> + result->resp1, result->resp2);
>
This change has nothing to do with typedefs. I am confused.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/9] driver: staging: wlan-ng: Fixed white spaces issues
On Thu, Apr 03, 2014 at 09:13:29AM +0200, Sherif Shehab Aldin wrote:
> static void hfa384x_usbctlx_resptimerfn(unsigned long data)
> {
> - hfa384x_t *hw = (hfa384x_t *) data;
> + hfa384x_t *hw = (hfa384x_t *)
> unsigned long flags;
>
> spin_lock_irqsave(>ctlxq.lock, flags);
This breaks the build.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] driver: staging: wlan-ng: Removed unnecessary typedefs from hfa384x_usb.c
On Thu, Apr 03, 2014 at 02:25:54AM +0200, Sherif Shehab Aldin wrote: > Removed unnecessary typedefs from hfa384x_usb.c > > Signed-off-by: Sherif Shehab Aldin You've broken this patch set up in a wrong way. It should have just been one patch. Don't introduce a warning and fix it later. The two changes are closely related so they fall under the one thing per patch rule. The subject for this patch is nonsense because it fixes a long line. I can see how you meant is as in you were fixing up the typedef patch that context will be lost in the final git log. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] i2c: add DMA support for freescale i2c driver
On Wed, Mar 26, 2014 at 08:26:27AM +0100, Marek Vasut wrote:
> > > I think we disconnected here, sorry. Why can you not use (i2c_imx->dma !=
> > > NULL) instead of (i2c_imx->use_dma == true) please ?
> >
> > But there are two judge conditions. But only the "i2c_imx->dma", but also
> > whether "i2c_imx_dma_request" success.
> >
> > "i2c_imx->use_dma == true" be equivalent to "i2c_imx->dma != NULL &&
> > !i2c_imx_dma_request()"
>
> + /* Init DMA config if support*/
> + i2c_imx->dma = devm_kzalloc(>dev, sizeof(struct imx_i2c_dma),
> + GFP_KERNEL);
> + if (!i2c_imx->dma) {
> + dev_info(>dev,
> + "can't allocate dma struct faild use dma.\n");
> + i2c_imx->use_dma = false;
> + } else if (i2c_imx_dma_request(i2c_imx, (dma_addr_t)phy_addr)) {
> + dev_info(>dev,
> + "can't request dma chan, faild use dma.\n");
> + i2c_imx->use_dma = false;
> + } else {
> + i2c_imx->use_dma = true;
> + }
>
> OK, looking at this one more time, why don't you wrap the allocation of
> i2c_imx-
> >dma into i2c_imx_dma_request() ? Even better, you can allocate *dma as a
> >local
> variable in i2c_imx_dma_request() and then assign it into i2c_imx->dma only
> at
> the end of the i2c_imx_dma_request() function , at the point where you are
> sure
> nothing failed. Then you can check i2c_imx->dma != NULL throughout the code
> to
> check if the DMA is available, no ?
>
> Shawn, Wolfram, am I talking nonsense or am I just not connecting ?
I'm with you, Marek.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] blk-mq: support for shared tags
On Wed, Apr 02, 2014 at 09:10:12PM -0700, Matias Bjorling wrote: > For the nvme driver, there's a single admin queue, which is outside > blk-mq's control, and the X normal queues. Should we allow the shared > tags structure to be used (get/put) for the admin queue, without > initializing blk-mq? or should the drivers simply implement their own > tags for their admin queue? I'd still create a request_queue for the internal queue, just not register a block device for it. For example SCSI sets up queues for each LUN found, but only a subset actually is exposed as a block device. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] usb: doc: udc-xilinx: Add devicetree bindings
Add devicetree bindings for Xilinx axi udc driver.
Signed-off-by: Subbaraya Sundeep Bhatta
---
Changes for v2:
- replaced xlnx,include-dma with xlnx,has-builtin-dma
.../devicetree/bindings/usb/udc-xilinx.txt | 20
1 files changed, 20 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/udc-xilinx.txt
diff --git a/Documentation/devicetree/bindings/usb/udc-xilinx.txt
b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
new file mode 100644
index 000..7c24fac
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
@@ -0,0 +1,20 @@
+Xilinx AXI USB2 device controller
+
+Required properties:
+- compatible : Should be "xlnx,axi-usb2-device-4.00.a"
+- reg : Physical base address and size of the Axi USB2
+ device registers map.
+- interrupts : Property with a value describing the interrupt
+ number.
+- interrupt-parent : Must be core interrupt controller
+- xlnx,has-builtin-dma : if DMA is included
+
+Example:
+ axi-usb2-device@42e0 {
+compatible = "xlnx,axi-usb2-device-4.00.a";
+interrupt-parent = <0x1>;
+interrupts = <0x0 0x39 0x1>;
+reg = <0x42e0 0x1>;
+xlnx,has-builtin-dma;
+};
+
--
1.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] i2c: Add driver for Cadence I2C controller
On 04/03/2014 09:10 AM, Wolfram Sang wrote:
>
> Please don't quote large parts of the message f you are not referring to
> it.
Normally I do it. Forgot sorry.
>>> +#ifdef CONFIG_PM_SLEEP
>>> +/**
>>> + * cdns_i2c_suspend - Suspend method for the driver
>>> + * @_dev: Address of the platform_device structure
>>> + * Return: 0 always
>>> + *
>>> + * Put the driver into low power mode.
>>> + */
>>> +static int cdns_i2c_suspend(struct device *_dev)
>>> +{
>>> + struct platform_device *pdev = container_of(_dev,
>>> + struct platform_device, dev);
>>> + struct cdns_i2c *xi2c = platform_get_drvdata(pdev);
>>> +
>>> + clk_disable(xi2c->clk);
>>> + xi2c->suspended = 1;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/**
>>> + * cdns_i2c_resume - Resume from suspend
>>> + * @_dev: Address of the platform_device structure
>>> + * Return: 0 on success and error value on error
>>> + *
>>> + * Resume operation after suspend.
>>> + */
>>> +static int cdns_i2c_resume(struct device *_dev)
>>> +{
>>> + struct platform_device *pdev = container_of(_dev,
>>> + struct platform_device, dev);
>>> + struct cdns_i2c *xi2c = platform_get_drvdata(pdev);
>>> + int ret;
>>> +
>>> + ret = clk_enable(xi2c->clk);
>>> + if (ret) {
>>> + dev_err(_dev, "Cannot enable clock.\n");
>>> + return ret;
>>> + }
>>> +
>>> + xi2c->suspended = 0;
>>> +
>>> + return 0;
>>> +}
>>> +#endif
>>
>> Can you also please remove this #ifdef and use __maybe_used
>> instead? Better not to have any ifdef in the code.
>
> Is this a new pattern? For PM_SLEEP, #ifdef seems to be quite common.
The first suggestion to do it came from CAN maintainer.
It is valid in general for ifdef.
I have checked all our drivers and we are changing them to use __maybe_used
because then we can easily find out if there is any problem
when function prototype has changed.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
[GIT PULL] GPIO bulk changes for v3.15
Hi Linus, this is the bulk of GPIO changes for the v3.15 merge window. Note: - This tree has pulled in an immutable branch with some irqchip infrastructure from Thomas Gleixner. This stuff is already in your tree coming in from tip. However as this pull request is based on v3.14-rc6 you will still see the commits in this pull request, but it should be all right. (Else beat me up as usual.) I tested to pull it in on top of your master and it LooksGoodToMe(TM) - Some changes hit the pin control tree, but have been funneled through this one tree to avoid fuzz and conflicts. A pretty big chunk of changes this time, but it has all been on rotation in linux-next and had some testing. Of course there will be some amount of fixes on top... The rest of the story is in the signed tag. Please pull it in! Yours, Linus Walleij The following changes since commit fa389e220254c69ffae0d403eac4146171062d08: Linux 3.14-rc6 (2014-03-09 19:41:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-v3.15-1 for you to fetch changes up to b22978fc33dec72e5f8e17f90eb63ea9137aafd5: gpio: rcar: Add helper variable dev = >dev (2014-03-28 21:54:41 +0100) This is the bulk of GPIO changes for v3.15: - Merged in a branch of irqchip changes from Thomas Gleixner: we need to have new callbacks from the irqchip to determine if the GPIO line will be eligible for IRQs, and this callback must be able to say "no". After some thinking I got the branch from tglx and have switched all current users over to use this. - Based on tglx patches, we have added some generic irqchip helpers in the gpiolib core. These will help centralize code when GPIO drivers have simple chained/cascaded IRQs. Drivers will still define their irqchip vtables, but the gpiolib core will take care of irqdomain set-up, mapping from local offsets to Linux irqs, and reserve resources by marking the GPIO lines for IRQs. - Initially the PL061 and Nomadik GPIO/pin control drivers have been switched over to use the new gpiochip-to-irqchip infrastructure with more drivers expected for the next kernel cycle. The factoring of just two drivers still makes it worth it so it is already a win. - A new driver for the Synopsys DesignWare APB GPIO block. - Modify the DaVinci GPIO driver to be reusable also for the new TI Keystone architecture. - A new driver for the LSI ZEVIO SoCs. - Delete the obsolte tnetv107x driver. - Some incremental work on GPIO descriptors: have gpiod_direction_output() use a logical level, respecting assertion polarity through ACTIVE_LOW flags, adding gpiod_direction_output_raw() for the case where you want to set that very value. Add gpiochip_get_desc() to fetch a GPIO descriptor from a specific offset on a certain chip inside driver code. - Switch ACPI GPIO code over to using gpiochip_get_desc() and get rid of gpio_to_desc(). - The ACPI GPIO event handling code has been reworked after encountering an actual real life implementation. - Support for ACPI GPIO operation regions. - Generic GPIO chips can now be assigned labels/names from platform data. - We now clamp values returned from GPIO drivers to the boolean [0,1] range. - Some improved documentation on how to use the polarity flag was added. - The a large slew of incremental driver updates and non-critical fixes. Some targeted for stable. Aaron Sierra (4): gpio: pca953x: Add devices to Kconfig help gpio: pca953x: Add NXP PCA9698 gpio: pca953x: Add Exar XRA1202 gpio: pca953x: Fix gpio_base may not default to -1 Alan Tull (2): fix build error in gpio-dwapb patch gpio: gpio-dwapb size-cells should be two Alexander Holler (1): gpio: davinci: fix gpio selection for OF Alexander Shiyan (6): gpio: davinci: Use signed type for 'irq' variable gpio: rc5t583: Remove redundant check gpio: generic: Use platform_device_id->driver_data field for driver flags gpio: Driver for SYSCON-based GPIOs gpio: twl4030: Remove redundant assignment gpio: samsung: Add missing "break" statement Alexandre Courbot (3): gpiolib: add gpiochip_get_desc() driver function gpiolib: ACPI: remove gpio_to_desc() usage gpio: clamp returned values to the boolean range Arnd Bergmann (1): gpio: remove obsolete tnetv107x driver Axel Lin (4): gpio: pl061: Select IRQ_DOMAIN rather than GENERIC_IRQ_CHIP gpio: clps711x: Add missing .owner to struct gpio_chip gpio: moxart: Avoid forward declaration gpio: moxart: Actually set output state in moxart_gpio_direction_output() Bartlomiej Zolnierkiewicz (1): gpio: iop: fix devm_ioremap_resource() return value checking Daniel Krueger (1): pch_gpio: set value before
[patch] irqchip/irq-crossbar: not allocating enough memory
We are allocating the size of a pointer and not the size of the data.
This will lead to memory corruption.
There isn't actually a "cb_device" struct, btw. The code is only able
to compile because GCC knows that all pointers are the same size.
Fixes: 96ca848ef7ea ('DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP')
Signed-off-by: Dan Carpenter
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index fc817d2..3d15d16 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -107,7 +107,7 @@ static int __init crossbar_of_init(struct device_node *node)
int i, size, max, reserved = 0, entry;
const __be32 *irqsr;
- cb = kzalloc(sizeof(struct cb_device *), GFP_KERNEL);
+ cb = kzalloc(sizeof(*cb), GFP_KERNEL);
if (!cb)
return -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 regression] net: phy: fix initialization (config_init) for Marvel 88E1116R PHYs
Am 03.04.2014 00:27, schrieb Sebastian Hesselbarth: On 04/03/2014 12:12 AM, Alexander Holler wrote: I am curious, how you determined above commit to be the cause of the regression you are seeing. Can you bisect, if you didn't already? There was no bisecting necessary. I've just looked at what changed in mv643xx_eth since 3.13 and the first commit I've reverted was already a hit. Reading a bit source revealed the differences between the old reset and the newly used one and ended up with my patch (first try) and was a hit too. Honestly, your own fix changes a different driver than mv643xx_eth. It changes stuff which now (through the mentioned commit) gets used through the change in mv643xx_eth. There is a lot of changes from v3.13 to v3.14 and bisecting really helps to pin-point the one offending patch. As you can see from my tests with Dockstar, poking in the PHY driver may not be the right place to fix it. Actually I assumed the reset needs longer than the 500ms, but as the printks revealed, the reset is much faster. So the problem seems to be the much increased time (1s) the newly used reset function idles in mdelay. You assume that the PHY issue comes from waiting for too long _after_ the reset? And again, the very same PHY on Dockstar is not affected. Guess with which hardware I'm experiencing this problem? Hint: http://ahsoftware.de/dockstar/ ;) But I think I have found the real reason. and the change of the reset just increased the chance the problem is hit (here with 100% success or fail rate however you want to name it). Just give me a day or two to find the time to verify my assumption (I don't want to speculate) and maybe find a real fix for the problem. Of course, I still like my patch because it greatly decreases the time necessary for a reset (and the chance to hit the problem). Well, you can share your idea anytime. You already speculated that PHY reset on 88e1116r is broken but it seems that is not true. The more you share of your issue and the tries to fix it, the more likely is it we can follow your patch immediately. Sorry, but wild speculating doesn't help always. Otherwise I could mention several dozen possible reasons, starting from broken memory or other hw up to some memory corruption elsewhere in the kernel. But I already have given a hint before, try what happens if you enable netconsole (compiled in) through the kernel commandline (netconsole=...). Maybe the ethernet on your dockstar will get stuck too. Again, if you really want to find the real patch breaking Sheevaplug, use git bisect. That's silly if I already know a/the change which brings the problem to light. If I revert the mentioned commit the problem disapears. So why should I go through the pain to bisect stuff? I already have found the knob to kill the ethernet on that machine. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
On 04/03/2014 12:35 AM, Vinod Koul wrote:
On Mon, Mar 31, 2014 at 12:08:55PM +0800, Hongbo Zhang wrote:
On 03/29/2014 09:45 PM, Vinod Koul wrote:
On Fri, Mar 28, 2014 at 02:33:37PM +0800, Hongbo Zhang wrote:
On 03/26/2014 03:01 PM, Vinod Koul wrote:
On Thu, 2014-01-16 at 13:47 +0800, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
The usage of spin_lock_irqsave() is a stronger locking mechanism than is
required throughout the driver. The minimum locking required should be used
instead. Interrupts will be turned off and context will be saved, it is
unnecessary to use irqsave.
This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
manipulation of protected fields is done using tasklet context or weaker, which
makes spin_lock_bh() the correct choice.
/**
@@ -1124,11 +1120,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
static void dma_do_tasklet(unsigned long data)
{
struct fsldma_chan *chan = (struct fsldma_chan *)data;
- unsigned long flags;
chan_dbg(chan, "tasklet entry\n");
- spin_lock_irqsave(>desc_lock, flags);
+ spin_lock_bh(>desc_lock);
okay here is the problem :(
You moved to _bh variant. So if you grab the lock in rest of the code
and irq gets triggered then here we will be spinning to grab the lock.
So effectively you made right locking solution into deadlock situation!
If the rest code grabs lock by spin_lock_bh(), and if irq raised,
the tasklet could not be executed because it has been disabled by
the _bh variant function.
yes if you are accessing resources only in tasklet and rest of the code, then
_bh variant works well. The problem here is usage in irq handler
The name dma_do_tasklet may mislead, it is tasklet handler, not irq
handler, not a trigger to load tasklet.
the irq handler is fsldma_chan_irq, and I don't use lock in it.
sorry my bad, i misread this as code in fsldma_chan_irq() insteadof
dma_do_tasklet(). In that case patch is doing the right thing.
OK, so I will send a v2 series with only updating 3/7 soon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/9] driver: staging: wlan-ng: Removed multiple assignments
Removed multiple assignments from hfa384x_usb.c
Signed-off-by: Sherif Shehab Aldin
---
drivers/staging/wlan-ng/hfa384x_usb.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 64b51b7..777b1e7 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -2600,7 +2600,8 @@ int hfa384x_drvr_start(hfa384x_t *hw)
*/
result1 = hfa384x_cmd_initialize(hw);
msleep(1000);
- result = result2 = hfa384x_cmd_initialize(hw);
+ result = hfa384x_cmd_initialize(hw);
+ result2 = result;
if (result1 != 0) {
if (result2 != 0) {
netdev_err(hw->wlandev->netdev,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] driver: staging: wlan-ng: Removed #if 0 lines from hfa384x_usb.c
Removed lines that were ignored by #if 0
Signed-off-by: Sherif Shehab Aldin
---
drivers/staging/wlan-ng/hfa384x_usb.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 777b1e7..4e9df48 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -2021,11 +2021,6 @@ int hfa384x_drvr_flashdl_write(hfa384x_t *hw, u32 daddr,
void *buf, u32 len)
pr_debug("dlbuf.page=0x%04x dlbuf.offset=0x%04x dlbufaddr=0x%08x\n",
hw->bufinfo.page, hw->bufinfo.offset, dlbufaddr);
-#if 0
- netdev_warn(hw->wlandev->netdev,
- "dlbuf@0x%06lx len=%d to=%d\n", dlbufaddr,
- hw->bufinfo.len, hw->dltimeout);
-#endif
/* Calculations to determine how many fills of the dlbuffer to do
* and how many USB wmemreq's to do for each fill. At this point
* in time, the dlbuffer size and the wmemreq size are the same.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] driver: staging: wlan-ng: Setting character pointers as const
changed declaration of ctlx_str to:
static const char * const ctlx_str[]
Signed-off-by: Sherif Shehab Aldin
---
drivers/staging/wlan-ng/hfa384x_usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index a389cef..65e59a3 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -272,7 +272,7 @@ static int hfa384x_isgood_pdrcode(u16 pdrcode);
static inline const char *ctlxstr(CTLX_STATE s)
{
- static const char *ctlx_str[] = {
+ static const char * const ctlx_str[] = {
"Initial state",
"Complete",
"Request failed",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] driver: staging: wlan-ng: switched to pr_warn
changed printk(KERN_WARNING .. to pr_warn
Signed-off-by: Sherif Shehab Aldin
---
drivers/staging/wlan-ng/hfa384x_usb.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 2a44c79..a389cef 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -715,10 +715,9 @@ static int usbctlx_rrid_completor_fn(struct
usbctlx_completor *head)
/* Validate the length, note body len calculation in bytes */
if (rridresult.riddata_len != complete->riddatalen) {
- printk(KERN_WARNING
- "RID len mismatch, rid=0x%04x hlen=%d fwlen=%d\n",
- rridresult.rid,
- complete->riddatalen, rridresult.riddata_len);
+ pr_warn("RID len mismatch, rid=0x%04x hlen=%d fwlen=%d\n",
+ rridresult.rid,
+ complete->riddatalen, rridresult.riddata_len);
return -ENODATA;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] driver: staging: wlan-ng: Fixed Alignment to match open parenthesis
Fixed Alignment to match open parenthesis in hfa384x_usb.c
Signed-off-by: Sherif Shehab Aldin
---
drivers/staging/wlan-ng/hfa384x_usb.c | 113 +
1 file changed, 59 insertions(+), 54 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 26289c6..4b11ed7 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -350,14 +350,14 @@ static int submit_rx_urb(hfa384x_t *hw, gfp_t memflags)
result = -ENOLINK;
if (!hw->wlandev->hwremoved &&
- !test_bit(WORK_RX_HALT, >usb_flags)) {
+ !test_bit(WORK_RX_HALT, >usb_flags)) {
result = SUBMIT_URB(>rx_urb, memflags);
/* Check whether we need to reset the RX pipe */
if (result == -EPIPE) {
netdev_warn(hw->wlandev->netdev,
- "%s rx pipe stalled: requesting reset\n",
- hw->wlandev->netdev->name);
+ "%s rx pipe stalled: requesting reset\n",
+ hw->wlandev->netdev->name);
if (!test_and_set_bit(WORK_RX_HALT, >usb_flags))
schedule_work(>usb_work);
}
@@ -406,8 +406,8 @@ static int submit_tx_urb(hfa384x_t *hw, struct urb *tx_urb,
gfp_t memflags)
/* Test whether we need to reset the TX pipe */
if (result == -EPIPE) {
netdev_warn(hw->wlandev->netdev,
- "%s tx pipe stalled: requesting reset\n",
- netdev->name);
+ "%s tx pipe stalled: requesting
reset\n",
+ netdev->name);
set_bit(WORK_TX_HALT, >usb_flags);
schedule_work(>usb_work);
} else if (result == 0) {
@@ -455,11 +455,11 @@ static void hfa384x_usb_defer(struct work_struct *data)
ret = usb_clear_halt(hw->usb, hw->endp_in);
if (ret != 0) {
netdev_err(hw->wlandev->netdev,
- "Failed to clear rx pipe for %s: err=%d\n",
- netdev->name, ret);
+ "Failed to clear rx pipe for %s: err=%d\n",
+ netdev->name, ret);
} else {
netdev_info(hw->wlandev->netdev, "%s rx pipe reset
complete.\n",
- netdev->name);
+ netdev->name);
clear_bit(WORK_RX_HALT, >usb_flags);
set_bit(WORK_RX_RESUME, >usb_flags);
}
@@ -472,7 +472,8 @@ static void hfa384x_usb_defer(struct work_struct *data)
ret = submit_rx_urb(hw, GFP_KERNEL);
if (ret != 0) {
netdev_err(hw->wlandev->netdev,
- "Failed to resume %s rx pipe.\n", netdev->name);
+ "Failed to resume %s rx pipe.\n",
+ netdev->name);
} else {
clear_bit(WORK_RX_RESUME, >usb_flags);
}
@@ -486,11 +487,11 @@ static void hfa384x_usb_defer(struct work_struct *data)
ret = usb_clear_halt(hw->usb, hw->endp_out);
if (ret != 0) {
netdev_err(hw->wlandev->netdev,
- "Failed to clear tx pipe for %s: err=%d\n",
- netdev->name, ret);
+ "Failed to clear tx pipe for %s: err=%d\n",
+ netdev->name, ret);
} else {
netdev_info(hw->wlandev->netdev, "%s tx pipe reset
complete.\n",
- netdev->name);
+ netdev->name);
clear_bit(WORK_TX_HALT, >usb_flags);
set_bit(WORK_TX_RESUME, >usb_flags);
@@ -1207,7 +1208,7 @@ int hfa384x_corereset(hfa384x_t *hw, int holdtime, int
settletime, int genesis)
result = usb_reset_device(hw->usb);
if (result < 0) {
netdev_err(hw->wlandev->netdev, "usb_reset_device() failed,
result=%d.\n",
- result);
+ result);
}
return result;
@@ -1307,7 +1308,7 @@ cleanup:
result = completor->complete(completor);
} else {
netdev_warn(hw->wlandev->netdev, "CTLX[%d] error:
state(%s)\n",
- le16_to_cpu(ctlx->outbuf.type),
+ le16_to_cpu(ctlx->outbuf.type),
[PATCH 7/9] driver: staging: wlan-ng: Fixed white spaces issues
In hfa384x_usb.c:
Fixed allignment issues after open braces
Moved Logical continuations to the correct lines
Removed unnecessary blank lines
Signed-off-by: Sherif Shehab Aldin
---
drivers/staging/wlan-ng/hfa384x_usb.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 4b11ed7..64b51b7 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -398,9 +398,8 @@ static int submit_tx_urb(hfa384x_t *hw, struct urb *tx_urb,
gfp_t memflags)
result = -ENOLINK;
if (netif_running(netdev)) {
-
- if (!hw->wlandev->hwremoved
- && !test_bit(WORK_TX_HALT, >usb_flags)) {
+ if (!hw->wlandev->hwremoved &&
+ !test_bit(WORK_TX_HALT, >usb_flags)) {
result = SUBMIT_URB(tx_urb, memflags);
/* Test whether we need to reset the TX pipe */
@@ -657,7 +656,6 @@ usbctlx_get_rridresult(const hfa384x_usb_rridresp_t
*rridresp,
result->rid = le16_to_cpu(rridresp->rid);
result->riddata = rridresp->data;
result->riddata_len = ((le16_to_cpu(rridresp->frmlen) - 1) * 2);
-
}
/*
@@ -676,7 +674,7 @@ static inline int usbctlx_cmd_completor_fn(struct
usbctlx_completor *head)
{
struct usbctlx_cmd_completor *complete;
- complete = (struct usbctlx_cmd_completor *) head;
+ complete = (struct usbctlx_cmd_completor *)head;
return usbctlx_get_status(complete->cmdresp, complete->result);
}
@@ -711,7 +709,7 @@ static int usbctlx_rrid_completor_fn(struct
usbctlx_completor *head)
struct usbctlx_rrid_completor *complete;
hfa384x_rridresult_t rridresult;
- complete = (struct usbctlx_rrid_completor *) head;
+ complete = (struct usbctlx_rrid_completor *)head;
usbctlx_get_rridresult(complete->rridresp, );
/* Validate the length, note body len calculation in bytes */
@@ -2827,7 +2825,7 @@ void hfa384x_tx_timeout(wlandevice_t *wlandev)
*/
static void hfa384x_usbctlx_reaper_task(unsigned long data)
{
- hfa384x_t *hw = (hfa384x_t *) data;
+ hfa384x_t *hw = (hfa384x_t *)data;
struct list_head *entry;
struct list_head *temp;
unsigned long flags;
@@ -2846,7 +2844,6 @@ static void hfa384x_usbctlx_reaper_task(unsigned long
data)
}
spin_unlock_irqrestore(>ctlxq.lock, flags);
-
}
/*
@@ -2865,7 +2862,7 @@ static void hfa384x_usbctlx_reaper_task(unsigned long
data)
*/
static void hfa384x_usbctlx_completion_task(unsigned long data)
{
- hfa384x_t *hw = (hfa384x_t *) data;
+ hfa384x_t *hw = (hfa384x_t *)data;
struct list_head *entry;
struct list_head *temp;
unsigned long flags;
@@ -3137,7 +3134,7 @@ static void hfa384x_usbin_callback(struct urb *urb)
{
wlandevice_t *wlandev = urb->context;
hfa384x_t *hw;
- hfa384x_usbin_t *usbin = (hfa384x_usbin_t *) urb->transfer_buffer;
+ hfa384x_usbin_t *usbin = (hfa384x_usbin_t *)urb->transfer_buffer;
struct sk_buff *skb = NULL;
int result;
int urb_status;
@@ -3465,7 +3462,7 @@ static void hfa384x_usbin_txcompl(wlandevice_t *wlandev,
*/
static void hfa384x_usbin_rx(wlandevice_t *wlandev, struct sk_buff *skb)
{
- hfa384x_usbin_t *usbin = (hfa384x_usbin_t *) skb->data;
+ hfa384x_usbin_t *usbin = (hfa384x_usbin_t *)skb->data;
hfa384x_t *hw = wlandev->priv;
int hdrlen;
struct p80211_rxmeta *rxmeta;
@@ -3610,7 +3607,7 @@ static void hfa384x_int_rxmonitor(wlandevice_t *wlandev,
struct p80211_caphdr *caphdr;
/* The NEW header format! */
datap = skb_put(skb, sizeof(struct p80211_caphdr));
- caphdr = (struct p80211_caphdr *) datap;
+ caphdr = (struct p80211_caphdr *)datap;
caphdr->version = htonl(P80211CAPTURE_VERSION);
caphdr->length = htonl(sizeof(struct p80211_caphdr));
@@ -3707,7 +3704,6 @@ static void hfa384x_usbout_callback(struct urb *urb)
#endif
if (wlandev && wlandev->netdev) {
-
switch (urb->status) {
case 0:
hfa384x_usbout_tx(wlandev, usbout);
@@ -3733,8 +3729,8 @@ static void hfa384x_usbout_callback(struct urb *urb)
hfa384x_t *hw = wlandev->priv;
if (!test_and_set_bit
- (THROTTLE_TX, >usb_flags)
- &&
[PATCH 5/9] driver: staging: wlan-ng: Removed Unnecessary space after function pointer name
Removed Unnecessary space after function pointer name
Signed-off-by: Sherif Shehab Aldin
---
drivers/staging/wlan-ng/hfa384x_usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 65e59a3..26289c6 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -203,7 +203,7 @@ static int hfa384x_usbctlx_submit(hfa384x_t *hw,
hfa384x_usbctlx_t *ctlx);
static void unlocked_usbctlx_complete(hfa384x_t *hw, hfa384x_usbctlx_t *ctlx);
struct usbctlx_completor {
- int (*complete) (struct usbctlx_completor *);
+ int (*complete)(struct usbctlx_completor *);
};
static int
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND] drivercore: deferral race condition fix
When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need for external event to kick the deferred queue to probe
these drivers.
The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
audio support built as modules and using nfsroot for root filesystem.
The following log fragment shows such sequence when all audio modules
were loaded but the sound card is not present since the machine driver has
failed to probe due to missing dependency during it's probe.
The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
machine driver:
...
[ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
[ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
[ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
[ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe:
snd_soc_register_component
[ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe:
snd_soc_register_component DONE
[ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
[ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
DONE (-517)
[ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
[ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
[ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
[ 13.346755] davinci_mcasp_driver_init: LEAVE
[ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral
[ 13.592527] platform sound.3: really_probe: probe_count = 0
In the log the machine driver enters it's probe at 12.719969 (this point it
has been removed from the deferred lists). McASP driver already executing
it's probing (since 12.615118).
The machine driver tries to construct the sound card (12.950839) but did
not found one of the components so it fails. After this McASP driver
registers all the ASoC components (the machine driver still in it's probe
function after it failed to construct the card) and the deferred work is
prepared at 13.099026 (note that this time the machine driver is not in the
lists so it is not going to be handled when the work is executing).
Lastly the machine driver exit from it's probe and the core places it to
the deferred list but there will be no other driver going to load and the
deferred queue is not going to be kicked again - till we have external event
like connecting USB stick, etc.
The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers loaded while this last
driver was probing.
This way we can avoid drivers stuck in the deferred queue.
Signed-off-by: Peter Ujfalusi
---
drivers/base/dd.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 06051767393f..80703de6e6ad 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -53,6 +53,10 @@ static LIST_HEAD(deferred_probe_pending_list);
static LIST_HEAD(deferred_probe_active_list);
static struct workqueue_struct *deferred_wq;
+static atomic_t probe_count = ATOMIC_INIT(0);
+static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
+static bool deferral_retry;
+
/**
* deferred_probe_work_func() - Retry probing devices in the active list.
*/
@@ -141,6 +145,11 @@ static void driver_deferred_probe_trigger(void)
if (!driver_deferred_probe_enable)
return;
+ if (atomic_read(_count) > 1)
+ deferral_retry = true;
+ else
+ deferral_retry = false;
+
/*
* A successful probe means that all the devices in the pending list
* should be triggered to be reprobed. Move all the deferred devices
@@ -259,9 +268,6 @@ int device_bind_driver(struct device *dev)
}
EXPORT_SYMBOL_GPL(device_bind_driver);
-static atomic_t probe_count = ATOMIC_INIT(0);
-static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
-
static int really_probe(struct device *dev, struct device_driver *drv)
{
int ret = 0;
@@ -310,6 +316,16 @@ probe_failed:
/* Driver requested deferred probing */
dev_info(dev, "Driver %s requests probe deferral\n", drv->name);
driver_deferred_probe_add(dev);
+ /*
+* This is the last driver to load and asking to be deferred.
+* If other driver(s) loaded while this driver was loading, we
+* should try the deferred modules again to avoid missing
+* dependency for this driver.
+*/
+ if (atomic_read(_count) == 1 && deferral_retry) {
+ deferral_retry = false;
+ driver_deferred_probe_trigger();
+ }
} else if (ret != -ENODEV && ret != -ENXIO) {
/* driver matched but the probe failed */
[PATCH 2/9] driver: staging: wlan-ng: Removed unnecessary typedefs from hfa384x_usb.c
Removed unnecessary typedefs from hfa384x_usb.c
Signed-off-by: Sherif Shehab Aldin
---
drivers/staging/wlan-ng/hfa384x_usb.c | 38 -
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 4c828c2..2a44c79 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -643,8 +643,8 @@ usbctlx_get_status(const hfa384x_usb_cmdresp_t *cmdresp,
result->resp2 = le16_to_cpu(cmdresp->resp2);
pr_debug("cmdresult:status=0x%04x resp0=0x%04x resp1=0x%04x
resp2=0x%04x\n",
- result->status, result->resp0,
- result->resp1, result->resp2);
+result->status, result->resp0,
+result->resp1, result->resp2);
return result->status & HFA384x_STATUS_RESULT;
}
@@ -745,14 +745,12 @@ static inline struct usbctlx_completor
*init_rrid_completor(
* Completor object:
* Interprets the results of a synchronous RID-write
*/
-typedef struct usbctlx_cmd_completor usbctlx_wrid_completor_t;
#define init_wrid_completor init_cmd_completor
/*
* Completor object:
* Interprets the results of a synchronous memory-write
*/
-typedef struct usbctlx_cmd_completor usbctlx_wmem_completor_t;
#define init_wmem_completor init_cmd_completor
/*
@@ -766,11 +764,11 @@ struct usbctlx_rmem_completor {
void *data;
unsigned int len;
};
-typedef struct usbctlx_rmem_completor usbctlx_rmem_completor_t;
static int usbctlx_rmem_completor_fn(struct usbctlx_completor *head)
{
- usbctlx_rmem_completor_t *complete = (usbctlx_rmem_completor_t *) head;
+ struct usbctlx_rmem_completor *complete =
+ (struct usbctlx_rmem_completor *)head;
pr_debug("rmemresp:len=%d\n", complete->rmemresp->frmlen);
memcpy(complete->data, complete->rmemresp->data, complete->len);
@@ -778,7 +776,7 @@ static int usbctlx_rmem_completor_fn(struct
usbctlx_completor *head)
}
static inline struct usbctlx_completor *init_rmem_completor(
- usbctlx_rmem_completor_t
+ struct usbctlx_rmem_completor
*completor,
hfa384x_usb_rmemresp_t
*rmemresp,
@@ -1380,7 +1378,7 @@ hfa384x_docmd(hfa384x_t *hw,
ctlx->outbufsize = sizeof(ctlx->outbuf.cmdreq);
pr_debug("cmdreq: cmd=0x%04x parm0=0x%04x parm1=0x%04x parm2=0x%04x\n",
- cmd->cmd, cmd->parm0, cmd->parm1, cmd->parm2);
+cmd->cmd, cmd->parm0, cmd->parm1, cmd->parm2);
ctlx->reapable = mode;
ctlx->cmdcb = cmdcb;
@@ -1563,7 +1561,7 @@ hfa384x_dowrid(hfa384x_t *hw,
if (result != 0) {
kfree(ctlx);
} else if (mode == DOWAIT) {
- usbctlx_wrid_completor_t completor;
+ struct usbctlx_cmd_completor completor;
hfa384x_cmdresult_t wridresult;
result = hfa384x_usbctlx_complete_sync(hw,
@@ -1655,7 +1653,7 @@ hfa384x_dormem(hfa384x_t *hw,
if (result != 0) {
kfree(ctlx);
} else if (mode == DOWAIT) {
- usbctlx_rmem_completor_t completor;
+ struct usbctlx_rmem_completor completor;
result =
hfa384x_usbctlx_complete_sync(hw, ctlx,
@@ -1745,7 +1743,7 @@ hfa384x_dowmem(hfa384x_t *hw,
if (result != 0) {
kfree(ctlx);
} else if (mode == DOWAIT) {
- usbctlx_wmem_completor_t completor;
+ struct usbctlx_cmd_completor completor;
hfa384x_cmdresult_t wmemresult;
result = hfa384x_usbctlx_complete_sync(hw,
@@ -2016,7 +2014,7 @@ int hfa384x_drvr_flashdl_write(hfa384x_t *hw, u32 daddr,
void *buf, u32 len)
return -EINVAL;
netdev_info(hw->wlandev->netdev,
- "Download %d bytes to flash @0x%06x\n", len, daddr);
+ "Download %d bytes to flash @0x%06x\n", len, daddr);
/* Convert to flat address for arithmetic */
/* NOTE: dlbuffer RID stores the address in AUX format */
@@ -2027,8 +2025,8 @@ int hfa384x_drvr_flashdl_write(hfa384x_t *hw, u32 daddr,
void *buf, u32 len)
#if 0
netdev_warn(hw->wlandev->netdev,
- "dlbuf@0x%06lx len=%d to=%d\n", dlbufaddr,
- hw->bufinfo.len, hw->dltimeout);
+ "dlbuf@0x%06lx len=%d to=%d\n", dlbufaddr,
+
[PATCH 1/9] driver: staging: wlan-ng: Fixed Breaking long lines and strings style rule
Fixed coding style rule "Breaking long lines and strings" for hfa384x_usb.c
Signed-off-by: Sherif Shehab Aldin
---
drivers/staging/wlan-ng/hfa384x_usb.c | 52 -
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 5b8b094..4c828c2 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -642,9 +642,9 @@ usbctlx_get_status(const hfa384x_usb_cmdresp_t *cmdresp,
result->resp1 = le16_to_cpu(cmdresp->resp1);
result->resp2 = le16_to_cpu(cmdresp->resp2);
- pr_debug("cmdresult:status=0x%04x "
-"resp0=0x%04x resp1=0x%04x resp2=0x%04x\n",
-result->status, result->resp0, result->resp1, result->resp2);
+ pr_debug("cmdresult:status=0x%04x resp0=0x%04x resp1=0x%04x
resp2=0x%04x\n",
+ result->status, result->resp0,
+ result->resp1, result->resp2);
return result->status & HFA384x_STATUS_RESULT;
}
@@ -991,9 +991,7 @@ int hfa384x_cmd_initialize(hfa384x_t *hw)
result = hfa384x_docmd_wait(hw, );
- pr_debug("cmdresp.init: "
-"status=0x%04x, resp0=0x%04x, "
-"resp1=0x%04x, resp2=0x%04x\n",
+ pr_debug("cmdresp.init: status=0x%04x, resp0=0x%04x, resp1=0x%04x,
resp2=0x%04x\n",
cmd.result.status,
cmd.result.resp0, cmd.result.resp1, cmd.result.resp2);
if (result == 0) {
@@ -1381,9 +1379,8 @@ hfa384x_docmd(hfa384x_t *hw,
ctlx->outbufsize = sizeof(ctlx->outbuf.cmdreq);
- pr_debug("cmdreq: cmd=0x%04x "
-"parm0=0x%04x parm1=0x%04x parm2=0x%04x\n",
-cmd->cmd, cmd->parm0, cmd->parm1, cmd->parm2);
+ pr_debug("cmdreq: cmd=0x%04x parm0=0x%04x parm1=0x%04x parm2=0x%04x\n",
+ cmd->cmd, cmd->parm0, cmd->parm1, cmd->parm2);
ctlx->reapable = mode;
ctlx->cmdcb = cmdcb;
@@ -2018,7 +2015,8 @@ int hfa384x_drvr_flashdl_write(hfa384x_t *hw, u32 daddr,
void *buf, u32 len)
if (hw->dlstate != HFA384x_DLSTATE_FLASHENABLED)
return -EINVAL;
- netdev_info(hw->wlandev->netdev, "Download %d bytes to flash
@0x%06x\n", len, daddr);
+ netdev_info(hw->wlandev->netdev,
+ "Download %d bytes to flash @0x%06x\n", len, daddr);
/* Convert to flat address for arithmetic */
/* NOTE: dlbuffer RID stores the address in AUX format */
@@ -2028,8 +2026,9 @@ int hfa384x_drvr_flashdl_write(hfa384x_t *hw, u32 daddr,
void *buf, u32 len)
hw->bufinfo.page, hw->bufinfo.offset, dlbufaddr);
#if 0
- netdev_warn(hw->wlandev->netdev, "dlbuf@0x%06lx len=%d to=%d\n",
dlbufaddr,
- hw->bufinfo.len, hw->dltimeout);
+ netdev_warn(hw->wlandev->netdev,
+ "dlbuf@0x%06lx len=%d to=%d\n", dlbufaddr,
+ hw->bufinfo.len, hw->dltimeout);
#endif
/* Calculations to determine how many fills of the dlbuffer to do
* and how many USB wmemreq's to do for each fill. At this point
@@ -2062,9 +2061,9 @@ int hfa384x_drvr_flashdl_write(hfa384x_t *hw, u32 daddr,
void *buf, u32 len)
result = hfa384x_cmd_download(hw, HFA384x_PROGMODE_NV,
burnlo, burnhi, burnlen);
if (result) {
- netdev_err(hw->wlandev->netdev,
"download(NV,lo=%x,hi=%x,len=%x) "
- "cmd failed, result=%d. Aborting d/l\n",
- burnlo, burnhi, burnlen, result);
+ netdev_err(hw->wlandev->netdev,
+ "download(NV,lo=%x,hi=%x,len=%x) cmd
failed, result=%d. Aborting d/l\n",
+ burnlo, burnhi, burnlen, result);
goto exit_proc;
}
@@ -2095,8 +2094,7 @@ int hfa384x_drvr_flashdl_write(hfa384x_t *hw, u32 daddr,
void *buf, u32 len)
0, 0, 0);
if (result) {
netdev_err(hw->wlandev->netdev,
- "download(NVWRITE,lo=%x,hi=%x,len=%x) "
- "cmd failed, result=%d. Aborting d/l\n",
+ "download(NVWRITE,lo=%x,hi=%x,len=%x) cmd
failed, result=%d. Aborting d/l\n",
burnlo, burnhi, burnlen, result);
goto exit_proc;
}
@@ -2352,7 +2350,8 @@ int hfa384x_drvr_ramdl_write(hfa384x_t *hw, u32 daddr,
void *buf, u32 len)
if (hw->dlstate != HFA384x_DLSTATE_RAMENABLED)
return -EINVAL;
- netdev_info(hw->wlandev->netdev, "Writing %d bytes to ram @0x%06x\n",
len, daddr);
+ netdev_info(hw->wlandev->netdev, "Writing %d bytes to ram @0x%06x\n",
+
Re: [PATCH v3 1/2] i2c: Add driver for Cadence I2C controller
Please don't quote large parts of the message f you are not referring to
it.
> > +#ifdef CONFIG_PM_SLEEP
> > +/**
> > + * cdns_i2c_suspend - Suspend method for the driver
> > + * @_dev: Address of the platform_device structure
> > + * Return: 0 always
> > + *
> > + * Put the driver into low power mode.
> > + */
> > +static int cdns_i2c_suspend(struct device *_dev)
> > +{
> > + struct platform_device *pdev = container_of(_dev,
> > + struct platform_device, dev);
> > + struct cdns_i2c *xi2c = platform_get_drvdata(pdev);
> > +
> > + clk_disable(xi2c->clk);
> > + xi2c->suspended = 1;
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * cdns_i2c_resume - Resume from suspend
> > + * @_dev: Address of the platform_device structure
> > + * Return: 0 on success and error value on error
> > + *
> > + * Resume operation after suspend.
> > + */
> > +static int cdns_i2c_resume(struct device *_dev)
> > +{
> > + struct platform_device *pdev = container_of(_dev,
> > + struct platform_device, dev);
> > + struct cdns_i2c *xi2c = platform_get_drvdata(pdev);
> > + int ret;
> > +
> > + ret = clk_enable(xi2c->clk);
> > + if (ret) {
> > + dev_err(_dev, "Cannot enable clock.\n");
> > + return ret;
> > + }
> > +
> > + xi2c->suspended = 0;
> > +
> > + return 0;
> > +}
> > +#endif
>
> Can you also please remove this #ifdef and use __maybe_used
> instead? Better not to have any ifdef in the code.
Is this a new pattern? For PM_SLEEP, #ifdef seems to be quite common.
signature.asc
Description: Digital signature
Re: [PATCH 1/4] workqueue: Move workqueue bus attr to device attribute
Nothing much, just some nitpicks :)
On 27 March 2014 22:50, Frederic Weisbecker wrote:
> A workqueue directory implements at least two files: max_active and
> per_cpu. Since thse are constant over WQ_SYSFS workqueues, they are
s/thse/these
> implemented as bus attributes.
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 193e977..4d230e3 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -3133,7 +3133,6 @@ static ssize_t per_cpu_show(struct device *dev, struct
> device_attribute *attr,
>
> return scnprintf(buf, PAGE_SIZE, "%d\n", (bool)!(wq->flags &
> WQ_UNBOUND));
> }
> -static DEVICE_ATTR_RO(per_cpu);
>
> static ssize_t max_active_show(struct device *dev,
>struct device_attribute *attr, char *buf)
> @@ -3156,14 +3155,12 @@ static ssize_t max_active_store(struct device *dev,
> workqueue_set_max_active(wq, val);
> return count;
> }
> -static DEVICE_ATTR_RW(max_active);
>
> -static struct attribute *wq_sysfs_attrs[] = {
> - _attr_per_cpu.attr,
> - _attr_max_active.attr,
> - NULL,
> +static struct device_attribute wq_sysfs_default_attrs[] = {
> + __ATTR(per_cpu, 0444, per_cpu_show, NULL),
> + __ATTR(max_active, 0644, max_active_show, max_active_store),
> + __ATTR_NULL,
> };
> -ATTRIBUTE_GROUPS(wq_sysfs);
>
> static ssize_t wq_pool_ids_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> @@ -3313,7 +3310,6 @@ static struct device_attribute wq_sysfs_unbound_attrs[]
> = {
>
> static struct bus_type wq_subsys = {
> .name = "workqueue",
> - .dev_groups = wq_sysfs_groups,
> };
>
> static int __init wq_sysfs_init(void)
> @@ -3346,6 +3342,7 @@ static void wq_device_release(struct device *dev)
> */
> int workqueue_sysfs_register(struct workqueue_struct *wq)
> {
> + struct device_attribute *attr;
> struct wq_device *wq_dev;
> int ret;
>
> @@ -3379,8 +3376,16 @@ int workqueue_sysfs_register(struct workqueue_struct
> *wq)
> return ret;
> }
>
> + for (attr = wq_sysfs_default_attrs; attr->attr.name; attr++) {
> + ret = device_create_file(_dev->dev, attr);
> + if (ret) {
> + device_unregister(_dev->dev);
> + wq->wq_dev = NULL;
> + return ret;
> + }
> + }
Exactly same as below loop, probably create a routine for this?
> if (wq->flags & WQ_UNBOUND) {
> - struct device_attribute *attr;
>
probably remove this blank line as well..
> for (attr = wq_sysfs_unbound_attrs; attr->attr.name; attr++) {
> ret = device_create_file(_dev->dev, attr);
> --
> 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/
Re: USB autosuspend causing trouble on Intel bluetooth (Linux 3.14)
Hi Thomas, On Thu, Apr 03, 2014, Thomas Bächler wrote: > > You can easily check by running the "Inquiry (LIAC)” test from > > tools/hci-tester. Problem is that some of the HCI events are not > > making it to the host. They get delivered as soon as the device > > wakes up again. In this test case it is the Inquiry Complete event. > > If you poke the controller and send a new command, the even will be > > magically dequeued. > > I cannot figure out how to compile hci-tester. The Makefiles from > bluez.git won't build it. A quick look at Makefile.tools shows that you'll probably need to pass --enable-experimental to configure in order to build it. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] workqueue: Add anon workqueue sysfs hierarchy
On 27 March 2014 22:51, Frederic Weisbecker wrote:
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> static int __init wq_sysfs_init(void)
> {
> - return subsys_virtual_register(_subsys, NULL);
> + struct device *anon_dev;
> + int ret;
> +
> + ret = subsys_virtual_register(_subsys, NULL);
> + if (ret < 0)
> + return ret;
> +
> + mutex_lock(_unbound_mutex);
> + cpumask_copy(_anon_cpumask, cpu_possible_mask);
> + mutex_unlock(_unbound_mutex);
> +
> + anon_dev = kzalloc(sizeof(*anon_dev), GFP_KERNEL);
> + if (!anon_dev)
> + return -ENOMEM;
> +
> + anon_dev->bus = _subsys;
> + anon_dev->init_name = "anon_wqs";
> + anon_dev->release = device_release;
> +
> + ret = device_register(anon_dev);
> + if (ret) {
> + kfree(anon_dev);
> + return ret;
> + }
> +
> + ret = device_create_file(anon_dev, _sysfs_anon_attr);
> + if (ret) {
> + device_unregister(anon_dev);
kfree(anon_dev) ??
> + return ret;
> + }
> +
> + kobject_uevent(_dev->kobj, KOBJ_ADD);
> +
> + return 0;
> }
> core_initcall(wq_sysfs_init);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drm/i915: XPS13 backlight regression in v3.14
On Thu, 03 Apr 2014, James Hogan wrote: > Hi, > > I've noticed that v3.14 breaks the backlight on Dell XPS13. Reverting the > following commit fixes the issue for me (i.e. the GUI brightness controls > work > again): > > bc0bb9fd1c78 drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE > > It appears that in v3.14 (with the above patch): > * intel_backlight/brightness=4882 (max & default) causes > acpi_video0/brightness to have no effect. > * intel_backlight/brightness=0 causes acpi_video0/brightness to behave > corrrectly (the firmware (I assume) fades the brightness gradually when > acpi_video0/brightness is set) > * intel_backlight/brightness=something else in between often causes > acpi_video0 and intel_backlight to apparently "fight" over the backlight, > resulting in brightness flickering up and down every second or so. > > Reverting the above patch on v3.14: > * intel_backlight/brightness has no effect > * acpi_video0/brightness works normally > > It doesn't seem quite as simple as them trying to use the same hardware since > when intel_backlight/brightness=4882, acpi_video0/brightness has no effect at > all, so I don't really get what's going on. > > Can anybody shed some light or suggest a proper fix for this recurring issue? Tracked at https://bugs.freedesktop.org/show_bug.cgi?id=76276 BR, Jani. > > Thanks > James -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [HELP] How to use ftrace to learn how a function is ivoked?
On 2014/4/3 14:36, Du, ChangbinX wrote: > Hi, All, > I have a question for ftrace usage. It is that if I have a function A, then I > want to > know how function A is ivoked? > I know ftrace can show me what sub-functions that A called by below steps: > # echo function_graph > current_tracer > # echo function_A > set_graph_function > # cat trace > Then a call stack will show what functions A has called. But sometimes I want > to > know how A is called. Is there a method to do this? Please help me! dump_stack(), kprobe, AFAIK. Thanks, -Aubrey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv2 2/3] regmap: Add the DT binding documentation for endianness
> Subject: Re: [PATCHv2 2/3] regmap: Add the DT binding documentation for
> endianness
>
> On Wed, Apr 02, 2014 at 06:09:08PM +0800, Xiubo Li wrote:
>
> > +sai2: sai@40031000 {
> > + compatible = "fsl,vf610-sai";
> > + reg = <0x40031000 0x1000>;
> > + ...
> > + val-endian = 'LE';
> > +};
>
> This is mostly OK as a binding (though it should be CCed to the DT list
> and maintiners as all DT bindings should) except using upper case
> doesn't really seem idiomatic for DT - lower case is more normal -
I will your advices.
> and I
> don't think we can make these properties mandatory in themselves.
> Individual bindings would need to make them mandatory. It's also odd to
> have a mandatory property which may be absent!
Well, yes, It is.
The absent one is just to compatible with the old drivers.
>
> It'd probably be better if the binding defined what the default
> endianess was too, or just didn't say what happens in cases where
> nothing is specified, the latter seems better.
I will think it over carefully.
> Generally just not
> mentioning regmap is better for a binding definition, the binding should
> be usable by all OSs and not just Linux.
How about move the endianness OF parsing to the driver/of/ ?
Is this will be better ?
Thanks,
BRs
Xiubo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] nohz: use seqlock to avoid race on idle time stats v2
(2014/04/03 4:35), Denys Vlasenko wrote:
> On Mon, Mar 31, 2014 at 4:08 AM, Hidetoshi Seto
> wrote:
>> There are 2 problems:
>>
>> [PROBLEM 1]: there is no exclusive control.
>>
>> It is easy to understand that there are 2 different cpu - an
>> observing cpu where running a program observing idle cpu's stat
>> and an observed cpu where performing idle. It means race can
>> happen if observed cpu wakes up while it is observed. Observer
>> can accidentally add calculated duration time (say delta) to
>> time stats which is just updated by woken cpu. Soon correct
>> idle time is returned in next turn, so it will result in
>> backward time. Therefore readers must be excluded by writer.
>>
>> Then time stats are updated by woken cpu so there are only one
>> writer, right? No, unfortunately no. I'm not sure why are they,
>> but in some reason the function get_cpu_{idle,iowait}_time_us()
>> has ability to update sleeping cpu's time stats from observing
>> cpu. From grep of today's kernel tree, this feature is used by
>> cpufreq module. Calling this function with this feature in
>> periodically manner works like emulating tick for sleeping cpu.
>
> Frederic's patches started by moving all updates
> to tick_nohz_stop_idle(), makign the above problem easier -
> get_cpu_{idle,iowait}_time_us() are pure readers.
>
> The patches are here:
>
> https://lkml.org/lkml/2013/10/19/86
My concern here was that get_cpu_{idle,iowait}_time_us() are
exported function so that removing update functionality from
these affects kernel ABI compatibility. Even though I guess
there would be no other user than known cpufreq and kins, I also
thought that it looks like a shotgun approach and rough stuff.
However now I noticed that it is old mindset from when kernel
have Documentation/feature-removal.txt ... so I'm OK with
removing updates from these functions.
Still I'd prefer to see this change in separate patch that
modifies get_cpu_{idle,iowait}_time_us() only. It should
have CC and acked-by with cpufreq people.
>> [PROBLEM 2]: broken iowait accounting.
>>
>> As historical nature, cpu's idle time was accounted as either
>> idle or iowait depending on the presence of tasks blocked by
>> I/O. No one complain about it for a long time. However:
>>
>> > Still trying to wrap my head around it, but conceptually
>> > get_cpu_iowait_time_us() doesn't make any kind of sense.
>> > iowait isn't per cpu since effectively tasks that aren't
>> > running aren't assigned a cpu (as Oleg already pointed out).
>> -- Peter Zijlstra
>>
>> Now some kernel folks realized that accounting iowait as per-cpu
>> does not make sense in SMP world. When we were in traditional
>> UP era, cpu is considered to be waiting I/O if it is idle while
>> nr_iowait > 0. But in these days with SMP systems, tasks easily
>> migrate from a cpu where they issued an I/O to another cpu where
>> they are queued after I/O completion.
>
> However, if we would put ourselves into admin's seat, iowait
> immediately starts to make sense: for admin, the system state
> where a lot of CPU time is genuinely idle is qualitatively different
> form the state where a lot of CPU time is "idle" because
> we are I/O bound.
>
> Admins probably wouldn't insist that iowait accounting must be
> very accurate. I would hazard to guess that admins would settle
> for the following rules:
>
> * (idle + iowait) should accurately represent amount of time
> CPUs were idle.
> * both idle and iowait should never go backwards
> * when system is truly idle, only idle should increase
> * when system is truly I/O bound on all CPUs, only iowait should increase
> * when the situation is in between of the above two cases,
> both iowait and idle counters should grow. It's ok if they
> represent idle/IO-bound ratio only approximately
Yep. Admins are at the mercy of iowait value, though they know it
is not accurate.
Assume there are task X,Y,Z (X issues io, Y sleeps moderately,
and Z has low priority):
Case 1:
cpu A: <--run X--><--iowait--><--run X--><--iowait--><--run X ...
cpu B: <---run Y--><--run Z--><--run Y--><--run Z--><--run Y ...
io: <-- io X --> <-- io X -->
Case 2:
cpu A: <--run X--><--run Z---><--run X--><--run Z---><--run X ...
cpu B: <---run Y---><--idle--><---run Y---><--idle--><--run Y ...
io: <-- io X --> <-- io X -->
So case 1 tend to be iowait while case 2 is idle, despite
almost same workloads. Then what should admins do...?
(How silly! :-p)
>> Back to NO_HZ mechanism. Totally terrible thing here is that
>> observer need to handle duration "delta" without knowing that
>> nr_iowait of sleeping cpu can be changed easily by migration
>> even if cpu is sleeping.
>
> How about the following: when CPU enters idle, it remembers
> in struct tick_sched->idle_active whether it was "truly" idle
> or I/O bound: something like
>
> ts->idle_active = nr_iowait_cpu(smp_processor_id()) ? 2 : 1;
>
> Then, when we exit idle, we account
Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number
On Thu, 2014-04-03 at 11:06 +0800, Zhang Yanfei wrote:
> On 04/03/2014 10:37 AM, Li Zhong wrote:
> > On Thu, 2014-04-03 at 09:37 +0800, Zhang Yanfei wrote:
> >> Add ccing
> >>
> >> On 04/02/2014 04:56 PM, Li Zhong wrote:
> >>> I noticed the phys_index and end_phys_index under
> >>> /sys/devices/system/memory/memoryXXX/ have the same value, e.g.
> >>> (for the test machine, one memory block has 8 sections, that is
> >>> sections_per_block equals 8)
> >>>
> >>> # cd /sys/devices/system/memory/memory100/
> >>> # cat phys_index end_phys_index
> >>> 0064
> >>> 0064
> >>>
> >>> Seems they should reflect the start/end section number respectively,
> >>> which
> >>> also matches what is said in Documentation/memory-hotplug.txt
> >>
> > Hi Yanfei,
> >
> > Thanks for the review.
> >
> >> Indeed. I've noticed this before. The value in 'end_phys_index' doesn't
> >> match what it really means. But, the name itself is vague, it looks like
> >> it is the index of some page frame. (we keep this name for compatibility?)
> >
> > I guess so, Dave just reminded me that the RFC would also break
> > userspace..
> >
> > And now my plan is:
> > leave the code unchanged
> > update the document, state the end_phys_index/phys_index are the same,
> > and means the memory block index
>
> Ah. I doubt whether there is userspace tool which is using the two sysfiles?
> for example, the memory100 directory itself can tell us which block it is.
> So why there is the two files under it give the same meaning.
>
> If there is userspace tool using the two files, does it use 'end_phys_index'
> in the correct way? That said, if a userspace tool knows what the
> 'end_phys_index'
> really mean, does it still need it since we have 'phys_index' with the same
> value?
For the end_phys_index, I totally agree with you. If somebody tries to
use it, say as the end section number, he should finally be able to find
that the value is not what he expects. But who knows ...
For phys_index, I guess it is also reasonable for some userspace tool to
just loop for each memoryXXX directory under /sys/devices/system/memory,
and use the phys_index as the memory block index for the directory,
instead of extracting the XXX from the directory name memoryXXX
Don't know whether there are some generic rules for handling such kind
of compatibility issues...
> > [optional] create two new files start_sec_nr, end_sec_nr if needed
>
> These two are the really meaningful sysfiles for userspace, IMO.
OK, I see.
>
> >
> > Do you have any other suggestions?
>
> No. I think we should wait for other guys to comment more.
OK, let's wait.
Thanks, Zhong
>
> Thanks.
>
> >
> > Thanks, Zhong
> >
> >>
> >> The corresponding member in struct memory_block is:
> >>
> >> struct memory_block {
> >> unsigned long start_section_nr;
> >> unsigned long end_section_nr;
> >> ...
> >>
> >> The two members seem to have the right name, and have the right value in
> >> kernel.
> >>
> >>
> >>>
> >>> This patch tries to modify that so the two files could show the start/end
> >>> section number of the memory block.
> >>>
> >>> After this change, output of the above example looks like:
> >>>
> >>> # cat phys_index end_phys_index
> >>> 0320
> >>> 0327
> >>>
> >>> Signed-off-by: Li Zhong
> >>> ---
> >>> drivers/base/memory.c | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> >>> index bece691..b10f2fa 100644
> >>> --- a/drivers/base/memory.c
> >>> +++ b/drivers/base/memory.c
> >>> @@ -114,7 +114,7 @@ static ssize_t show_mem_start_phys_index(struct
> >>> device *dev,
> >>> struct memory_block *mem = to_memory_block(dev);
> >>> unsigned long phys_index;
> >>>
> >>> - phys_index = mem->start_section_nr / sections_per_block;
> >>> + phys_index = mem->start_section_nr;
> >>> return sprintf(buf, "%08lx\n", phys_index);
> >>> }
> >>>
> >>> @@ -124,7 +124,7 @@ static ssize_t show_mem_end_phys_index(struct device
> >>> *dev,
> >>> struct memory_block *mem = to_memory_block(dev);
> >>> unsigned long phys_index;
> >>>
> >>> - phys_index = mem->end_section_nr / sections_per_block;
> >>> + phys_index = mem->end_section_nr;
> >>> return sprintf(buf, "%08lx\n", phys_index);
> >>> }
> >>>
> >>>
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >>> the body of a message to majord...@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>> Please read the FAQ at http://www.tux.org/lkml/
> >>>
> >>
> >>
> >
> >
> > .
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] x86: replace timeouts when booting secondary CPU with infinite wait loop
* Igor Mammedov wrote: > > I've seen that. Kernel still boots. With your patch it would hang. Nonsense, not booting is OK when critical hardware is genuinely bad - this isn't a disk drive or networking where bad IO 'happens sometimes' and failure is something we have to engineer for - this is the CPU! If a critical piece of hardware like the CPU or RAM is non-functional then it should be excluded by the user explicitly, not worked around after some ugly, non-deterministic and fragile timeout. The timeout in the SMP bringup code was really an ancient property, introduced back more than a decade ago when hardware makers were ignorant of Linux we were ignorant of how to properly interface with SMP hardware. Today a 'timeout' means one of 3 things: - bad, fragile hardware - this we don't want to hide, unless explicitly told so by the user. I've seen such symptoms related to overclocking for example - so not booting is perfectly justified, it can prevent reporting a bogus kernel crash down the line. - buggy SMP bringup. That is a bug that needs to be fixed, not worked around. - timeout fragility in virtualized environments I'm not aware of any genuine case where timing out is the correct thing to do. So the patches look fine to me as-is, I planned on looking at them more closely after the merge window. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[HELP] How to use ftrace to learn how a function is ivoked?
Hi, All, I have a question for ftrace usage. It is that if I have a function A, then I want to know how function A is ivoked? I know ftrace can show me what sub-functions that A called by below steps: # echo function_graph > current_tracer # echo function_A > set_graph_function # cat trace Then a call stack will show what functions A has called. But sometimes I want to know how A is called. Is there a method to do this? Please help me! Regards and Thanks! Du, Changbin
Things I wish I'd known about Inotify
(To: == [the set of people I believe know a lot about inotify]) Hello all, Lately, I've been studying the inotify API fairly thoroughly and realized that there's a very big gap between knowing what the system calls do versus using them to reliably and efficiently monitor the state of a set of filesystem objects. With that in mind, I've drafted some substantial additions to the inotify(7) man page. I would be very happy if folk on the "To:" list could comment on the text below, since I believe you all have a lot of practical experience with Inotify. (Of course, I also welcome comments from anyone else.) In particular, I would like comments on the accuracy of the various technical points (especially those relating to matching up related IN_MOVED_FROM and IN_MOVED_TO events), as well as pointers on any other pitfalls that the programmers should be wary of that should be added to the page. Thanks, Michael Limitations and caveats The inotify API provides no information about the user or process that triggered the inotify event. In particular, there is no easy way for a process that is monitoring events via inotify to distinguish events that it triggers itself from those that are triggered by other processes. The inotify API identifies affected files by filename. However, by the time an application processes an inotify event, the file‐ name may already have been deleted or renamed. The inotify API identifies events via watch descriptors. It is the application's responsibility to cache a mapping (if one is needed) between watch descriptors and pathnames. Be aware that directory renamings may affect multiple cached pathnames. Inotify monitoring of directories is not recursive: to monitor subdirectories under a directory, additional watches must be cre‐ ated. This can take a significant amount time for large direc‐ tory trees. If monitoring an entire directory subtree, and a new subdirectory is created in that tree or an existing directory is renamed into that tree, be aware that by the time you create a watch for the new subdirectory, new files (and subdirectories) may already exist inside the subdirectory. Therefore, you may want to scan the contents of the subdirectory immediately after adding the watch (and, if desired, recursively add watches for any subdirec‐ tories that it contains). Note that the event queue can overflow. In this case, events are lost. Robust applications should handle the possibility of lost events gracefully. For example, it may be necessary to rebuild part or all of the application cache. (One simple, but possibly expensive, approach is to close the inotify file descriptor, empty the cache, create a new inotify file descriptor, and then re-create watches and cache entries for the objects to be moni‐ tored.) Dealing with rename() events The IN_MOVED_FROM and IN_MOVED_TO events that are generated by rename(2) are usually available as consecutive events when read‐ ing from the inotify file descriptor. However, this is not guar‐ anteed. If multiple processes are triggering events for moni‐ tored objects, then (on rare occasions) an arbitrary number of other events may appear between the IN_MOVED_FROM and IN_MOVED_TO events. Matching up the IN_MOVED_FROM and IN_MOVED_TO event pair gener‐ ated by rename(2) is thus inherently racy. (Don't forget that if an object is renamed outside of a monitored directory, there may not even be an IN_MOVED_TO event.) Heuristic approaches (e.g., assume the events are always consecutive) can be used to ensure a match in most cases, but will inevitably miss some cases, causing the application to perceive the IN_MOVED_FROM and IN_MOVED_TO events as being unrelated. If watch descriptors are destroyed and re-created as a result, then those watch descriptors will be inconsistent with the watch descriptors in any pending events. (Re-creating the inotify file descriptor and rebuilding the cache may be useful to deal with this scenario.) Applications should also allow for the possibility that the IN_MOVED_FROM event was the last event that could fit in the buf‐ fer returned by the current call to read(2), and the accompanying IN_MOVED_TO event might be fetched only on the next read(2). -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo
Re: FW: [BUG] x86: reboot doesn't reboot
> From: Steven Rostedt [mailto:rost...@goodmis.org] > Sent: Thursday, April 03, 2014 2:14 PM > To: Linus Torvalds; LKML > Cc: Ingo Molnar; H. Peter Anvin; Thomas Gleixner; Li, Aubrey; Matthew Garrett > Subject: [BUG] x86: reboot doesn't reboot > > I noticed that one of my test boxes no longer does a reboot with the latest > kernel. It goes down and shows: > > [ 51.589896] reboot: Restarting system > [ 51.593567] reboot: machine restart > > > And the system sounds like it turns off (the fans stop), but then I just sit > there > and wait, and wait and wait. The system never starts up again. > > I did a bisect and it landed on: a4f1987e4c54 "x86, reboot: Add EFI and > CF9 reboot methods into the default list" which looks like a very likely > suspect. I > removed that and fb3bd7b19b2b, as the second commit was just a fix up of the > first, recompiled, installed and rebooted to that kernel. I tried to reboot > again > and sure enough after posting the "machine restart" I started getting those > "Press any key to continue." > messages again. That's a good sign. > > Linus mentioned to me to use "reboot=pci" on the kernel command line, but no > dice. That doesn't seem to make a difference. May I know if "reboot=t" make any difference on your system with the change? Thanks, -Aubrey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
On 04/02/2014 05:12 PM, Tero Kristo wrote:
> On 04/02/2014 04:48 PM, Peter Ujfalusi wrote:
>> ABE DPLL frequency need to be lowered from 361267200
>> to 180633600 to facilitate the ATL requironments.
>> The dpll_abe_m2x2_ck clock need to be set to double
>> of ABE DPLL rate in order to have correct clocks
>> for audio.
>
> Do you have some sort of TRM reference for this?
The ATL's max divider is 32.
For audio purpose the clock coming out from the ATL instance should be
128 * fs. It is only possible to have 44.1KHz sampling rate with ABE DPLL set
to 361267200 or 180633600. Which means:
The atl generated clock should be 128 * 44100 = 5644800
>From ABE_DPLL 361267200 we would need to have 64 as divider (ATL can't do
>this).
>From the suggested ABE_DPLL of 180633600 we can use ATL divider of 32, which
is the maximum it can do.
So the reason for the change is to have ATLPCLK clock which can be used for
audio in the future, the 361267200 is just too high.
>
> -Tero
>
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> drivers/clk/ti/clk-7xx.c | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
>> index f7e40734c819..19a55bf407dd 100644
>> --- a/drivers/clk/ti/clk-7xx.c
>> +++ b/drivers/clk/ti/clk-7xx.c
>> @@ -16,7 +16,7 @@
>> #include
>> #include
>>
>> -#define DRA7_DPLL_ABE_DEFFREQ361267200
>> +#define DRA7_DPLL_ABE_DEFFREQ180633600
>> #define DRA7_DPLL_GMAC_DEFFREQ10
>>
>>
>> @@ -322,6 +322,11 @@ int __init dra7xx_dt_clk_init(void)
>> if (rc)
>> pr_err("%s: failed to configure ABE DPLL!\n", __func__);
>>
>> +dpll_ck = clk_get_sys(NULL, "dpll_abe_m2x2_ck");
>> +rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2);
>> +if (rc)
>> +pr_err("%s: failed to configure ABE DPLL m2x2!\n", __func__);
>> +
>> dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
>> rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
>> if (rc)
>>
>
--
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: [PATCH v4 1/2] serial: sc16is7xx
Thu, 3 Apr 2014 00:49:14 -0400 от j...@ringle.org:
> From: Jon Ringle
>
> The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel
> high performance UART. The SC16IS7xx’s internal register set is
> backward-compatible with the widely used and widely popular 16C450.
>
> The SC16IS7xx also provides additional advanced features such as
> auto hardware and software flow control, automatic RS-485 support, and
> software reset.
>
> Signed-off-by: Jon Ringle
> ---
...
> + tristate "SC16IS7xx serial support"
> + select SERIAL_CORE
> + select REGMAP_I2C if I2C
> + default n
"n" is already default choice. There is no need to specify this.
...
> +#include
> +#include
What a reason to include SPI header?
...
> + * The programmer must program the TCR such that TCR[3:0] > TCR[7:4]. There
> is
> + * no built-in hardware check to make sure this condition is met. Also, the
> TCR
> + * must be programmed with this condition before auto RTS or software flow
> + * control is enabled to avoid spurious operation of the device.
> + */
> +#define SC16IS7XX_TCR_RX_HALT(words) (((words / 4) & 0x0f) << 0)
> +#define SC16IS7XX_TCR_RX_RESUME(words) (((words / 4) & 0x0f) << 4)
"words" on the right side should be framed by brackets.
...
> + * When TLR is used for RX trigger level control, FCR[7:6] should be left at
> the
> + * default state, that is, ‘00’.
> + */
> +#define SC16IS7XX_TLR_TX_TRIGGER(words) (((words / 4) & 0x0f) << 0)
> +#define SC16IS7XX_TLR_RX_TRIGGER(words) (((words / 4) & 0x0f) << 4)
Ditto.
...
> +static void sc16is7xx_config_rs485(struct uart_port *port,
> +struct serial_rs485 *rs485)
> +{
> + struct sc16is7xx_one *one = to_sc16is7xx_one(port, port);
> +
> + one->rs485 = *rs485;
> +
> + if (one->rs485.flags & SER_RS485_ENABLED) {
> + sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG,
> + SC16IS7XX_EFCR_AUTO_RS485_BIT,
> + SC16IS7XX_EFCR_AUTO_RS485_BIT);
> + } else {
> + sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG,
> + SC16IS7XX_EFCR_AUTO_RS485_BIT,
> + 0);
> + }
> +}
This function will get "unused" warning if TIOCSRS485 and
TIOCGRS485 is not defined.
...
> +static int sc16is7xx_startup(struct uart_port *port)
> +{
...
> + sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG,
> + SC16IS7XX_EFCR_AUTO_RS485_BIT,
> + SC16IS7XX_EFCR_AUTO_RS485_BIT);
You should do not set optional RS485 mode unconditionally.
Since IOCTL for RS485 is used, this should be enough.
---
[PATCH] GenWQE: Fix email address and update copyright notice
Updated email address of co-author and updated the copyright notice
with the current year.
Signed-off-by: Frank Haverkamp
Signed-off-by: Michael Jung
---
drivers/misc/genwqe/card_base.c |6 +++---
drivers/misc/genwqe/card_base.h |4 ++--
drivers/misc/genwqe/card_ddcb.c |4 ++--
drivers/misc/genwqe/card_ddcb.h |4 ++--
drivers/misc/genwqe/card_debugfs.c |4 ++--
drivers/misc/genwqe/card_dev.c |4 ++--
drivers/misc/genwqe/card_sysfs.c|4 ++--
drivers/misc/genwqe/card_utils.c|4 ++--
drivers/misc/genwqe/genwqe_driver.h |4 ++--
include/uapi/linux/genwqe/genwqe_card.h |4 ++--
10 files changed, 21 insertions(+), 21 deletions(-)
--- a/drivers/misc/genwqe/card_base.c
+++ b/drivers/misc/genwqe/card_base.c
@@ -1,11 +1,11 @@
/**
* IBM Accelerator Family 'GenWQE'
*
- * (C) Copyright IBM Corp. 2013
+ * (C) Copyright IBM Corp. 2013, 2014
*
* Author: Frank Haverkamp
* Author: Joerg-Stephan Vogt
- * Author: Michael Jung
+ * Author: Michael Jung
* Author: Michael Ruettger
*
* This program is free software; you can redistribute it and/or modify
@@ -46,7 +46,7 @@
MODULE_AUTHOR("Frank Haverkamp ");
MODULE_AUTHOR("Michael Ruettger ");
MODULE_AUTHOR("Joerg-Stephan Vogt ");
-MODULE_AUTHOR("Michal Jung ");
+MODULE_AUTHOR("Michael Jung ");
MODULE_DESCRIPTION("GenWQE Card");
MODULE_VERSION(DRV_VERS_STRING);
--- a/drivers/misc/genwqe/card_base.h
+++ b/drivers/misc/genwqe/card_base.h
@@ -4,11 +4,11 @@
/**
* IBM Accelerator Family 'GenWQE'
*
- * (C) Copyright IBM Corp. 2013
+ * (C) Copyright IBM Corp. 2013, 2014
*
* Author: Frank Haverkamp
* Author: Joerg-Stephan Vogt
- * Author: Michael Jung
+ * Author: Michael Jung
* Author: Michael Ruettger
*
* This program is free software; you can redistribute it and/or modify
--- a/drivers/misc/genwqe/card_ddcb.c
+++ b/drivers/misc/genwqe/card_ddcb.c
@@ -1,11 +1,11 @@
/**
* IBM Accelerator Family 'GenWQE'
*
- * (C) Copyright IBM Corp. 2013
+ * (C) Copyright IBM Corp. 2013, 2014
*
* Author: Frank Haverkamp
* Author: Joerg-Stephan Vogt
- * Author: Michael Jung
+ * Author: Michael Jung
* Author: Michael Ruettger
*
* This program is free software; you can redistribute it and/or modify
--- a/drivers/misc/genwqe/card_ddcb.h
+++ b/drivers/misc/genwqe/card_ddcb.h
@@ -4,11 +4,11 @@
/**
* IBM Accelerator Family 'GenWQE'
*
- * (C) Copyright IBM Corp. 2013
+ * (C) Copyright IBM Corp. 2013, 2014
*
* Author: Frank Haverkamp
* Author: Joerg-Stephan Vogt
- * Author: Michael Jung
+ * Author: Michael Jung
* Author: Michael Ruettger
*
* This program is free software; you can redistribute it and/or modify
--- a/drivers/misc/genwqe/card_debugfs.c
+++ b/drivers/misc/genwqe/card_debugfs.c
@@ -1,11 +1,11 @@
/**
* IBM Accelerator Family 'GenWQE'
*
- * (C) Copyright IBM Corp. 2013
+ * (C) Copyright IBM Corp. 2013, 2014
*
* Author: Frank Haverkamp
* Author: Joerg-Stephan Vogt
- * Author: Michael Jung
+ * Author: Michael Jung
* Author: Michael Ruettger
*
* This program is free software; you can redistribute it and/or modify
--- a/drivers/misc/genwqe/card_dev.c
+++ b/drivers/misc/genwqe/card_dev.c
@@ -1,11 +1,11 @@
/**
* IBM Accelerator Family 'GenWQE'
*
- * (C) Copyright IBM Corp. 2013
+ * (C) Copyright IBM Corp. 2013, 2014
*
* Author: Frank Haverkamp
* Author: Joerg-Stephan Vogt
- * Author: Michael Jung
+ * Author: Michael Jung
* Author: Michael Ruettger
*
* This program is free software; you can redistribute it and/or modify
--- a/drivers/misc/genwqe/card_sysfs.c
+++ b/drivers/misc/genwqe/card_sysfs.c
@@ -1,11 +1,11 @@
/**
* IBM Accelerator Family 'GenWQE'
*
- * (C) Copyright IBM Corp. 2013
+ * (C) Copyright IBM Corp. 2013, 2014
*
* Author: Frank Haverkamp
* Author: Joerg-Stephan Vogt
- * Author: Michael Jung
+ * Author: Michael Jung
* Author: Michael Ruettger
*
* This program is free software; you can redistribute it and/or modify
--- a/drivers/misc/genwqe/card_utils.c
+++ b/drivers/misc/genwqe/card_utils.c
@@ -1,11 +1,11 @@
/**
* IBM Accelerator Family 'GenWQE'
*
- * (C) Copyright IBM Corp. 2013
+ * (C) Copyright IBM Corp. 2013, 2014
*
* Author: Frank Haverkamp
* Author: Joerg-Stephan Vogt
- * Author: Michael Jung
+ * Author: Michael Jung
* Author: Michael Ruettger
*
* This program is free software; you can redistribute it and/or modify
--- a/drivers/misc/genwqe/genwqe_driver.h
+++ b/drivers/misc/genwqe/genwqe_driver.h
@@ -4,11 +4,11 @@
/**
* IBM Accelerator Family 'GenWQE'
*
- * (C) Copyright IBM Corp. 2013
+ * (C) Copyright IBM Corp. 2013, 2014
*
* Author: Frank Haverkamp
* Author: Joerg-Stephan Vogt
- * Author: Michael Jung
+ * Author: Michael Jung
* Author: Michael Ruettger
*
* This program is free software; you can redistribute it and/or modify
--- a/include/uapi/linux/genwqe/genwqe_card.h
+++
[PATCH] f2fs: introduce f2fs_issue_flush to avoid redundant flush issue
Some storage devices show relatively high latencies to complete cache_flush
commands, even though their normal IO speed is prettry much high. In such
the case, it needs to merge cache_flush commands as much as possible to avoid
issuing them redundantly.
So, this patch introduces a mount option, "-o flush_merge", to mitigate such
the overhead.
If this option is enabled by user, F2FS merges the cache_flush commands and then
issues just one cache_flush on behalf of them. Once the single command is
finished, F2FS sends a completion signal to all the pending threads.
Note that, this option can be used under a workload consisting of very intensive
concurrent fsync calls, while the storage handles cache_flush commands slowly.
Signed-off-by: Jaegeuk Kim
---
Documentation/filesystems/f2fs.txt | 4 ++
fs/f2fs/f2fs.h | 16 +++
fs/f2fs/file.c | 2 +-
fs/f2fs/segment.c | 87 ++
fs/f2fs/super.c| 7 +++
5 files changed, 115 insertions(+), 1 deletion(-)
diff --git a/Documentation/filesystems/f2fs.txt
b/Documentation/filesystems/f2fs.txt
index 2f6d021..25311e11 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -122,6 +122,10 @@ disable_ext_identify Disable the extension list
configured by mkfs, so f2fs
inline_xattr Enable the inline xattrs feature.
inline_dataEnable the inline data feature: New created
small(<~3.4k)
files can be written into inode block.
+flush_merge Merge concurrent cache_flush commands as much as possible
+ to eliminate redundant command issues. If the underlying
+ device handles the cache_flush command relatively slowly,
+ recommend to enable this option.
DEBUGFS ENTRIES
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 1e3d869..2ecac83 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -40,6 +40,7 @@
#define F2FS_MOUNT_DISABLE_EXT_IDENTIFY0x0040
#define F2FS_MOUNT_INLINE_XATTR0x0080
#define F2FS_MOUNT_INLINE_DATA 0x0100
+#define F2FS_MOUNT_FLUSH_MERGE 0x0200
#define clear_opt(sbi, option) (sbi->mount_opt.opt &= ~F2FS_MOUNT_##option)
#define set_opt(sbi, option) (sbi->mount_opt.opt |= F2FS_MOUNT_##option)
@@ -316,6 +317,12 @@ enum {
NO_CHECK_TYPE
};
+struct flush_cmd {
+ struct flush_cmd *next;
+ struct completion wait;
+ int ret;
+};
+
struct f2fs_sm_info {
struct sit_info *sit_info; /* whole segment information */
struct free_segmap_info *free_info; /* free segment information */
@@ -344,6 +351,14 @@ struct f2fs_sm_info {
unsigned int ipu_policy;/* in-place-update policy */
unsigned int min_ipu_util; /* in-place-update threshold */
+
+ /* for flush command control */
+ struct task_struct *f2fs_issue_flush; /* flush thread */
+ wait_queue_head_t flush_wait_queue; /* waiting queue for wake-up */
+ struct flush_cmd *issue_list; /* list for command issue */
+ struct flush_cmd *dispatch_list;/* list for command dispatch */
+ spinlock_t issue_lock; /* for issue list lock */
+ struct flush_cmd *issue_tail; /* list tail of issue list */
};
/*
@@ -1160,6 +1175,7 @@ void destroy_node_manager_caches(void);
*/
void f2fs_balance_fs(struct f2fs_sb_info *);
void f2fs_balance_fs_bg(struct f2fs_sb_info *);
+int f2fs_issue_flush(struct f2fs_sb_info *);
void invalidate_blocks(struct f2fs_sb_info *, block_t);
void refresh_sit_entry(struct f2fs_sb_info *, block_t, block_t);
void clear_prefree_segments(struct f2fs_sb_info *);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 6ba2668..302d552 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -186,7 +186,7 @@ int f2fs_sync_file(struct file *file, loff_t start, loff_t
end, int datasync)
ret = wait_on_node_pages_writeback(sbi, inode->i_ino);
if (ret)
goto out;
- ret = blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL);
+ ret = f2fs_issue_flush(F2FS_SB(inode->i_sb));
}
out:
trace_f2fs_sync_file_exit(inode, need_cp, datasync, ret);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index f799c6a..2993624 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -24,6 +25,7 @@
#define __reverse_ffz(x) __reverse_ffs(~(x))
static struct kmem_cache *discard_entry_slab;
+static struct kmem_cache *flush_cmd_slab;
/*
* __reverse_ffs is copied from include/asm-generic/bitops/__ffs.h since
@@ -195,6 +197,73 @@ void f2fs_balance_fs_bg(struct
Re: [PATCH 3.12 03/40] intel_idle: Support Intel Atom Processor C2000 Product Family
> From: Len Brown
>
> 3.12-stable review patch. If anyone has any objections, please let me know.
>
> ===
>
> commit fab04b2208dd1d4121319f0096c5a5f4b70abc54 upstream.
>
> Support the "Intel(R) Atom(TM) Processor C2000 Product Family",
> formerly code-named Avoton. It is based on the next generation
> Intel Atom processor architecture, formerly code-named Silvermont.
>
> Signed-off-by: Len Brown
> Signed-off-by: Rafael J. Wysocki
> Signed-off-by: Jiri Slaby
> ---
> drivers/idle/intel_idle.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> index d47bb0f267f7..000d370519d9 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@ -1,7 +1,7 @@
> /*
> * intel_idle.c - native hardware idle loop for modern Intel processors
> *
> - * Copyright (c) 2010, Intel Corporation.
> + * Copyright (c) 2013, Intel Corporation.
> * Len Brown
> *
> * This program is free software; you can redistribute it and/or modify it
> @@ -329,6 +329,22 @@ static struct cpuidle_state
> atom_cstates[CPUIDLE_STATE_MAX] = {
> {
> .enter = NULL }
> };
> +static struct cpuidle_state avn_cstates[CPUIDLE_STATE_MAX] = {
> + {
> + .name = "C1-AVN",
> + .desc = "MWAIT 0x00",
> + .flags = MWAIT2flg(0x00) | CPUIDLE_FLAG_TIME_VALID,
> + .exit_latency = 2,
> + .target_residency = 2,
> + .enter = _idle },
> + {
> + .name = "C6-AVN",
> + .desc = "MWAIT 0x51",
> + .flags = MWAIT2flg(0x58) | CPUIDLE_FLAG_TIME_VALID |
> CPUIDLE_FLAG_TLB_FLUSHED,
> + .exit_latency = 15,
> + .target_residency = 45,
> + .enter = _idle },
> +};
>
> /**
> * intel_idle
> @@ -465,6 +481,11 @@ static const struct idle_cpu idle_cpu_hsw = {
> .disable_promotion_to_c1e = true,
> };
>
> +static const struct idle_cpu idle_cpu_avn = {
> + .state_table = avn_cstates,
> + .disable_promotion_to_c1e = true,
> +};
> +
> #define ICPU(model, cpu) \
> { X86_VENDOR_INTEL, 6, model, X86_FEATURE_MWAIT, (unsigned long) }
>
> @@ -486,6 +507,7 @@ static const struct x86_cpu_id intel_idle_ids[] = {
> ICPU(0x3f, idle_cpu_hsw),
> ICPU(0x45, idle_cpu_hsw),
> ICPU(0x46, idle_cpu_hsw),
> + ICPU(0x4D, idle_cpu_avn),
> {}
> };
> MODULE_DEVICE_TABLE(x86cpu, intel_idle_ids);
Ahoj !
For this one you also need the upstream patch
22e580d07f6529a395c129575127ea6d860aed3a to make the C-States work on
C2000 series.
Arne
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] GenWQE: Use pci_enable_msi_exact() instead of pci_enable_msi_block()
Hi Alexander, Am Mittwoch, den 02.04.2014, 13:52 +0200 schrieb Alexander Gordeev: > As result of deprecation of MSI-X/MSI enablement functions > pci_enable_msix() and pci_enable_msi_block() all drivers > using these two interfaces need to be updated to use the > new pci_enable_msi_range() or pci_enable_msi_exact() > and pci_enable_msix_range() or pci_enable_msix_exact() > interfaces. > > Signed-off-by: Alexander Gordeev > Cc: Frank Haverkamp > Cc: Greg Kroah-Hartman > --- > drivers/misc/genwqe/card_utils.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/misc/genwqe/card_utils.c > b/drivers/misc/genwqe/card_utils.c > index 6b1a6ef..294f667 100644 > --- a/drivers/misc/genwqe/card_utils.c > +++ b/drivers/misc/genwqe/card_utils.c > @@ -628,7 +628,7 @@ int genwqe_set_interrupt_capability(struct genwqe_dev > *cd, int count) > int rc; > struct pci_dev *pci_dev = cd->pci_dev; > > - rc = pci_enable_msi_block(pci_dev, count); > + rc = pci_enable_msi_exact(pci_dev, count); > if (rc == 0) > cd->flags |= GENWQE_FLAG_MSI_ENABLED; > return rc; fine with me, if it works like it did before. Acked-by: Frank Haverkamp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] x86: reboot doesn't reboot
I noticed that one of my test boxes no longer does a reboot with the latest kernel. It goes down and shows: [ 51.589896] reboot: Restarting system [ 51.593567] reboot: machine restart And the system sounds like it turns off (the fans stop), but then I just sit there and wait, and wait and wait. The system never starts up again. I did a bisect and it landed on: a4f1987e4c54 "x86, reboot: Add EFI and CF9 reboot methods into the default list" which looks like a very likely suspect. I removed that and fb3bd7b19b2b, as the second commit was just a fix up of the first, recompiled, installed and rebooted to that kernel. I tried to reboot again and sure enough after posting the "machine restart" I started getting those "Press any key to continue." messages again. That's a good sign. Linus mentioned to me to use "reboot=pci" on the kernel command line, but no dice. That doesn't seem to make a difference. I see in the merge commit: Pull x86 reboot changes from Ingo Molnar: "Refine the reboot logic around the CF9 and EFI reboot methods, to make it more robust. The expectation is for no working system to break, and for a couple of reboot-force systems to start rebooting automatically again" Unfortunately, the expectation of no working system to break, didn't quite stand up to expectations :-/ -- 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 2/2] ttyprintk: Allow built as a module
At Wed, 2 Apr 2014 12:32:22 -0700, Greg Kroah-Hartman wrote: > > On Wed, Apr 02, 2014 at 12:29:42PM +0200, Takashi Iwai wrote: > > The driver is well written to be used as a module, just the exit call > > is missing. > > > > Signed-off-by: Takashi Iwai > > --- > > drivers/char/Kconfig | 2 +- > > drivers/char/ttyprintk.c | 13 - > > 2 files changed, 13 insertions(+), 2 deletions(-) > > There was some reason we didn't do this back when the code was accepted, > but I really can't remember why. > > If you have tested this out, I don't have any objections to taking these > patches, thanks. The module worked fine with my quick tests (load/unload/feed something via /dev/ttyprintk), at least. But it'd be helpful if anyone remembers and clarifies. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Thermal/int3403: Fix thermal hysteresis unit conversion
Thermal hysteresis represents a temperature difference. But the original code treats it as a temperature value, Convert it from tenths of degree Kelvin to Milli-Celsius by deducing 273200. This is not right. Kelvin and Celsius have same degree size. From temperature difference view, the conversion between tenths of degree Kelvin unit and Milli-Celsius unit is just to multiply 100. Signed-off-by: Lan Tianyu Acked-by: Srinivas Pandruvada --- drivers/thermal/int3403_thermal.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/thermal/int3403_thermal.c b/drivers/thermal/int3403_thermal.c index 1301681..e93f025 100644 --- a/drivers/thermal/int3403_thermal.c +++ b/drivers/thermal/int3403_thermal.c @@ -62,7 +62,13 @@ static int sys_get_trip_hyst(struct thermal_zone_device *tzone, if (ACPI_FAILURE(status)) return -EIO; - *temp = DECI_KELVIN_TO_MILLI_CELSIUS(hyst, KELVIN_OFFSET); + /* +* Thermal hysteresis represents a temperature difference. +* Kelvin and Celsius have same degree size. So the +* conversion here between tenths of degree Kelvin unit +* and Milli-Celsius unit is just to multiply 100. +*/ + *temp = hyst * 100; return 0; } -- 1.8.4.rc0.1.g8f6a3e5.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ttyprintk: Fix wrong tty_unregister_driver() call in the error path
At Wed, 02 Apr 2014 14:24:33 +0200, Jean Delvare wrote: > > Le Wednesday 02 April 2014 à 12:29 +0200, Takashi Iwai a écrit : > > ttyprintk driver calls tty_unregister_driver() wrongly in the error > > path of tty_register_driver(). Also, setting ttyprintk_driver to NULL > > is utterly superfluous, so let's get rid of it, too. > > > > Reported-by: Jean Delvare > > Signed-off-by: Takashi Iwai > > --- > > drivers/char/ttyprintk.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/drivers/char/ttyprintk.c b/drivers/char/ttyprintk.c > > index daea84c41743..2a39c5790364 100644 > > --- a/drivers/char/ttyprintk.c > > +++ b/drivers/char/ttyprintk.c > > @@ -210,10 +210,8 @@ static int __init ttyprintk_init(void) > > return 0; > > > > error: > > - tty_unregister_driver(ttyprintk_driver); > > put_tty_driver(ttyprintk_driver); > > tty_port_destroy(_port.port); > > - ttyprintk_driver = NULL; > > return ret; > > } > > device_initcall(ttyprintk_init); > > Reviewed-by: Jean Delvare Meanwhile, I found that tty_unregister_driver() was added intentionally in the commit f06fb543c1d0, TTY: ttyprintk, unregister tty driver on failure When the tty_printk driver fails to create a node in sysfs, the system crashes. It is because the driver registers a tty driver and frees it without deregistering it first. The fix is easy: add a call to tty_unregister_driver to the fail path. But, I failed to see why this is needed in the current code. Jiri, is your fix still valid at all? thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] i2c: Add driver for Cadence I2C controller
Hi Soren,
On 03/11/2014 05:50 PM, Soren Brinkmann wrote:
> Add a driver for the Cadence I2C controller. This controller is for
> example found in Xilinx Zynq.
>
> Signed-off-by: Soren Brinkmann
> ---
> v3:
> - incorporate signal handling changes from Mike Looijmans
> (https://lkml.org/lkml/2014/3/11/64)
> v2:
> - make driver depend on COMMON_CLK instead of ARCH_ZYNQ
> ---
> .../devicetree/bindings/i2c/i2c-cadence.txt| 21 +
> MAINTAINERS| 1 +
> drivers/i2c/busses/Kconfig | 7 +
> drivers/i2c/busses/Makefile| 1 +
> drivers/i2c/busses/i2c-cadence.c | 898
> +
> 5 files changed, 928 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cadence.txt
> create mode 100644 drivers/i2c/busses/i2c-cadence.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-cadence.txt
> b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt
> new file mode 100644
> index ..685adf513111
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt
> @@ -0,0 +1,21 @@
> +Binding for the Cadence I2C controller
> +
> +Required properties:
> + compatible: Compatibility string. Must be 'cdns,i2c-r1p10'.
> + clocks: From common clock bindings. Phandle to input clock.
> +
> +Optional properties:
> + clock-frequency: Desired operating frequency, in Hz, of the bus (actual may
> +be lower). Defaults to 40 if not specified.
> +
> +Example:
> +
> + i2c@e0004000 {
> + compatible = "cdns,i2c-r1p10";
> + clocks = < 38>;
> + interrupts = <0 25 4>;
> + reg = <0xE0004000 0x1000>;
> + clock-frequency = <40>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1ecfde109667..58b6bb1892d0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1403,6 +1403,7 @@ F: drivers/cpuidle/cpuidle-zynq.c
> N: zynq
> N: xilinx
> F: drivers/clocksource/cadence_ttc_timer.c
> +F: drivers/i2c/busses/i2c-cadence.c
> F: drivers/mmc/host/sdhci-of-arasan.c
>
> ARM SMMU DRIVER
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index f5ed03164d86..6754d2ed04b3 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -375,6 +375,13 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
> help
> The unit of the TWI clock is kHz.
>
> +config I2C_CADENCE
> + tristate "Cadence I2C Controller"
> + depends on COMMON_CLK
> + help
> + Say yes here to select Cadence I2C Host Controller. This controller is
> + e.g. used by Xilinx Zynq.
> +
> config I2C_CBUS_GPIO
> tristate "CBUS I2C driver"
> depends on GPIOLIB
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index a08931fe73e1..f9ebb8c6cdc1 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_I2C_AT91) += i2c-at91.o
> obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
> obj-$(CONFIG_I2C_BCM2835)+= i2c-bcm2835.o
> obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
> +obj-$(CONFIG_I2C_CADENCE)+= i2c-cadence.o
> obj-$(CONFIG_I2C_CBUS_GPIO) += i2c-cbus-gpio.o
> obj-$(CONFIG_I2C_CPM)+= i2c-cpm.o
> obj-$(CONFIG_I2C_DAVINCI)+= i2c-davinci.o
> diff --git a/drivers/i2c/busses/i2c-cadence.c
> b/drivers/i2c/busses/i2c-cadence.c
> new file mode 100644
> index ..bcc5eda3337b
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-cadence.c
> @@ -0,0 +1,898 @@
> +/*
> + * I2C bus driver for the Cadence I2C controller.
> + *
> + * Copyright (C) 2009 - 2014 Xilinx, Inc.
> + *
> + * This program is free software; you can redistribute it
> + * and/or modify it under the terms of the GNU General Public
> + * License as published by the Free Software Foundation;
> + * either version 2 of the License, or (at your option) any
> + * later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Register offsets for the I2C device. */
> +#define CDNS_I2C_CR_OFFSET 0x00 /* Control Register, RW */
> +#define CDNS_I2C_SR_OFFSET 0x04 /* Status Register, RO */
> +#define CDNS_I2C_ADDR_OFFSET 0x08 /* I2C Address Register, RW */
> +#define CDNS_I2C_DATA_OFFSET 0x0C /* I2C Data Register, RW */
> +#define CDNS_I2C_ISR_OFFSET 0x10 /* Interrupt Status Register, RW */
> +#define CDNS_I2C_XFER_SIZE_OFFSET0x14 /* Transfer Size Register, RW */
> +#define CDNS_I2C_TIME_OUT_OFFSET 0x1C /* Time Out Register, RW */
> +#define CDNS_I2C_IER_OFFSET 0x24 /* Interrupt Enable Register, WO */
> +#define CDNS_I2C_IDR_OFFSET 0x28 /* Interrupt Disable Register, WO */
> +
> +/* Control Register Bit mask definitions */
> +#define CDNS_I2C_CR_HOLD BIT(4) /* Hold Bus bit */
> +#define
Re: [PATCH] mm: msync: require either MS_ASYNC or MS_SYNC
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com writes: I think the only reasonable solution is to better document existing behavior and what the programmer should do. With that in mind, I've drafted the following text for the msync(2) man page: NOTES According to POSIX, exactly one of MS_SYNC and MS_ASYNC must be specified in flags. However, Linux permits a call to msync() that specifies neither of these flags, with semantics that are (currently) equivalent to specifying MS_ASYNC. (Since Linux 2.6.19, MS_ASYNC is in fact a no-op, since the kernel properly tracks dirty pages and flushes them to storage as necessary.) Notwithstanding the Linux behavior, portable, future-proof appli‐ cations should ensure that they specify exactly one of MS_SYNC and MS_ASYNC in flags. Comments on this draft welcome. I think it's a step backwards to document unspecified behavior. If anything, the man page should make it clear that providing neither flag results in undefined behavior and will lead to failure on systems on than Linux. While I can see the point of not changing the previous behavior to protect buggy code, there's no need to document it in the man page and further enshrine it. There's a larger point, which is that people write code for Linux when they should be writing code for POSIX. Therefore, Linux has an obligation to the larger free software community to avoid encouraging non-portable code. This is somewhat similar (except for the key point that it's unintentional) to bash's allowing == in test, which is a gratuitous extension to the standard that has led to large amounts of nonportable code. To mitigate this, it would be reasonable to syslog a warning the first time a process makes a call with flags that POSIX says leads to undefined behavior. That would meet the portability-citizenzhip goals and not break existing systems. pgpTIbf2O1ttb.pgp Description: PGP signature
cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/
Hi, I'm using cscope to browse kernel sources, but I'm facing warnings from the tool since following commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=22d651dcef536c75f75537290bf3da5038e68b6b commit 22d651dcef536c75f75537290bf3da5038e68b6b Author: Michael Ellerman m...@ellerman.id.au Date: Tue Jan 21 15:22:17 2014 +1100 selftests/powerpc: Import Anton's memcpy / copy_tofrom_user tests Turn Anton's memcpy / copy_tofrom_user test into something that can live in tools/testing/selftests. It requires one turd in arch/powerpc/lib/memcpy_64.S, but it's pretty harmless IMHO. We are sailing very close to the wind with the feature macros. We define them to nothing, which currently means we get a few extra nops and include the unaligned calls. Signed-off-by: Anton Blanchard an...@samba.org Signed-off-by: Michael Ellerman m...@ellerman.id.au Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org cscope reports error when generating the cross-reference database: $ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope GEN cscope cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S cscope: cannot find file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S And when calling cscope from ./obj-cscope/ directory, it reports errors too. Hopefully it doesn't stop it from working, so I'm still able to use cscope to browse kernel sources. It's a rather uncommon side effect of having (for the first time ?) sources files as symlinks: looking for symlinks in the kernel sources returns only: $ find . -type l ./arch/mips/boot/dts/include/dt-bindings ./arch/microblaze/boot/dts/system.dts ./arch/powerpc/boot/dts/include/dt-bindings ./arch/metag/boot/dts/include/dt-bindings ./arch/arm/boot/dts/include/dt-bindings ./tools/testing/selftests/powerpc/copyloops/copyuser_power7.S ./tools/testing/selftests/powerpc/copyloops/memcpy_64.S ./tools/testing/selftests/powerpc/copyloops/memcpy_power7.S ./tools/testing/selftests/powerpc/copyloops/copyuser_64.S ./obj-cscope/source ./Documentation/DocBook/vidioc-g-sliced-vbi-cap.xml ./Documentation/DocBook/vidioc-decoder-cmd.xml ... ./Documentation/DocBook/media-func-ioctl.xml ./Documentation/DocBook/vidioc-enumoutput.xml So one can wonder if having symlinked sources files is an expected supported feature for kbuild and all the various kernel tools/infrastructure ? Regarding cscope specifically, it does not support symlink, and it's the expected behavior according to the bug reports I was able to find: #214 cscope ignores symlinks to files http://sourceforge.net/p/cscope/bugs/214/ #229 -I options doesn't handle symbolic link http://sourceforge.net/p/cscope/bugs/229/ #247 cscope: cannot find file http://sourceforge.net/p/cscope/bugs/247/ #252 cscope: cannot find file *** http://sourceforge.net/p/cscope/bugs/252/ #261 Regression - version 15.7a does not follow symbolic links http://sourceforge.net/p/cscope/bugs/261/ Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: serial console does not wake from S3 suspend
Valerio Vanni vale...@valeriovanni.com ha scritto nel messaggio news:lg9etc$9fl$1...@ger.gmane.org When resuming from S3 suspend, serial console starts sending garbage on the serial port. Not continuously, it sends garbage only when in local console prints a text. It stops only when the (sending) machine is shut down, or if some text is sent manually (i.e. with cat txtfile /dev/ttyS0). Full details are here: https://bugzilla.kernel.org/show_bug.cgi?id=69751 The problem is still present in final 3.14 (and in linux-next). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.14 regression: huge latency in read/select on tun
On Thu, 2014-04-03 at 09:52 +0200, Ortwin Glück wrote:
On 02.04.2014 18:42, Eric Dumazet wrote:
You could post a tcpdump maybe ?
This is a dump from on the tun interface (traffic inside the tunnel).
It's an scp upload of a 2MB file. I aborted after a while when not much
progress was seen anymore, but you get the idea.
What I see:
- Frame 28: long delay because I had to enter the key password
- Frame 31: the packets seems to be out of order. It has a sequence
number that is far ahead of previously sent sequence no's. Some
duplicates and retransmissions follow. That pattern repeats randomly all
over the trace.
- from Frame 73 on: ping pong of ACKs and data, while the data is
delayed by ~200ms caused by the select(). The ping pong also shows that
there are virtually no packets in flight (see also Window size).
It seems TSO support is broken.
Your trace have no 'big' packets but holes like :
00:41:35.832695 IP 10.243.88.168.35846 10.185.85.69.22: Flags [.], ack 6093,
win 310, options [nop,nop,TS val 78054 ecr 3191538976], length 0
00:41:35.855990 IP 10.243.88.168.35846 10.185.85.69.22: Flags [P.], seq
6696:6776, ack 6093, win 310, options [nop,nop,TS val 78060 ecr 3191538976],
length 80
00:41:36.047465 IP 10.185.85.69.22 10.243.88.168.35846: Flags [P.], seq
6093:6141, ack 6776, win 218, options [nop,nop,TS val 3191539191 ecr 78060],
length 48
missing 6776:14144 sequence (6 segments)
00:41:36.048766 IP 10.243.88.168.35846 10.185.85.69.22: Flags [.], seq
14144:15372, ack 6141, win 310, options [nop,nop,TS val 78108 ecr 3191539191],
length 1228
00:41:36.057995 IP 10.185.85.69.22 10.243.88.168.35846: Flags [.], ack 6776,
win 218, options [nop,nop,TS val 3191539202 ecr 78060,nop,nop,sack 1
{14144:15372}], length 0
You are 'saved' because retransmits do not use TSO :
00:41:36.058050 IP 10.243.88.168.35846 10.185.85.69.22: Flags [.], seq
6776:8004, ack 6141, win 310, options [nop,nop,TS val 78110 ecr 3191539202],
length 1228
00:41:36.058070 IP 10.243.88.168.35846 10.185.85.69.22: Flags [.], seq
8004:9232, ack 6141, win 310, options [nop,nop,TS val 78110 ecr 3191539202],
length 1228
Also receiver seems to be unable to open TCP window, but thats a secondary
problem.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] ASoC: dapm: Add support for multi register mux
On 04/03/2014 11:53 AM, Mark Brown wrote: On Thu, Apr 03, 2014 at 11:47:15AM +0200, Takashi Iwai wrote: I'm a bit late in the game, but I feel a bit uneasy through looking at the whole changes. My primary question is, whether do we really need to share the same struct soc_enum for the onehot type? What makes hard to use a struct soc_enum_onehot for them? You need different individual get/put for each type. We may still need to change soc_dapm_update stuff, but it's different from sharing soc_enum. Indeed, I had thought this was where the discussion was heading - not looked at this version of the patch yet. It would be nice, but it also requires some slight restructuring. The issue we have right now is that there is strictly speaking a bit of a layering violation. The DAPM widgets should not need to know how the kcontrols that are attached to the widget do their IO. What we essentially do in dapm_connect_mux() (and also dapm_connect_mixer) is an open-coded version of the controls get handler. Replacing that by calling the get handler instead should allow us to use different structs for enums and onehot enums. - Lars -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 01/11] base: power: Add generic OF-based power domain look-up
On 3 April 2014 14:30, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Ulf, On 03.04.2014 14:16, Ulf Hansson wrote: On 3 March 2014 17:02, Tomasz Figa tomasz.f...@gmail.com wrote: This patch introduces generic code to perform power domain look-up using device tree and automatically bind devices to their power domains. Generic device tree binding is introduced to specify power domains of devices in their device tree nodes. Backwards compatibility with legacy Samsung-specific power domain bindings is provided, but for now the new code is not compiled when CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This will change as soon as Exynos power domain code gets converted to use the generic framework in further patch. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com --- .../devicetree/bindings/power/power_domain.txt | 51 drivers/base/power/domain.c| 298 + include/linux/pm_domain.h | 46 kernel/power/Kconfig | 4 + 4 files changed, 399 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt new file mode 100644 index 000..93be5d9 --- /dev/null +++ b/Documentation/devicetree/bindings/power/power_domain.txt @@ -0,0 +1,51 @@ +* Generic power domains + +System on chip designs are often divided into multiple power domains that +can be used for power gating of selected IP blocks for power saving by +reduced leakage current. + +This device tree binding can be used to bind power domain consumer devices +with their power domains provided by power domain providers. A power domain +provider can be represented by any node in the device tree and can provide +one or more power domains. A consumer node can refer to the provider by +a phandle and a set of phandle arguments (so called power domain specifier) +of length specified by #power-domain-cells property in the power domain +provider node. + +==Power domain providers== + +Required properties: + - #power-domain-cells : Number of cells in a power domain specifier; + Typically 0 for nodes representing a single power domain and 1 for nodes + providing multiple power domains (e.g. power controllers), but can be + any value as specified by device tree binding documentation of particular + provider. I am trying to understand if using a value 1, ever would make sense. Wouldn't that mean each consumer (device) would actually be a part of more than one power domain? That won't work, right!? Not exactly. Each phandle + #power-domain-cells cells are used just for single power domain. The cells here are used merely as the identifier used by power domain driver to translate a power domain specifier from DT to a kernel pointer. It's up to driver bindings to select the number of cells to properly identify a power domain. As an example (from different world, but showing the same mechanism), let's see a common pattern of GPIO banks on some SoC: GPA0 GPA1 GPB0 GPB1 GPC0 GPC1 One might assign a single-cell ID to each bank ending with a namespace of integers from 0 to 5 that would be used as follows: #define GPA0 0 #define GPA1 1 #define GPB0 2 #define GPB1 3 #define GPC0 4 #define GPC1 5 reset-gpios = gpio GPA0 4; However one might also consider assigning one cell to bank set (e.g. GPA) and one cell to identify the bank inside of a set, like on the following example: #define GPA 0 #define GPB 1 #define GPC 2 reset-gpios = gpio GPA 0 4; Good bindings should allow arbitrary identification schemes to let a driver developer use the one that suits the hardware he's working on. Additionally, there are no corresponding parsing method (like of_genpd_xlate_onecell() ) that support more than one cell. There are two generic xlate helpers provided for the most common cases that are likely to be reused by most drivers. For more complex cases it's up to the driver to implement its own mapping function. It can be promoted to a generic one later if such need shows up. Best regards, Tomasz Tomasz, thanks for the clarification! I still have more to learn about DT. :-) Not sure if some additional comments would make this more clear though - or if it's juts my untrained eye that had a few problems understanding. Kind regards Ulf Hansson -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [Linaro-acpi] How to pass I2C platform_data under ACPI
On Thursday 03 April 2014 14:38:33 mika.westerb...@linux.intel.com wrote:
On Thu, Apr 03, 2014 at 11:25:34AM +, Pallala, Ramakrishna wrote:
In non ACPI environment I used to initialize the platform_data under
board or platforms files. Under ACPI how do I do that?
If you can't extract that information from ACPI namespace, then one option
is to pass platform data along with the device ACPI ID:
static const struct acpi_device_id my_acpi_match[] = {
{ MYID0001, (kernel_ulong_t)my_platform_data }
...
{ },
};
Thanks for the Quick reply.
So If I want to use different platform_data for different boards can I
do something like below?
Exactly.
And initialize the platform data in either driver or in separate module
which gets compiled along with driver?
Typically it has been done in the same driver but I don't see any problems
having a separate module as well.
static const struct acpi_device_id my_acpi_match[] = {
{ MYID0001, (kernel_ulong_t)my_platform_data1 }
{ MYID0002, (kernel_ulong_t)my_platform_data2 }
...
{ },
We definitely don't want per-board match entries, that does not scale.
The driver should be reasonably generic and get all the necessary data
out of well-defined tables. You can have different IDs when there
are only a few cases that are actually relevant, but it has to be
conceivable that the same driver get used on future hardware without
changes.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] blkdev: use an efficient way to check merge flags
Hi, Jan,
I've just renewed the patch as you suggusted. Actually it isn't quite
performance sensitive, but the point is one less branch leads to
less penalty caused by branch prediction failure. Ok, this may be
way too paranoid.:-)
A bitwise flag comparison could be done using a more efficient bit-ops
way, by mimicking GCC logic of optimizing such bitwise comparison.
Signed-off-by: Jianyu Zhan nasa4...@gmail.com
---
include/linux/blkdev.h | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 1e1fa3f..f2b79fc 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -655,16 +655,18 @@ static inline bool rq_mergeable(struct request *rq)
static inline bool blk_check_merge_flags(unsigned int flags1,
unsigned int flags2)
{
- if ((flags1 REQ_DISCARD) != (flags2 REQ_DISCARD))
- return false;
-
- if ((flags1 REQ_SECURE) != (flags2 REQ_SECURE))
- return false;
-
- if ((flags1 REQ_WRITE_SAME) != (flags2 REQ_WRITE_SAME))
- return false;
-
- return true;
+ /*
+* Check whether all tree flags are the same in both
+* flags.
+*
+* Replace original three-if's comparision with a
+* more efficient method, by mimicking the GCC logic of
+* optimizing such bitwise comparion. This makes GCC
+* to spit out most compact and least brach code.
+*/
+ return ((flags1 ^ flags2)
+ (REQ_DISCARD | REQ_SECURE | REQ_WRITE_SAME))
+ == 0;
}
static inline bool blk_write_same_mergeable(struct bio *a, struct bio *b)
--
1.9.0.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] x86: reboot doesn't reboot
On Thu, 03 Apr 2014 14:30:50 +0800 Li, Aubrey aubrey...@linux.intel.com wrote: May I know if reboot=t make any difference on your system with the change? Is this the future fix? Or do you have patches for me to test. I'll be happy to test any patches you have on this box. If you need to know anything about this box, let me know and I'll run any command that would help you. 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/
