[PATCH 2/2] ASoC: core: fix the memory leak in case of remove_aux_dev()
When probing aux_dev, initializing is as below:
device_initialize()
device_add()
So when remove aux_dev, we need do as below:
device_del()
device_put()
Otherwise, the rtd_release() will not be called.
So here using device_unregister() to replace device_del(),
like the action in soc_remove_link_dais().
Signed-off-by: liu chuansheng
---
sound/soc/soc-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 9689411..2270f8f 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1556,7 +1556,7 @@ static void soc_remove_aux_dev(struct snd_soc_card *card,
int num)
/* unregister the rtd device */
if (rtd->dev_registered) {
device_remove_file(rtd->dev, _attr_codec_reg);
- device_del(rtd->dev);
+ device_unregister(rtd->dev);
rtd->dev_registered = 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ASoC: core: fix the memory leak in case of device_add() failure
After called device_initialize(), even device_add() returns
error, we still need use the put_device() to release the reference
to call rtd_release(), which will do the free() action.
Signed-off-by: liu chuansheng
---
sound/soc/soc-core.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 91d592f..9689411 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1255,6 +1255,8 @@ static int soc_post_component_init(struct snd_soc_card
*card,
INIT_LIST_HEAD(>dpcm[SNDRV_PCM_STREAM_CAPTURE].fe_clients);
ret = device_add(rtd->dev);
if (ret < 0) {
+ /* calling put_device() here to free the rtd->dev */
+ put_device(rtd->dev);
dev_err(card->dev,
"ASoC: failed to register runtime device: %d\n", ret);
return ret;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic when running /etc/init.d/iptables restart
Hi Gao feng The stack information is as follows. The kenel will panic because the nf_ct_destroy is NULL. Reproduction: (1) starting a lxc container (2) iptables -t nat -A POSTROUTING -s 10.48.254.18 -o eth1 -j MASQUERADE (run it on host machine) (3) /etc/ini.d/iptables save (run it on host machine) (4)/etc/init.d/iptables restart (run it on host machine) Stack: Pid: 0, comm: swapper Not tainted 2.6.32-279.14.1.rc3.el6.x86_64 #1 IBM System x3650 M4 -[7915IA4]-/00J6528 RIP: 0010:[] [] nf_conntrack_destroy+0x19/0x30 RSP: 0018:880028303ab0 EFLAGS: 00010246 RAX: RBX: 881051b237c0 RCX: 00d4 RDX: 0500 RSI: RDI: 881056bc0528 RBP: 880028303ab0 R08: 8810514fc020 R09: 8810574b6110 R10: R11: 0004 R12: 814445fe R13: 88105327fba8 R14: 882059ed6e00 R15: FS: () GS:88002830() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 7f3484002098 CR3: 002056792000 CR4: 000406e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process swapper (pid: 0, threadinfo 8810590b2000, task 88205954c040) Stack: 880028303ad0 8142febd 880028303b30 881051b237c0 880028303af0 8142fc36 00020004 881051b237c0 880028303b20 8142fd82 880028303b20 882059ed6d80 Call Trace: [] skb_release_head_state+0xed/0x110 [] __kfree_skb+0x16/0xa0 [] kfree_skb+0x42/0x90 [] __neigh_event_send+0x11e/0x1e0 [] neigh_resolve_output+0x133/0x370 [] ? select_idle_sibling+0x95/0x150 [] ip_finish_output+0x237/0x310 [] ip_output+0xb8/0xc0 [] ip_local_out+0x25/0x30 [] ip_queue_xmit+0x190/0x420 [] ? try_to_wake_up+0x24c/0x3e0 [] tcp_transmit_skb+0x3fe/0x7b0 [] tcp_retransmit_skb+0x1ba/0x5f0 [] ? __wake_up+0x53/0x70 [] ? tcp_write_timer+0x0/0x200 [] tcp_retransmit_timer+0x1df/0x680 [] tcp_write_timer+0x198/0x200 [] run_timer_softirq+0x197/0x340 [] ? tick_sched_timer+0x0/0xc0 [] ? lapic_next_event+0x1d/0x30 [] __do_softirq+0xc1/0x1e0 [] ? hrtimer_interrupt+0x140/0x250 [] call_softirq+0x1c/0x30 [] do_softirq+0x65/0xa0 [] irq_exit+0x85/0x90 [] smp_apic_timer_interrupt+0x70/0x9b [] apic_timer_interrupt+0x13/0x20 [] ? intel_idle+0xde/0x170 [] ? intel_idle+0xc1/0x170 [] ? sched_clock_cpu+0xcd/0x110 [] cpuidle_idle_call+0xa7/0x140 [] cpu_idle+0xb6/0x110 [] start_secondary+0x22a/0x26d Code: 02 ff d0 c9 c3 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 48 8b 05 90 7c ba 00 48 85 c0 74 04 ff d0 c9 c3 <0f> 0b 0f 1f 44 00 00 eb f9 66 66 66 66 66 2e 0f 1f 84 00 00 00 2012/12/25 Gao feng : > cc netdev > Hi canqun: > > On 2012/12/24 13:51, canqun zhang wrote: >> Hi Patrick， >> If i start one lxc container instance, and then in the system there >> will be two net namespaces,one is init_net namespace, the other is >> created by lxc.If running "/etc/init.d/iptables restart",the system >> will be panic. I find iptables restarting will clean init_net >> namespace firstly,then clean the net namespace created by lxc,buf >> related functions about cleaning up init_net namespace will destroy >> global variables such as nf_ct_destroy,ip_ct_attach，etc.So,funtions >> cleaning up the other net namespace will be panic. >> > > I'm afraid that the system will not panic. > When do rmmod nf_conntrack_ipv[4,6],we already call nf_ct_iterate_cleanup > to destroy the nf_conns which belongs to l[3,4]proto protocols,At this > time the nf_ct_destroy still points to destroy_conntrack because the module > nf_conntrack is hold by l3 and l4proto. > You can check the function nf_conntrack_l[3,4]proto_unregister. > > Can you make it a little clear? > The reproduction and oops dump stack is useful. > > 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: kernel panic when running /etc/init.d/iptables restart
cc netdev Hi canqun: On 2012/12/24 13:51, canqun zhang wrote: > Hi Patrick， > If i start one lxc container instance, and then in the system there > will be two net namespaces,one is init_net namespace, the other is > created by lxc.If running "/etc/init.d/iptables restart",the system > will be panic. I find iptables restarting will clean init_net > namespace firstly,then clean the net namespace created by lxc,buf > related functions about cleaning up init_net namespace will destroy > global variables such as nf_ct_destroy,ip_ct_attach，etc.So,funtions > cleaning up the other net namespace will be panic. > I'm afraid that the system will not panic. When do rmmod nf_conntrack_ipv[4,6],we already call nf_ct_iterate_cleanup to destroy the nf_conns which belongs to l[3,4]proto protocols,At this time the nf_ct_destroy still points to destroy_conntrack because the module nf_conntrack is hold by l3 and l4proto. You can check the function nf_conntrack_l[3,4]proto_unregister. Can you make it a little clear? The reproduction and oops dump stack is useful. 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] ARM: tegra: dts: add aliases and DMA requestor for serial controller
On 12/22/2012 01:15 PM, Laxman Dewangan wrote: > On Saturday 22 December 2012 02:20 AM, Stephen Warren wrote: >> On 12/20/2012 09:18 PM, Laxman Dewangan wrote: >>> On Thursday 20 December 2012 10:33 PM, Stephen Warren wrote: On 12/19/2012 11:15 PM, Laxman Dewangan wrote: > On Wednesday 19 December 2012 10:30 PM, Stephen Warren wrote: >> On 12/18/2012 11:31 PM, Laxman Dewangan wrote: >>> Add APB DMA requestor and serial aliases for serial controller. >>> There will be two serial driver i.e. 8250 based simple serial driver >>> and APB DMA based serial driver for higher baudrate and performace. >> ... >> This patch seems to do two things: >> ... >> 2) Add aliases for the serial ports. I have no idea why this is >> useful. > Serial aliases are added because we want to get the port number like > /dev/ttyTHS0, /d/ttyTHS2 etc. The uarta should be /dev/ttyTHS0 and > uartc should be /dev/ttyTHS2. The port number can be found using > aliases > and of_alias_get_id() in driver file: > > port_number = of_alias_get_id(np, "serial"); Oh, I see. I guess the aliases make sense then. But, wouldn't you only add aliases for the specific UARTs that are in use on a particular board (so put them in tegraNN-board.dts) rather than all UARTs on Tegra (i.e. the current patch which puts them into tegraNN.dtsi)? >>> I like to have this in tegraN N.dtsi file becasue: >>> - This policy is not going to change the board to board. For high speed >>> driver the uarta will be ttyTHS0 and uartb ttyTHS1. >> Sure it is. Since the board files select which UARTs use the low-speed >> driver vs. the high-speed driver by overriding the compatible value, >> each board will have a different subset of UARTs which use the high >> speed driver and hence which use the aliases. Don't you want to end up >> with /dev/ttyHS0 on each board, rather than ending up with a "random" >> device node name depending on which UART the board designer picked for >> the high speed device? > > We had this in past where we started the high speed driver always from 0 > like in one board uartc become ttyHS0 and another board uarta become > ttyHS0 and uartc become ttyHS1. > This confused more to other team (BT and modem team) as they need to > know all uart instance and their corresponding driver. So we kept uarta That doesn't really make sense; The BT and MODEM team should only care about the specific UARTs they use. > will be always 0 and uartc will be always 2. That seems a little unlikely; why can't different boards use different UARTs for different purposes; after all, UARTA is often a debug UART not a BT or MODEM UART. > This way it is straight > forward for the uart user to directly see the uart instance on board and > decide the port number rather than going to what are other uart and > their corresponding driver. Still, there is some precedent in the kernel for your approach. So, I guess we can go ahead with using the aliases as-is. Your approach breaks down in the following scenarios though: a) Somebody (random customer board designer or SW engineer, who NVIDIA can't control) wants the console UART to always have alias serial0; there are examples of this in the kernel. On just the boards we support upstream, some use UART A for the debug/console and some use UART D. I know of others that use UART B. b) The board contains UARTs (e.g. PCIe) that aren't the Tegra-internal UARTs, so the alias IDs can't all map to Tegra UART IDs. c) Conceptually, the purpose of aliases seems to be to provide useful names (numbers) for the relevant ports, and naming/numbering non-existent ports doesn't seem particularly useful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] KVM: Write protect the updated slot only when we start dirty logging
On Tue, 25 Dec 2012 07:05:55 +0200 Gleb Natapov wrote: > > Other parts are doing "if (!slot->dirty_bitmap)" to see if the slot > > is in dirty logging mode. If you prefer, we can do the same here. > > > Does not matter to me. If you think it will be more consistent do it. No preference at the moment. But since .dirty_bitmap and .rmap may be changed to control free_physmem(new, old) behaviour, I'll keep the code as is. I'll send some patches to clean up the current "mem, new, old, slot" games in __kvm_set_memory_region() later. I was confused many times by these. In addition, passing old slot by value to kvm_arch_commit_memory_region() should be fixed as well. The structure is too big to copy. Thanks, Takuya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv4 5/8] drm: tegra: Remove redundant host1x
On 12/21/2012 11:50 PM, Terje Bergström wrote:
> On 21.12.2012 16:36, Thierry Reding wrote:
>> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
>>> +static struct platform_driver tegra_drm_platform_driver = {
>>> + .driver = {
>>> + .name = "tegradrm",
>>
>> This should be "tegra-drm" to match the module name.
>
> We've actually created two problems.
>
> First is that the device name should match driver name which should
> match module name. But host1x doesn't know the module name of tegradrm.
There's no hard requirement for the device/driver name to match the
module name. It's good thing to do, but nothing will blow up if it don't
(modules can use MODULE_ALIAS() to declare which drivers they expose).
But, what's the problem with host1x knowing the driver name; the host1x
driver and tegradrm driver are both part of the same code-base, so this
seems trivial to achieve.
> Second problem is that host1x driver creates tegradrm device even if
> tegradrm isn't loaded to system.
That's fine. If there's no driver, the device simply won't be probe()d.
That's just like a device node existing in device tree, but the driver
for it not being enabled in the kernel, or the relevant module not being
inserted.
> These mean that the device has to be created in tegra-drm module to have
I definitely disagree here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] KVM: Write protect the updated slot only when we start dirty logging
On Tue, Dec 25, 2012 at 01:08:40PM +0900, Takuya Yoshikawa wrote: > On Mon, 24 Dec 2012 15:27:17 +0200 > Gleb Natapov wrote: > > > > @@ -6897,7 +6897,14 @@ void kvm_arch_commit_memory_region(struct kvm *kvm, > > > spin_lock(>mmu_lock); > > > if (nr_mmu_pages) > > > kvm_mmu_change_mmu_pages(kvm, nr_mmu_pages); > > > - kvm_mmu_slot_remove_write_access(kvm, mem->slot); > > > + /* > > > + * Write protect all pages for dirty logging. > > > + * Existing largepage mappings are destroyed here and new ones will > > > + * not be created until the end of the logging. > > > + */ > > > + if ((mem->flags & KVM_MEM_LOG_DIRTY_PAGES) && > > > + !(old.flags & KVM_MEM_LOG_DIRTY_PAGES)) > > > + kvm_mmu_slot_remove_write_access(kvm, mem->slot); > > We should not check old slot flags here or at least check that > > old.npages is not zero. Userspace may delete a slot using old flags, > > then, if new memslot is created with dirty log enabled, it will not be > > protected. > > The flag, KVM_MEM_LOG_DIRTY_PAGES, is explicitely cleared when we > delete a slot to free dirty_bitmap: > > if (!npages) > mem->flags &= ~KVM_MEM_LOG_DIRTY_PAGES; > > So when old.npages is not zero, the second condition must be true. > Right. I was looking for where it is cleared and missed that. > Other parts are doing "if (!slot->dirty_bitmap)" to see if the slot > is in dirty logging mode. If you prefer, we can do the same here. > Does not matter to me. If you think it will be more consistent do it. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: debug clock tree
On Monday 24 December 2012 11:07 PM, Mike Turquette wrote: On Sun, Dec 23, 2012 at 4:26 AM, Prashant Gaikwad wrote: On Saturday 22 December 2012 04:26 AM, Mike Turquette wrote: On Wed, Dec 19, 2012 at 11:53 PM, Prashant Gaikwad wrote: On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad wrote: Adds debug file "clock_tree" in /sys/kernel/debug/clk dir. It helps to view all the clock registered in tree format. Prashant, Thanks for submitting this. We've been talking about having a single file for representing the tree for some time. Regarding the output format had you considered using a well known format which can be parsed using well known parsing libs? This avoids needing a custom parser just for this one file. JSON springs to mind as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. For example: clockenable_cnt prepare_cnt rate - i2s0_sync 0 02400 spdif_in_sync 0 02400 spdif_mux 0 02400 spdif0 02400 spdif_doubler 0 04800 spdif_div 0 04800 spdif_2x0 04800 Even I think that output must be easily human-readable. How about adding sysfs to switch between human-readable and machine-readable format? I will try come up with a implementation. Do you mean a sysfs file which controls the output format? How about just two different files? One can be clk-dump (machine readable) and the other is clk-summary (human readable). It is also fine. Is this patch ok for human-readable format? or any suggestions? I will change the file name to clk-summary. Prashant, Yes the format seems to be agreeable for human-readable format based on the feedback on the list. Go ahead and keep the column titles and the dashed lines that I commented on earlier... my comments are less relevant if a separate machine-readable clk-dump file exists. Thanks Mike!! Are you going to take a crack at JSON-formatted output for clk-dump? I will work on it. Thanks, Mike Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 6:31 AM, Borislav Petkov wrote: > On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote: >> Right, let me try that and report back. > > Yep, looks like reverting the above commit fixes it - the boston.com > website loads just fine. > > Thanks. > > -- > Regards/Gruss, > Boris. Saw the same error and after reading this thread, reverted the Commit 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2. drm/radeon: use async dma for ttm buffer moves on 6xx-SI and the problem is gone. In my case, it is a solid hang right after system switches to vga. I was able to login on console once or twice. But dmesg showed the same message reported in this thread: [ 35.812085] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 35.812091] radeon :01:00.0: GPU lockup (waiting for 0x0002 last fence id 0x0001) My system has: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at mm/huge_memory.c:1798!
Hello all, I found the below kernel bug using latest mainline(637704cbc95), my hardware has 2 numa nodes, and it's easy to reproduce the issue using LTP test case: "# ./mmap10 -a -s -c 200": [root@localhost linux]# cat .config | grep NUMA CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_ARCH_USES_NUMA_PROT_NONE=y CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y CONFIG_NUMA_BALANCING=y # CONFIG_X86_NUMACHIP is not set CONFIG_NUMA=y CONFIG_AMD_NUMA=y CONFIG_X86_64_ACPI_NUMA=y # CONFIG_NUMA_EMU is not set CONFIG_USE_PERCPU_NUMA_NODE_ID=y CONFIG_ACPI_NUMA=y --- [ 588.143072] mapcount 0 page_mapcount 3 [ 588.147471] [ cut here ] [ 588.152856] kernel BUG at mm/huge_memory.c:1798! [ 588.158125] invalid opcode: [#1] SMP [ 588.162882] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables bnep bluetooth rfkill iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi vfat fat dm_mirror dm_region_hash dm_log dm_mod cdc_ether iTCO_wdt i7core_edac coretemp usbnet iTCO_vendor_support mii crc32c_intel edac_core lpc_ich shpchp ioatdma mfd_core i2c_i801 pcspkr serio_raw bnx2 microcode dca vhost_net tun macvtap macvlan kvm_intel kvm uinput mgag200 sr_mod cdrom i2c_algo_bit sd_mod drm_kms_helper crc_t10dif ata_generic pata_acpi ttm ata_piix drm libata i2c_core megaraid_sas [ 588.246517] CPU 1 [ 588.248636] Pid: 23217, comm: mmap10 Not tainted 3.8.0-rc1mainline+ #17 IBM IBM System x3400 M3 Server -[7379I08]-/69Y4356 [ 588.262171] RIP: 0010:[] [] __split_huge_page+0x677/0x6d0 [ 588.272067] RSP: :88017a03fc08 EFLAGS: 00010293 [ 588.278235] RAX: 0003 RBX: 88027a6c22e0 RCX: 34d2 [ 588.286394] RDX: 748b RSI: 0046 RDI: 0246 [ 588.294216] RBP: 88017a03fcb8 R08: 819d2440 R09: 054a [ 588.302441] R10: 00aa R11: R12: [ 588.310495] R13: 7f4f11a0 R14: 880179e96e00 R15: ea0005c08000 [ 588.318640] FS: 7f4f11f4a740() GS:88017bc2() knlGS: [ 588.327894] CS: 0010 DS: ES: CR0: 8005003b [ 588.334569] CR2: 0037e9ebb404 CR3: 00017a436000 CR4: 07e0 [ 588.342718] DR0: DR1: DR2: [ 588.350861] DR3: DR6: 0ff0 DR7: 0400 [ 588.359134] Process mmap10 (pid: 23217, threadinfo 88017a03e000, task 880172dd32e0) [ 588.368667] Stack: [ 588.370960] 88017a540ec8 88017a03fc20 816017b5 88017a03fc88 [ 588.379566] 812fa014 880279ebd5c0 f4f11a4c [ 588.388150] 0007f4f11f49 0007f4f11a00 88017a540ef0 88017a540ee8 [ 588.396711] Call Trace: [ 588.455106] [] ? rwsem_down_read_failed+0x15/0x17 [ 588.518106] [] ? call_rwsem_down_read_failed+0x14/0x30 [ 588.580897] [] ? down_read+0x24/0x2b [ 588.642630] [] split_huge_page+0x68/0xb0 [ 588.703814] [] __split_huge_page_pmd+0x134/0x330 [ 588.766064] [] ? pte_alloc_one+0x37/0x50 [ 588.826460] [] split_huge_page_pmd_mm+0x51/0x60 [ 588.887746] [] split_huge_page_address+0x3b/0x50 [ 588.948673] [] __vma_adjust_trans_huge+0x9c/0xf0 [ 589.008660] [] vma_adjust+0x684/0x750 [ 589.066328] [] __split_vma.isra.28+0x1fa/0x220 [ 589.123497] [] ? __switch_to+0x181/0x4a0 [ 589.180704] [] do_munmap+0xf9/0x420 [ 589.237461] [] ? __schedule+0x3cc/0x7b0 [ 589.294520] [] vm_munmap+0x4e/0x70 [ 589.350784] [] sys_munmap+0x2b/0x40 [ 589.406971] [] system_call_fastpath+0x16/0x1b [ 589.464792] Code: 49 8b 07 a9 00 00 00 01 75 f4 e9 2d fb ff ff 41 8b 4f 18 8b 75 8c 48 c7 c7 f8 27 81 81 31 c0 83 c1 01 e8 df 63 46 00 0f 0b 0f 0b <0f> 0b 41 8b 57 18 8b 75 8c 48 c7 c7 d8 27 81 81 31 c0 83 c2 01 [ 589.595165] RIP [] __split_huge_page+0x677/0x6d0 [ 589.656000] RSP [ 589.713937] ---[ end trace bff29bee67936f30 ]--- -- Thanks, Zhouping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2.0 (EHCI) keeps crapping out (3.2.29)
On 12/24/2012 11:10 PM, Rob Landley wrote: On 12/24/2012 09:02:11 PM, Logan Rathbone wrote: *** NOTE: Kindly CC me directly if you reply to list since I'm not an LKML subscriber. *** Running vanilla 3.2.29 (Slackware 14.0). I also had this issue on 2.6.37.6 and *possibly* 2.6.33.x, but I don't recall. Every now and again (could be every few days, could take a couple of weeks... depends.) USB 2.0 stops working. My scanner as well as certain mass-storage devices that are USB-2.0 compatible fail to function all of a sudden. With the said mass storage devices, I get lots of errors like this in my logs: hub 1-0:1.0: unable to enumerate USB device on port 3 What is the _first_ error that shows up in dmesg when the failure occurs? I *think* this is the first error that appears: usb 1-3: USB disconnect, device number 3 sd 5:0:0:0: Device offlined - not ready after error recovery That second message is sometimes: usblp0: removed But honestly I can't recall if my USB 2.0 printer stopped working at that point in time. The effect of the crap-out is mainly noticeable on my mass storage devices since I can't mount them (the device nodes do not get created by udev until I rmmod & modprobe ehci_hcd again or reboot). I also see stuff like this scattered throughout (hard to tell if it's one of the first or last errors that pops up though... I think it's the last. It usually pops up after a whole whack of the "unable to enumerate" errors: ehci_hcd :00:10.3: force halt; handshake f8044014 c000 -> -110 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2.0 (EHCI) keeps crapping out (3.2.29)
On 12/24/2012 09:02:11 PM, Logan Rathbone wrote: *** NOTE: Kindly CC me directly if you reply to list since I'm not an LKML subscriber. *** Running vanilla 3.2.29 (Slackware 14.0). I also had this issue on 2.6.37.6 and *possibly* 2.6.33.x, but I don't recall. Every now and again (could be every few days, could take a couple of weeks... depends.) USB 2.0 stops working. My scanner as well as certain mass-storage devices that are USB-2.0 compatible fail to function all of a sudden. With the said mass storage devices, I get lots of errors like this in my logs: hub 1-0:1.0: unable to enumerate USB device on port 3 What is the _first_ error that shows up in dmesg when the failure occurs? Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] KVM: Write protect the updated slot only when we start dirty logging
On Mon, 24 Dec 2012 15:27:17 +0200 Gleb Natapov wrote: > > @@ -6897,7 +6897,14 @@ void kvm_arch_commit_memory_region(struct kvm *kvm, > > spin_lock(>mmu_lock); > > if (nr_mmu_pages) > > kvm_mmu_change_mmu_pages(kvm, nr_mmu_pages); > > - kvm_mmu_slot_remove_write_access(kvm, mem->slot); > > + /* > > +* Write protect all pages for dirty logging. > > +* Existing largepage mappings are destroyed here and new ones will > > +* not be created until the end of the logging. > > +*/ > > + if ((mem->flags & KVM_MEM_LOG_DIRTY_PAGES) && > > + !(old.flags & KVM_MEM_LOG_DIRTY_PAGES)) > > + kvm_mmu_slot_remove_write_access(kvm, mem->slot); > We should not check old slot flags here or at least check that > old.npages is not zero. Userspace may delete a slot using old flags, > then, if new memslot is created with dirty log enabled, it will not be > protected. The flag, KVM_MEM_LOG_DIRTY_PAGES, is explicitely cleared when we delete a slot to free dirty_bitmap: if (!npages) mem->flags &= ~KVM_MEM_LOG_DIRTY_PAGES; So when old.npages is not zero, the second condition must be true. Other parts are doing "if (!slot->dirty_bitmap)" to see if the slot is in dirty logging mode. If you prefer, we can do the same here. Thanks, Takuya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table
On Mon, Dec 24, 2012 at 4:16 PM, H. Peter Anvin wrote: > On 12/20/2012 08:56 AM, Yinghai Lu wrote: >>> >>> >>> So in that case, kgdb is broken and will need to be fixed up. That >>> happens all the time with debugging tools. >> >> >> If there is a way that we can make all parties happy, we really should >> not break KGDB. >> >> Please reconsider to stop #PF handler in x86_64_start_kernel. in that case >> 1. microcode update still can use #PF handler to find microcode in >> ramdisk and use it. >> 2. kernel that is loaded above 4G, could set mapping in C instead of >> set that in head_64.S >> and use ioremap to access zero_page >> 3. KGDB still can call early_trap_init early before init_mem_mapping. >> > > Yinghai, this is total and utter bullshit. > > We should *fix* kgdb, not pave around it. I refuse to have kgdb be yet > another Xen turning random kernel internals into ABIs. well, I updated for-x86-boot-v7 that stop #PF handler after init_mem_mapping. it has fix for AMD system aka reverting far jmp to ret. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/25] kprobes: fix wait_for_kprobe_optimizer()
(2012/12/22 10:57), Tejun Heo wrote:
> wait_for_kprobe_optimizer() seems largely broken. It uses
> optimizer_comp which is never re-initialized, so
> wait_for_kprobe_optimizer() will never wait for anything once
> kprobe_optimizer() finishes all pending jobs for the first time.
Thank you for fixing that!
I must misunderstand that the DECLARE_COMPLETION() macro.
> Also, aside from completion, delayed_work_pending() is %false once
> kprobe_optimizer() starts execution and wait_for_kprobe_optimizer()
> won't wait for it.
>
> Reimplement it so that it flushes optimizing_work until
> [un]optimizing_lists are empty. Note that this also makes
> optimizing_work execute immediately if someone's waiting for it, which
> is the nicer behavior.
I think your enhancement is reasonable and GOOD for me.
Thanks again!
Acked-by: Masami Hiramatsu
>
> Only compile tested.
>
> Signed-off-by: Tejun Heo
> Cc: Ananth N Mavinakayanahalli
> Cc: Anil S Keshavamurthy
> Cc: "David S. Miller"
> Cc: Masami Hiramatsu
> ---
> Please let me know how this patch should be routed. I can take it
> through the workqueue tree if necessary.
>
> Thanks.
>
> kernel/kprobes.c | 23 +++
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 098f396..f230e81 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -471,7 +471,6 @@ static LIST_HEAD(unoptimizing_list);
>
> static void kprobe_optimizer(struct work_struct *work);
> static DECLARE_DELAYED_WORK(optimizing_work, kprobe_optimizer);
> -static DECLARE_COMPLETION(optimizer_comp);
> #define OPTIMIZE_DELAY 5
>
> /*
> @@ -552,8 +551,7 @@ static __kprobes void do_free_cleaned_kprobes(struct
> list_head *free_list)
> /* Start optimizer after OPTIMIZE_DELAY passed */
> static __kprobes void kick_kprobe_optimizer(void)
> {
> - if (!delayed_work_pending(_work))
> - schedule_delayed_work(_work, OPTIMIZE_DELAY);
> + schedule_delayed_work(_work, OPTIMIZE_DELAY);
> }
>
> /* Kprobe jump optimizer */
> @@ -592,16 +590,25 @@ static __kprobes void kprobe_optimizer(struct
> work_struct *work)
> /* Step 5: Kick optimizer again if needed */
> if (!list_empty(_list) || !list_empty(_list))
> kick_kprobe_optimizer();
> - else
> - /* Wake up all waiters */
> - complete_all(_comp);
> }
>
> /* Wait for completing optimization and unoptimization */
> static __kprobes void wait_for_kprobe_optimizer(void)
> {
> - if (delayed_work_pending(_work))
> - wait_for_completion(_comp);
> + mutex_lock(_mutex);
> +
> + while (!list_empty(_list) ||
> !list_empty(_list)) {
> + mutex_unlock(_mutex);
> +
> + /* this will also make optimizing_work execute immmediately */
> + flush_delayed_work(_work);
> + /* @optimizing_work might not have been queued yet, relax */
> + cpu_relax();
> +
> + mutex_lock(_mutex);
> + }
> +
> + mutex_unlock(_mutex);
> }
>
> /* Optimize kprobe if p is ready to be optimized */
>
--
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/
[PATCH] sched: Fix print format for u64
From: Fabio Estevam commit c566e8e9 (sched: Aggregate total task_group load) introduced the following build warning: kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'u64' [-Wformat] kernel/sched/debug.c:225:2: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'u64' [-Wformat] Signed-off-by: Fabio Estevam --- kernel/sched/debug.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c index 2cd3c1b..83ec463 100644 --- a/kernel/sched/debug.c +++ b/kernel/sched/debug.c @@ -222,7 +222,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq) cfs_rq->runnable_load_avg); SEQ_printf(m, " .%-30s: %lld\n", "blocked_load_avg", cfs_rq->blocked_load_avg); - SEQ_printf(m, " .%-30s: %ld\n", "tg_load_avg", + SEQ_printf(m, " .%-30s: %lld\n", "tg_load_avg", atomic64_read(_rq->tg->load_avg)); SEQ_printf(m, " .%-30s: %lld\n", "tg_load_contrib", cfs_rq->tg_load_contrib); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 25/25] ipc: don't use [delayed_]work_pending()
Hello, On Mon, Dec 24, 2012 at 08:41:01PM +0100, Borislav Petkov wrote: > On Mon, Dec 24, 2012 at 10:45:20AM -0800, Tejun Heo wrote: > > I was confused a bit there. We can't. Nothing guarantees that the > > queuer sees the cleared PENDING before the work item starts execution, > > and I think ipc memory hotplug could also be broken from that. > > Stupid question: why not clear PENDING after execution is done? I'm > looking at process_one_work() here. The behavior is primarily because we want to enable workqueue users to guarantee that a full work item execution happens at least once after certain event happens. ie. Let's say there's a work item which processes data generated by a device. If it's IRQ handler calls queue_work() after getting notified of new data segment by the device, it would want to guarantee that whole work item execution would happen afterwards. If you clear PENDING after execution, the event may overlap with the end of the previous execution and the new data won't be processed. > > It's highly unlikely to actually happen and there may be external > > locking which prevents the race from actually happening, but there's > > nothing synchronizing queueing and the execution of the work item. > > Looking at that part of code only, it's possible that it fails to > > queue the work item after a memory hotplug event even though the > > previous queueing already started execution and processed a couple > > notifiers. > > Maybe failure to queue could be signalled with a proper return value > from __queue_work()? It already does that but it's not about the return value. You simply cannot know whether to proceed with queueing or not with test_bit() alone. > Btw, I'm afraid I don't understand the "memory hotplug event" aspect and > how that can influence the queueing - all it does it is list_add_tail, > basically. It doesn't have anything to do with memory hotplug event itself. It's a generic memory access ordering / synchronization issue. There just isn't anything preventing test_bit() from seeing PENDING bit from before clearing. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Regression in kernel 3.8-rc1 bisected to commit adfa79d: I now get many "unable to enumerate USB device" messages
The problem has been bisected to commit adfa79d entitled "USB: EHCI: make ehci-pci a separate driver". The symptom is that my NVIDIA controller again reverts to unended logging of messages of the form "hub 2-0:1.0: unable to enumerate USB device on port 5". This behavior was previously fixed with commit c618759. Thanks, Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 25/25] ipc: don't use [delayed_]work_pending()
Hello, Borislav. On Mon, Dec 24, 2012 at 08:32:58PM +0100, Borislav Petkov wrote: > Ok, understood. I have only one question: how do you make sure > schedule_work() is used only in cold paths? Hot and cold are relative terms and unless someone is doing things like invoking queue_work() from high-frequency interrupt handler, the level of overhead from queue_work() isn't likely to matter. The best way to deal with such hot paths would differ depending on the specifics of each hot path - ie. bouncing to workqueue from IRQ handler would be better handled by threaded IRQ handlers. At this point, especially given how all of work_pending() users are way too cold for any of this to matter, I don't think we need to worry about this. > Btw, there's __cancel_delayed_work() which is not used anywhere and it > could be deleted AFAICT. Yeah, there are several interfaces which are being deprecated. They'll be gone in a few cycles. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USB 2.0 (EHCI) keeps crapping out (3.2.29)
*** NOTE: Kindly CC me directly if you reply to list since I'm not an LKML subscriber. *** Running vanilla 3.2.29 (Slackware 14.0). I also had this issue on 2.6.37.6 and *possibly* 2.6.33.x, but I don't recall. Every now and again (could be every few days, could take a couple of weeks... depends.) USB 2.0 stops working. My scanner as well as certain mass-storage devices that are USB-2.0 compatible fail to function all of a sudden. With the said mass storage devices, I get lots of errors like this in my logs: hub 1-0:1.0: unable to enumerate USB device on port 3 Devices that have previously been mounted and accessed successfully begin giving input/output errors when I try to ls them. rmmod'ing ehci_hcd and modprobe'ing it again resolves the issue until it occurs again. It *could* be a hardware problem, but it seems odd that unloading & reloading the module instantly makes it work perfectly again. Via USB 1.1/2.0 controller from circa 2002-2003. If anyone has any ideas, please let me know... logan@logancomp:~$ /sbin/lspci |grep -i usb 00:10.0 USB controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.1 USB controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.2 USB controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.3 USB controller: VIA Technologies, Inc. USB 2.0 (rev 82) logan@logancomp:~$ cat /proc/cmdline auto BOOT_IMAGE=Slackware ro root=802 nohz=off highres=off clocksource=jiffies acpi_enforce_resources=lax vt.default_utf8=0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: pcf50633: Init pcf->dev before using it
Current code uses pcf->dev in the dev_err call before setting it to
>dev. Fix it.
Signed-off-by: Axel Lin
---
drivers/mfd/pcf50633-core.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/pcf50633-core.c b/drivers/mfd/pcf50633-core.c
index 64803f1..d115673 100644
--- a/drivers/mfd/pcf50633-core.c
+++ b/drivers/mfd/pcf50633-core.c
@@ -208,6 +208,8 @@ static int pcf50633_probe(struct i2c_client *client,
if (!pcf)
return -ENOMEM;
+ i2c_set_clientdata(client, pcf);
+ pcf->dev = >dev;
pcf->pdata = pdata;
mutex_init(>lock);
@@ -219,9 +221,6 @@ static int pcf50633_probe(struct i2c_client *client,
return ret;
}
- i2c_set_clientdata(client, pcf);
- pcf->dev = >dev;
-
version = pcf50633_reg_read(pcf, 0);
variant = pcf50633_reg_read(pcf, 1);
if (version < 0 || variant < 0) {
--
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 v2 4/8] MFD:rtsx: Add callback function switch_output_voltage
From: Wei WANG
Different card reader has different method to switch output voltage,
add this callback to let the card reader implement its individual switch
function.
Signed-off-by: Wei WANG
---
drivers/mfd/rtl8411.c| 16
drivers/mfd/rts5209.c| 20
drivers/mfd/rts5229.c| 20
drivers/mfd/rtsx_pcr.c |9 +
include/linux/mfd/rtsx_pci.h | 24
5 files changed, 85 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 89f046c..5058ba8 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -112,6 +112,21 @@ static int rtl8411_card_power_off(struct rtsx_pcr *pcr,
int card)
BPP_LDO_POWB, BPP_LDO_SUSPEND);
}
+static int rtl8411_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+ u8 mask, val;
+
+ mask = (BPP_REG_TUNED18 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_MASK;
+ if (voltage == OUTPUT_3V3)
+ val = (BPP_ASIC_3V3 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_3V3;
+ else if (voltage == OUTPUT_1V8)
+ val = (BPP_ASIC_1V8 << BPP_TUNED18_SHIFT_8411) | BPP_PAD_1V8;
+ else
+ return -EINVAL;
+
+ return rtsx_pci_write_register(pcr, LDO_CTL, mask, val);
+}
+
static unsigned int rtl8411_cd_deglitch(struct rtsx_pcr *pcr)
{
unsigned int card_exist;
@@ -172,6 +187,7 @@ static const struct pcr_ops rtl8411_pcr_ops = {
.disable_auto_blink = rtl8411_disable_auto_blink,
.card_power_on = rtl8411_card_power_on,
.card_power_off = rtl8411_card_power_off,
+ .switch_output_voltage = rtl8411_switch_output_voltage,
.cd_deglitch = rtl8411_cd_deglitch,
};
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index 283a4f1..ba74de8 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -144,6 +144,25 @@ static int rts5209_card_power_off(struct rtsx_pcr *pcr,
int card)
return rtsx_pci_send_cmd(pcr, 100);
}
+static int rts5209_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+ int err;
+
+ if (voltage == OUTPUT_3V3) {
+ err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FC0 | 0x24);
+ if (err < 0)
+ return err;
+ } else if (voltage == OUTPUT_1V8) {
+ err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4C40 | 0x24);
+ if (err < 0)
+ return err;
+ } else {
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct pcr_ops rts5209_pcr_ops = {
.extra_init_hw = rts5209_extra_init_hw,
.optimize_phy = rts5209_optimize_phy,
@@ -153,6 +172,7 @@ static const struct pcr_ops rts5209_pcr_ops = {
.disable_auto_blink = rts5209_disable_auto_blink,
.card_power_on = rts5209_card_power_on,
.card_power_off = rts5209_card_power_off,
+ .switch_output_voltage = rts5209_switch_output_voltage,
.cd_deglitch = NULL,
};
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index b9dbab2..ec1747a 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -114,6 +114,25 @@ static int rts5229_card_power_off(struct rtsx_pcr *pcr,
int card)
return rtsx_pci_send_cmd(pcr, 100);
}
+static int rts5229_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+ int err;
+
+ if (voltage == OUTPUT_3V3) {
+ err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FC0 | 0x24);
+ if (err < 0)
+ return err;
+ } else if (voltage == OUTPUT_1V8) {
+ err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4C40 | 0x24);
+ if (err < 0)
+ return err;
+ } else {
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct pcr_ops rts5229_pcr_ops = {
.extra_init_hw = rts5229_extra_init_hw,
.optimize_phy = rts5229_optimize_phy,
@@ -123,6 +142,7 @@ static const struct pcr_ops rts5229_pcr_ops = {
.disable_auto_blink = rts5229_disable_auto_blink,
.card_power_on = rts5229_card_power_on,
.card_power_off = rts5229_card_power_off,
+ .switch_output_voltage = rts5229_switch_output_voltage,
.cd_deglitch = NULL,
};
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 1dc64bb..99e12b8 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -702,6 +702,15 @@ int rtsx_pci_card_power_off(struct rtsx_pcr *pcr, int card)
}
EXPORT_SYMBOL_GPL(rtsx_pci_card_power_off);
+int rtsx_pci_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+ if (pcr->ops->switch_output_voltage)
+ return pcr->ops->switch_output_voltage(pcr, voltage);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(rtsx_pci_switch_output_voltage);
+
unsigned int rtsx_pci_card_exist(struct rtsx_pcr *pcr)
{
unsigned
[PATCH v2 2/8] MFD:rtsx: Remove redundant code
From: Wei WANG In function rtsx_pci_add_sg_tbl, the statement "ptr++" is useless. Signed-off-by: Wei WANG --- drivers/mfd/rtsx_pcr.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c index 3a44efa..fa2c2bc 100644 --- a/drivers/mfd/rtsx_pcr.c +++ b/drivers/mfd/rtsx_pcr.c @@ -325,7 +325,6 @@ static void rtsx_pci_add_sg_tbl(struct rtsx_pcr *pcr, val = ((u64)addr << 32) | ((u64)len << 12) | option; put_unaligned_le64(val, ptr); - ptr++; pcr->sgi++; } -- 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 v2 1/8] MFD:rtsx: Fix typo in comment
From: Wei WANG Fix a misspelling word in comment Signed-off-by: Wei WANG --- include/linux/mfd/rtsx_pci.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index 060b721..bebe9f9 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -452,7 +452,7 @@ #defineSD_RSP_TYPE_R6 0x01 #defineSD_RSP_TYPE_R7 0x01 -/* SD_CONFIURE3 */ +/* SD_CONFIGURE3 */ #defineSD_RSP_80CLK_TIMEOUT_EN 0x01 /* Card Transfer Reset Register */ -- 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 v2 7/8] MFD:rtsx: Fix checkpatch warning
From: Wei WANG
WARNING: Avoid CamelCase:
+ u8 N, min_N, max_N, clk_divider;
WARNING: Avoid CamelCase:
+ u8 N, min_N, max_N, clk_divider;
Signed-off-by: Wei WANG
---
drivers/mfd/rtsx_pcr.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 958b738..7632e7f 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -590,7 +590,7 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
u8 ssc_depth, bool initial_mode, bool double_clk, bool vpclk)
{
int err, clk;
- u8 N, min_N, max_N, clk_divider;
+ u8 n, min_n, max_n, clk_divider;
u8 mcu_cnt, div, max_div;
u8 depth[] = {
[RTSX_SSC_DEPTH_4M] = SSC_DEPTH_4M,
@@ -615,8 +615,8 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
card_clock /= 100;
dev_dbg(&(pcr->pci->dev), "Switch card clock to %dMHz\n", card_clock);
- min_N = 80;
- max_N = 208;
+ min_n = 80;
+ max_n = 208;
max_div = CLK_DIV_8;
clk = card_clock;
@@ -630,30 +630,30 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
return 0;
if (pcr->ops->conv_clk_and_div_n)
- N = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
+ n = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
else
- N = (u8)(clk - 2);
- if ((clk <= 2) || (N > max_N))
+ n = (u8)(clk - 2);
+ if ((clk <= 2) || (n > max_n))
return -EINVAL;
mcu_cnt = (u8)(125/clk + 3);
if (mcu_cnt > 15)
mcu_cnt = 15;
- /* Make sure that the SSC clock div_n is equal or greater than min_N */
+ /* Make sure that the SSC clock div_n is equal or greater than min_n */
div = CLK_DIV_1;
- while ((N < min_N) && (div < max_div)) {
+ while ((n < min_n) && (div < max_div)) {
if (pcr->ops->conv_clk_and_div_n) {
- int dbl_clk = pcr->ops->conv_clk_and_div_n(N,
+ int dbl_clk = pcr->ops->conv_clk_and_div_n(n,
DIV_N_TO_CLK) * 2;
- N = (u8)pcr->ops->conv_clk_and_div_n(dbl_clk,
+ n = (u8)pcr->ops->conv_clk_and_div_n(dbl_clk,
CLK_TO_DIV_N);
} else {
- N = (N + 2) * 2 - 2;
+ n = (n + 2) * 2 - 2;
}
div++;
}
- dev_dbg(&(pcr->pci->dev), "N = %d, div = %d\n", N, div);
+ dev_dbg(&(pcr->pci->dev), "N = %d, div = %d\n", n, div);
ssc_depth = depth[ssc_depth];
if (double_clk)
@@ -670,7 +670,7 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_CTL1, SSC_RSTB, 0);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_CTL2,
SSC_DEPTH_MASK, ssc_depth);
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_DIV_N_0, 0xFF, N);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_DIV_N_0, 0xFF, n);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SSC_CTL1, SSC_RSTB, SSC_RSTB);
if (vpclk) {
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_VPCLK0_CTL,
--
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 v2 8/8] MFD:rtsx: Use macro defines to replace some variables
From: Wei WANG
In function rtsx_pci_switch_clock, some variables, such as min_n, max_n,
and max_div, are not necessary. And those assigned values look very
obscure for others. It's more proper to use macro definitions here to
replace these variables.
Signed-off-by: Wei WANG
---
drivers/mfd/rtsx_pcr.c | 13 -
drivers/mfd/rtsx_pcr.h |3 +++
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 7632e7f..431a74c 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -590,8 +590,7 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
u8 ssc_depth, bool initial_mode, bool double_clk, bool vpclk)
{
int err, clk;
- u8 n, min_n, max_n, clk_divider;
- u8 mcu_cnt, div, max_div;
+ u8 n, clk_divider, mcu_cnt, div;
u8 depth[] = {
[RTSX_SSC_DEPTH_4M] = SSC_DEPTH_4M,
[RTSX_SSC_DEPTH_2M] = SSC_DEPTH_2M,
@@ -615,10 +614,6 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
card_clock /= 100;
dev_dbg(&(pcr->pci->dev), "Switch card clock to %dMHz\n", card_clock);
- min_n = 80;
- max_n = 208;
- max_div = CLK_DIV_8;
-
clk = card_clock;
if (!initial_mode && double_clk)
clk = card_clock * 2;
@@ -633,16 +628,16 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
n = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
else
n = (u8)(clk - 2);
- if ((clk <= 2) || (n > max_n))
+ if ((clk <= 2) || (n > MAX_DIV_N_PCR))
return -EINVAL;
mcu_cnt = (u8)(125/clk + 3);
if (mcu_cnt > 15)
mcu_cnt = 15;
- /* Make sure that the SSC clock div_n is equal or greater than min_n */
+ /* Make sure that the SSC clock div_n is not less than MIN_DIV_N_PCR */
div = CLK_DIV_1;
- while ((n < min_n) && (div < max_div)) {
+ while ((n < MIN_DIV_N_PCR) && (div < CLK_DIV_8)) {
if (pcr->ops->conv_clk_and_div_n) {
int dbl_clk = pcr->ops->conv_clk_and_div_n(n,
DIV_N_TO_CLK) * 2;
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 12462c1..33c210b 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -25,6 +25,9 @@
#include
+#define MIN_DIV_N_PCR 80
+#define MAX_DIV_N_PCR 208
+
void rts5209_init_params(struct rtsx_pcr *pcr);
void rts5229_init_params(struct rtsx_pcr *pcr);
void rtl8411_init_params(struct rtsx_pcr *pcr);
--
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 v2 5/8] MMC:rtsx: Using callback function to switch output voltage
From: Wei WANG
Different card reader has different method to switch output voltage, so
we have to use the callback function provided by MFD driver to switch
output pad voltage.
Signed-off-by: Wei WANG
---
drivers/mmc/host/rtsx_pci_sdmmc.c | 30 +-
1 file changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 571915d..f74b5ad 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -1060,26 +1060,6 @@ static int sd_wait_voltage_stable_2(struct
realtek_pci_sdmmc *host)
return 0;
}
-static int sd_change_bank_voltage(struct realtek_pci_sdmmc *host, u8 voltage)
-{
- struct rtsx_pcr *pcr = host->pcr;
- int err;
-
- if (voltage == SD_IO_3V3) {
- err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FC0 | 0x24);
- if (err < 0)
- return err;
- } else if (voltage == SD_IO_1V8) {
- err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4C40 | 0x24);
- if (err < 0)
- return err;
- } else {
- return -EINVAL;
- }
-
- return 0;
-}
-
static int sdmmc_switch_voltage(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct realtek_pci_sdmmc *host = mmc_priv(mmc);
@@ -1098,11 +1078,11 @@ static int sdmmc_switch_voltage(struct mmc_host *mmc,
struct mmc_ios *ios)
rtsx_pci_start_run(pcr);
if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330)
- voltage = SD_IO_3V3;
+ voltage = OUTPUT_3V3;
else
- voltage = SD_IO_1V8;
+ voltage = OUTPUT_1V8;
- if (voltage == SD_IO_1V8) {
+ if (voltage == OUTPUT_1V8) {
err = rtsx_pci_write_register(pcr,
SD30_DRIVE_SEL, 0x07, DRIVER_TYPE_B);
if (err < 0)
@@ -1113,11 +1093,11 @@ static int sdmmc_switch_voltage(struct mmc_host *mmc,
struct mmc_ios *ios)
goto out;
}
- err = sd_change_bank_voltage(host, voltage);
+ err = rtsx_pci_switch_output_voltage(pcr, voltage);
if (err < 0)
goto out;
- if (voltage == SD_IO_1V8) {
+ if (voltage == OUTPUT_1V8) {
err = sd_wait_voltage_stable_2(host);
if (err < 0)
goto out;
--
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 v2 6/8] MFD:rtsx: Add callback function conv_clk_and_div_n
From: Wei WANG
Add callback function conv_clk_and_div_n to convert between SSC clock
and its divider N.
For rtl8411, the formula to calculate SSC clock divider N is different
with the other card reader models.
Signed-off-by: Wei WANG
---
drivers/mfd/rtl8411.c | 13 +
drivers/mfd/rts5209.c |1 +
drivers/mfd/rts5229.c |1 +
drivers/mfd/rtsx_pcr.c | 14 --
include/linux/mfd/rtsx_common.h |3 +++
include/linux/mfd/rtsx_pci.h|1 +
6 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 5058ba8..3d3b4ad 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -178,6 +178,18 @@ static unsigned int rtl8411_cd_deglitch(struct rtsx_pcr
*pcr)
return card_exist;
}
+static int rtl8411_conv_clk_and_div_n(int input, int dir)
+{
+ int output;
+
+ if (dir == CLK_TO_DIV_N)
+ output = input * 4 / 5 - 2;
+ else
+ output = (input + 2) * 5 / 4;
+
+ return output;
+}
+
static const struct pcr_ops rtl8411_pcr_ops = {
.extra_init_hw = rtl8411_extra_init_hw,
.optimize_phy = NULL,
@@ -189,6 +201,7 @@ static const struct pcr_ops rtl8411_pcr_ops = {
.card_power_off = rtl8411_card_power_off,
.switch_output_voltage = rtl8411_switch_output_voltage,
.cd_deglitch = rtl8411_cd_deglitch,
+ .conv_clk_and_div_n = rtl8411_conv_clk_and_div_n,
};
/* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index ba74de8..98fe0f3 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -174,6 +174,7 @@ static const struct pcr_ops rts5209_pcr_ops = {
.card_power_off = rts5209_card_power_off,
.switch_output_voltage = rts5209_switch_output_voltage,
.cd_deglitch = NULL,
+ .conv_clk_and_div_n = NULL,
};
/* SD Pull Control Enable:
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index ec1747a..29d889c 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -144,6 +144,7 @@ static const struct pcr_ops rts5229_pcr_ops = {
.card_power_off = rts5229_card_power_off,
.switch_output_voltage = rts5229_switch_output_voltage,
.cd_deglitch = NULL,
+ .conv_clk_and_div_n = NULL,
};
/* SD Pull Control Enable:
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 99e12b8..958b738 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -629,7 +629,10 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
if (clk == pcr->cur_clock)
return 0;
- N = (u8)(clk - 2);
+ if (pcr->ops->conv_clk_and_div_n)
+ N = (u8)pcr->ops->conv_clk_and_div_n(clk, CLK_TO_DIV_N);
+ else
+ N = (u8)(clk - 2);
if ((clk <= 2) || (N > max_N))
return -EINVAL;
@@ -640,7 +643,14 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
int card_clock,
/* Make sure that the SSC clock div_n is equal or greater than min_N */
div = CLK_DIV_1;
while ((N < min_N) && (div < max_div)) {
- N = (N + 2) * 2 - 2;
+ if (pcr->ops->conv_clk_and_div_n) {
+ int dbl_clk = pcr->ops->conv_clk_and_div_n(N,
+ DIV_N_TO_CLK) * 2;
+ N = (u8)pcr->ops->conv_clk_and_div_n(dbl_clk,
+ CLK_TO_DIV_N);
+ } else {
+ N = (N + 2) * 2 - 2;
+ }
div++;
}
dev_dbg(&(pcr->pci->dev), "N = %d, div = %d\n", N, div);
diff --git a/include/linux/mfd/rtsx_common.h b/include/linux/mfd/rtsx_common.h
index a8d393e..2b13970 100644
--- a/include/linux/mfd/rtsx_common.h
+++ b/include/linux/mfd/rtsx_common.h
@@ -38,6 +38,9 @@
#define RTSX_SD_CARD 0
#define RTSX_MS_CARD 1
+#define CLK_TO_DIV_N 0
+#define DIV_N_TO_CLK 1
+
struct platform_device;
struct rtsx_slot {
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 2e3e2e0..3f2bf26 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -704,6 +704,7 @@ struct pcr_ops {
int (*switch_output_voltage)(struct rtsx_pcr *pcr,
u8 voltage);
unsigned int(*cd_deglitch)(struct rtsx_pcr *pcr);
+ int (*conv_clk_and_div_n)(int clk, int dir);
};
enum PDEV_STAT {PDEV_STAT_IDLE, PDEV_STAT_RUN};
--
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 v2 3/8] MFD:rtsx: Declare that the DMA address limitation is 32bit explicitly
From: Wei WANG Signed-off-by: Wei WANG --- drivers/mfd/rtsx_pcr.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c index fa2c2bc..1dc64bb 100644 --- a/drivers/mfd/rtsx_pcr.c +++ b/drivers/mfd/rtsx_pcr.c @@ -1010,6 +1010,10 @@ static int __devinit rtsx_pci_probe(struct pci_dev *pcidev, pci_name(pcidev), (int)pcidev->vendor, (int)pcidev->device, (int)pcidev->revision); + ret = pci_set_dma_mask(pcidev, DMA_BIT_MASK(32)); + if (ret < 0) + return ret; + ret = pci_enable_device(pcidev); if (ret) return ret; -- 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 v2 0/8] rtsx patchset for MFD and MMC tree
From: Wei WANG Wei WANG (8): MFD:rtsx: Fix typo in comment MFD:rtsx: Remove redundant code MFD:rtsx: Declare that the DMA address limitation is 32bit explicitly MFD:rtsx: Add callback function switch_output_voltage MMC:rtsx: Using callback function to switch output voltage MFD:rtsx: Add callback function conv_clk_and_div_n MFD:rtsx: Fix checkpatch warning MFD:rtsx: Use macro defines to replace some variables drivers/mfd/rtl8411.c | 29 drivers/mfd/rts5209.c | 21 + drivers/mfd/rts5229.c | 21 + drivers/mfd/rtsx_pcr.c| 45 + drivers/mfd/rtsx_pcr.h|3 +++ drivers/mmc/host/rtsx_pci_sdmmc.c | 30 + include/linux/mfd/rtsx_common.h |3 +++ include/linux/mfd/rtsx_pci.h | 27 +- 8 files changed, 135 insertions(+), 44 deletions(-) -- 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 v2] fadvise: perform WILLNEED readahead asynchronously
Using fadvise with POSIX_FADV_WILLNEED can be very slow and cause
user-visible latency. This hurts interactivity and encourages
userspace to resort to background threads for readahead (or avoid
POSIX_FADV_WILLNEED entirely).
"strace -T" timing on an uncached, one gigabyte file:
Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832>
After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.61>
For a smaller 9.8M request, there is still a significant improvement:
Before: fadvise64(3, 0, 10223108, POSIX_FADV_WILLNEED) = 0 <0.005399>
After: fadvise64(3, 0, 10223108, POSIX_FADV_WILLNEED) = 0 <0.59>
Even with a small 1M request, there is an improvement:
Before: fadvise64(3, 0, 1048576, POSIX_FADV_WILLNEED) = 0 <0.000474>
After: fadvise64(3, 0, 1048576, POSIX_FADV_WILLNEED) = 0 <0.63>
While userspace can mimic the effect of this commit by using a
background thread to perform readahead(), this allows for simpler
userspace code.
To mitigate denial-of-service attacks, inflight (but incomplete)
readahead requests are accounted for when new readahead requests arrive.
New readahead requests may be reduced or ignored if there are too many
inflight readahead pages in the workqueue.
IO priority is also taken into account for workqueue readahead.
Normal and idle priority tasks share a concurrency-limited workqueue to
prevent excessive readahead requests from taking place simultaneously.
This normal workqueue is concurrency-limited to one task per-CPU
(like AIO).
Real-time I/O tasks get their own high-priority workqueue independent
of the normal workqueue.
The impact of idle tasks is also reduced and they are more likely to
have advisory readahead requests ignored/dropped when read congestion
occurs.
Cc: Alan Cox
Cc: Dave Chinner
Cc: Zheng Liu
Signed-off-by: Eric Wong
---
I have not tested on NUMA (since I've no access to NUMA hardware)
and do not know how the use of the workqueue affects RA performance.
I'm only using WQ_UNBOUND on non-NUMA, though.
I'm halfway tempted to make DONTNEED use a workqueue, too.
Having perceptible latency on advisory syscalls is unpleasant and
keeping the latency makes little sense if we can hide it.
include/linux/mm.h | 3 +
mm/fadvise.c | 10 +--
mm/readahead.c | 217 +
3 files changed, 224 insertions(+), 6 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 6320407..90b361c 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1536,6 +1536,9 @@ void task_dirty_inc(struct task_struct *tsk);
#define VM_MAX_READAHEAD 128 /* kbytes */
#define VM_MIN_READAHEAD 16 /* kbytes (includes current page) */
+void wq_page_cache_readahead(struct address_space *mapping, struct file *filp,
+ pgoff_t offset, unsigned long nr_to_read);
+
int force_page_cache_readahead(struct address_space *mapping, struct file
*filp,
pgoff_t offset, unsigned long nr_to_read);
diff --git a/mm/fadvise.c b/mm/fadvise.c
index a47f0f5..cf3bd4c 100644
--- a/mm/fadvise.c
+++ b/mm/fadvise.c
@@ -102,12 +102,10 @@ SYSCALL_DEFINE(fadvise64_64)(int fd, loff_t offset,
loff_t len, int advice)
if (!nrpages)
nrpages = ~0UL;
- /*
-* Ignore return value because fadvise() shall return
-* success even if filesystem can't retrieve a hint,
-*/
- force_page_cache_readahead(mapping, f.file, start_index,
- nrpages);
+ get_file(f.file); /* fput() is called by workqueue */
+
+ /* queue up the request, don't care if it fails */
+ wq_page_cache_readahead(mapping, f.file, start_index, nrpages);
break;
case POSIX_FADV_NOREUSE:
break;
diff --git a/mm/readahead.c b/mm/readahead.c
index 7963f23..f9e0705 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -19,6 +19,45 @@
#include
#include
#include
+#include
+#include
+
+static struct workqueue_struct *ra_be __read_mostly;
+static struct workqueue_struct *ra_rt __read_mostly;
+static unsigned long ra_nr_queued;
+static DEFINE_SPINLOCK(ra_nr_queued_lock);
+
+struct wq_ra_req {
+ struct work_struct work;
+ struct address_space *mapping;
+ struct file *file;
+ pgoff_t offset;
+ unsigned long nr_to_read;
+ int ioprio;
+};
+
+static void wq_ra_enqueue(struct wq_ra_req *);
+
+/* keep NUMA readahead on the same CPU for now... */
+#ifdef CONFIG_NUMA
+# define RA_WQ_FLAGS 0
+#else
+# define RA_WQ_FLAGS WQ_UNBOUND
+#endif
+
+static int __init init_readahead(void)
+{
+ /* let tasks with real-time priorities run freely */
+ ra_rt = alloc_workqueue("readahead_rt", RA_WQ_FLAGS|WQ_HIGHPRI, 0);
+
+ /* limit async concurrency of normal and idle readahead */
+ ra_be = alloc_workqueue("readahead_be",
[PATCH] regulator: lp8755: Fix lp8755_regulator_init unwind code
It's safe to pass NULL argument to regulator_unregister(), so we can remove
the NULL checking before calling regulator_unregister().
However pass a ERR_PTR to regulator_unregister() is wrong, so we need to
explicitly set "pchip->rdev[buck_num] = NULL" before goto err_buck.
This patch also includes below cleanups:
Show correct regulator id in dev_err.
Remove __devexit_p.
Signed-off-by: Axel Lin
---
drivers/regulator/lp8755.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/lp8755.c b/drivers/regulator/lp8755.c
index dbc4d12..06a82e2 100644
--- a/drivers/regulator/lp8755.c
+++ b/drivers/regulator/lp8755.c
@@ -358,7 +358,9 @@ static int lp8755_regulator_init(struct lp8755_chip *pchip)
regulator_register(_regulators[buck_num], );
if (IS_ERR(pchip->rdev[buck_num])) {
ret = PTR_ERR(pchip->rdev[buck_num]);
- dev_err(pchip->dev, "regulator init failed: buck 0\n");
+ pchip->rdev[buck_num] = NULL;
+ dev_err(pchip->dev, "regulator init failed: buck %d\n",
+ buck_num);
goto err_buck;
}
}
@@ -367,8 +369,7 @@ static int lp8755_regulator_init(struct lp8755_chip *pchip)
err_buck:
for (icnt = 0; icnt < LP8755_BUCK_MAX; icnt++)
- if (pchip->rdev[icnt] != NULL)
- regulator_unregister(pchip->rdev[icnt]);
+ regulator_unregister(pchip->rdev[icnt]);
return ret;
}
@@ -557,7 +558,7 @@ static struct i2c_driver lp8755_i2c_driver = {
.name = LP8755_NAME,
},
.probe = lp8755_probe,
- .remove = __devexit_p(lp8755_remove),
+ .remove = lp8755_remove,
.id_table = lp8755_id,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] output the cpu number when printking.
On Mon, 2012-12-24 at 09:55 -0800, Greg KH wrote: > On Mon, Dec 24, 2012 at 01:01:55PM +0800, he, bo wrote: > > From: "he, bo" > > > > We often hit kernel panic issues on SMP machines because processes race > > on multiple cpu. By adding a new parameter printk.cpu, kernel prints > > cpu number at printk information line. It’s useful to debug what cpus > > are racing. > > How useful is this really for normal developers? It's very useful to debug race conditions under SMP environment. We applied the patch to our Android build image on our smartphones. > We complained when > this option was proposed by the ARM developers who were, for the first > time, handling more than one processor and the issues involved with > that. You are enabling this as a default option, for all developers, > and almost no one will ever need it. At least, I am a developer to use it every day. :). I need debug various weird issues and tried many debug tools. Anyway, we would change the default to _disable_. > > So, if you really want this, don't enable this by default. Also, go > back and read the old thread about this option and why it was rejeted > previously. Thanks for your kind reminder. I googled it. Is the link like https://lkml.org/lkml/2012/8/3/121? Or http://lkml.indiana.edu/hypermail/linux/kernel/1208.0/02097.html? Above links raise a good question that we might be able to use ftrace (trace_printk) instead of to extend printk. 1) There are indeed lots of debug methods/tools in kernel because of many excellent developers' contributions. However, the most frequently-used tool is still printk. 2) ftrace (I use it often) is good when system mostly doesn't crash. If system crashes, we couldn't get ftrace info sometimes. When we debug some hard issues on a multi-core device, the system often crashes when Graphics driver accesses registers incorrectly. There is no chance for kernel to dump ftrace or panic info. With printk, we find that's because 2 cpu are racing. One cpu turns off Graphics while another cpu is accessing it. Of course, we also applied the Android persistent ram patch, so after rebooting, we still could see the printk buffer of previous booting. 3) Current drivers usually have many dev_dbg statements. We could enable dynamic debug control to get such info quickly. With the printk cpu number patch, we quickly enhance them to dump info about potential races among cpu. With ftrace, we need change all these dev_dbg to trace_printk and that's not the original objective of driver developers. Mostly, the patch is to reuse all current printk statements in kernel with a little overhead. Thanks for your kind comments. Yanmin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 00/27] x86, boot, 64bit: Add support for loading ramdisk and bzImage above 4G
On 12/22/2012 05:24 AM, Konrad Rzeszutek Wilk wrote: Interestingly enough I only see this on any AMD machine - different motherboards, different memory configurations. And also in a HVM guest running on an AMD machine. If it runs on Intel it works just fine. Could this be the ljmpq problem that Borislav reported (Intel implemented ljmpq, AMD didn't, and I was tempted by a micro-optimization which broke AMD which made it into the patchset)? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Bluetooth: fix the oops due to conn->hcon == NULL in shutdown case
Meet one panic issue as below stack:
<1>[11340.226404] BUG: unable to handle kernel NULL pointer dereference at
0008
<4>[11340.226619] EIP is at __sco_sock_close+0xe8/0x1a0
<4>[11340.226629] EAX: f063a740 EBX: ECX: f58f4544 EDX:
<4>[11340.226640] ESI: dec83e00 EDI: 5f9a081f EBP: e0fdff38 ESP: e0fdff1c
<0>[11340.226674] Stack:
<4>[11340.226682] c184db87 c1251028 dec83e00 e0fdff38 c1754aef dec83e00
e0fdff5c
<4>[11340.226718] c184f587 e0fdff64 e0fdff68 5f9a081f e0fdff5c c1751852
d7813800 62262f10
<4>[11340.226752] e0fdff70 c1753c00 0001 000d e0fdffac
c175425c 0041
<0>[11340.226793] Call Trace:
<4>[11340.226813] [] ? sco_sock_clear_timer+0x27/0x60
<4>[11340.226831] [] ? local_bh_enable+0x68/0xd0
<4>[11340.226846] [] ? lock_sock_nested+0x4f/0x60
<4>[11340.226862] [] sco_sock_shutdown+0x67/0xb0
<4>[11340.226879] [] ? sockfd_lookup_light+0x22/0x80
<4>[11340.226897] [] sys_shutdown+0x30/0x60
<4>[11340.226912] [] sys_socketcall+0x1dc/0x2a0
<4>[11340.226929] [] ? trace_hardirqs_on_thunk+0xc/0x10
<4>[11340.226944] [] syscall_call+0x7/0xb
<4>[11340.226960] [] ? restore_cur+0x5e/0xd7
<0>[11340.226969] Code: ff 4b 08 0f 94 c0 84 c0 74 20 80 7b 19 01 74 2f b8
0a 00 00
Disassemble the code:
base address of __sco_sock_close is 0xc184f410
0xc184f4f8 <+232>: lock decl 0x8(%ebx) < == crash here, ebx is 0x0,
the related source code is:
(gdb) l *0xc184f4f8
0xc184f4f8 is in __sco_sock_close (arch/x86/include/asm/atomic.h:123)
119 static inline int atomic_dec_and_test(atomic_t *v)
123 asm volatile(LOCK_PREFIX "decl %0; sete %1"
The whole call stack is:
sys_shutdown()
sco_sock_shutdown()
__sco_sock_close()
hci_conn_put()
atomic_dec_and_test()
Due to the conn->hcon is NULL, and the member hcon->refcnt is at offset 0x8,
so "BUG: unable to handle kernel NULL pointer dereference at 0008"
appears.
Here fix it that adding the condition if conn->hcon is NULL, just like
in sco_chan_del().
Signed-off-by: liu chuansheng
---
net/bluetooth/sco.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 531a93d..190f70c 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -355,8 +355,10 @@ static void __sco_sock_close(struct sock *sk)
if (sco_pi(sk)->conn) {
sk->sk_state = BT_DISCONN;
sco_sock_set_timer(sk, SCO_DISCONN_TIMEOUT);
- hci_conn_put(sco_pi(sk)->conn->hcon);
- sco_pi(sk)->conn->hcon = NULL;
+ if (sco_pi(sk)->conn->hcon) {
+ hci_conn_put(sco_pi(sk)->conn->hcon);
+ sco_pi(sk)->conn->hcon = NULL;
+ }
} else
sco_chan_del(sk, ECONNRESET);
break;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] regulator: core: Allow specify apply_[reg|bit] for regmap based voltage_sel operations
On Tue, Dec 25, 2012 at 12:34 AM, Mark Brown wrote: > On Tue, Dec 18, 2012 at 09:30:10AM +0800, Axel Lin wrote: >> Some DVM regulators needs to update apply_bit after setting vsel_reg to >> initiate voltage change on the output. This patch adds apply_reg and > > Applied all except patch 2 (where you've done a new version, I'll wait > for Haojian to ack though) - thanks! I acked 2nd patch just now. Best Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] regulator: 88pm8607: Use apply_[reg|bit] with regmap based voltage_sel operations
On Mon, Dec 24, 2012 at 9:14 AM, Axel Lin wrote:
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/88pm8607.c | 38 ++
> 1 file changed, 6 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/regulator/88pm8607.c b/drivers/regulator/88pm8607.c
> index 5c4879a..a957e8c 100644
> --- a/drivers/regulator/88pm8607.c
> +++ b/drivers/regulator/88pm8607.c
> @@ -30,8 +30,6 @@ struct pm8607_regulator_info {
> unsigned int*vol_table;
> unsigned int*vol_suspend;
>
> - int update_reg;
> - int update_bit;
> int slope_double;
> };
>
> @@ -222,30 +220,6 @@ static int pm8607_list_voltage(struct regulator_dev
> *rdev, unsigned index)
> return ret;
> }
>
> -static int pm8607_set_voltage_sel(struct regulator_dev *rdev, unsigned
> selector)
> -{
> - struct pm8607_regulator_info *info = rdev_get_drvdata(rdev);
> - uint8_t val;
> - int ret;
> -
> - val = (uint8_t)(selector << (ffs(rdev->desc->vsel_mask) - 1));
> -
> - ret = pm860x_set_bits(info->i2c, rdev->desc->vsel_reg,
> - rdev->desc->vsel_mask, val);
> - if (ret)
> - return ret;
> - switch (info->desc.id) {
> - case PM8607_ID_BUCK1:
> - case PM8607_ID_BUCK2:
> - case PM8607_ID_BUCK3:
> - ret = pm860x_set_bits(info->i2c, info->update_reg,
> - 1 << info->update_bit,
> - 1 << info->update_bit);
> - break;
> - }
> - return ret;
> -}
> -
> static int pm8606_preg_enable(struct regulator_dev *rdev)
> {
> struct pm8607_regulator_info *info = rdev_get_drvdata(rdev);
> @@ -277,7 +251,7 @@ static int pm8606_preg_is_enabled(struct regulator_dev
> *rdev)
>
> static struct regulator_ops pm8607_regulator_ops = {
> .list_voltage = pm8607_list_voltage,
> - .set_voltage_sel = pm8607_set_voltage_sel,
> + .set_voltage_sel = regulator_set_voltage_sel_regmap,
> .get_voltage_sel = regulator_get_voltage_sel_regmap,
> .enable = regulator_enable_regmap,
> .disable = regulator_disable_regmap,
> @@ -314,11 +288,11 @@ static struct regulator_ops pm8606_preg_ops = {
> .n_voltages = ARRAY_SIZE(vreg##_table), \
> .vsel_reg = PM8607_##vreg, \
> .vsel_mask = ARRAY_SIZE(vreg##_table) - 1, \
> + .apply_reg = PM8607_##ureg, \
> + .apply_bit = (ubit),\
> .enable_reg = PM8607_##ereg,\
> .enable_mask = 1 << (ebit), \
> }, \
> - .update_reg = PM8607_##ureg,\
> - .update_bit = (ubit), \
> .slope_double = (0), \
> .vol_table = (unsigned int *)##_table,\
> .vol_suspend= (unsigned int *)##_suspend_table,\
> @@ -344,9 +318,9 @@ static struct regulator_ops pm8606_preg_ops = {
> }
>
> static struct pm8607_regulator_info pm8607_regulator_info[] = {
> - PM8607_DVC(BUCK1, GO, 0, SUPPLIES_EN11, 0),
> - PM8607_DVC(BUCK2, GO, 1, SUPPLIES_EN11, 1),
> - PM8607_DVC(BUCK3, GO, 2, SUPPLIES_EN11, 2),
> + PM8607_DVC(BUCK1, GO, BIT(0), SUPPLIES_EN11, 0),
> + PM8607_DVC(BUCK2, GO, BIT(1), SUPPLIES_EN11, 1),
> + PM8607_DVC(BUCK3, GO, BIT(2), SUPPLIES_EN11, 2),
>
> PM8607_LDO(1, LDO1, 0, SUPPLIES_EN11, 3),
> PM8607_LDO(2, LDO2, 0, SUPPLIES_EN11, 4),
> --
> 1.7.9.5
>
>
>
Acked-by: Haojian Zhuang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 28/29] net/: rename net_random() to prandom_u32()
On Mon, Dec 24, 2012 at 11:14:15AM +0900, Akinobu Mita wrote:
> Use more preferable function name which implies using a pseudo-random
> number generator.
>
> Signed-off-by: Akinobu Mita
> Cc: Jesse Gross
> Cc: Venkat Venkatsubra
> Cc: Vlad Yasevich
> Cc: Sridhar Samudrala
> Cc: Neil Horman
> Cc: Steffen Klassert
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: linux-s...@vger.kernel.org
> Cc: d...@openvswitch.org
> Cc: net...@vger.kernel.org
> ---
> include/net/red.h | 2 +-
> net/802/garp.c| 2 +-
> net/openvswitch/actions.c | 2 +-
> net/rds/bind.c| 2 +-
> net/sctp/socket.c | 2 +-
> net/xfrm/xfrm_state.c | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
I'm largely indifferent to this patch, but I kind of feel like its just churn.
Whats the real advantage in making this change? I grant that it clearly
indicates the type of random number generator we're using at a given call site,
But for those using net_random, you probably don't care too much about
the source of your random bits. If you did really want true random vs.
pseudo-random data, you need to explicitly use the right call. You're previous
patch series did good cleanup on differentiating the different random calls, but
this just seems like its removing what is otherwise useful indirection.
Neil
> diff --git a/include/net/red.h b/include/net/red.h
> index ef46058..168bb2f 100644
> --- a/include/net/red.h
> +++ b/include/net/red.h
> @@ -303,7 +303,7 @@ static inline unsigned long red_calc_qavg(const struct
> red_parms *p,
>
> static inline u32 red_random(const struct red_parms *p)
> {
> - return reciprocal_divide(net_random(), p->max_P_reciprocal);
> + return reciprocal_divide(prandom_u32(), p->max_P_reciprocal);
> }
>
> static inline int red_mark_probability(const struct red_parms *p,
> diff --git a/net/802/garp.c b/net/802/garp.c
> index 8456f5d..cf7410d 100644
> --- a/net/802/garp.c
> +++ b/net/802/garp.c
> @@ -397,7 +397,7 @@ static void garp_join_timer_arm(struct garp_applicant
> *app)
> {
> unsigned long delay;
>
> - delay = (u64)msecs_to_jiffies(garp_join_time) * net_random() >> 32;
> + delay = (u64)msecs_to_jiffies(garp_join_time) * prandom_u32() >> 32;
> mod_timer(>join_timer, jiffies + delay);
> }
>
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index ac2defe..257bc36 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -404,7 +404,7 @@ static int sample(struct datapath *dp, struct sk_buff
> *skb,
>a = nla_next(a, )) {
> switch (nla_type(a)) {
> case OVS_SAMPLE_ATTR_PROBABILITY:
> - if (net_random() >= nla_get_u32(a))
> + if (prandom_u32() >= nla_get_u32(a))
> return 0;
> break;
>
> diff --git a/net/rds/bind.c b/net/rds/bind.c
> index 637bde5..7f95f4b 100644
> --- a/net/rds/bind.c
> +++ b/net/rds/bind.c
> @@ -118,7 +118,7 @@ static int rds_add_bound(struct rds_sock *rs, __be32
> addr, __be16 *port)
> rover = be16_to_cpu(*port);
> last = rover;
> } else {
> - rover = max_t(u16, net_random(), 2);
> + rover = max_t(u16, prandom_u32(), 2);
> last = rover - 1;
> }
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 9e65758..95860aa 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -5899,7 +5899,7 @@ static long sctp_get_port_local(struct sock *sk, union
> sctp_addr *addr)
>
> inet_get_local_port_range(, );
> remaining = (high - low) + 1;
> - rover = net_random() % remaining + low;
> + rover = prandom_u32() % remaining + low;
>
> do {
> rover++;
> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
> index 3459692..35ddaab 100644
> --- a/net/xfrm/xfrm_state.c
> +++ b/net/xfrm/xfrm_state.c
> @@ -1546,7 +1546,7 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32
> high)
> } else {
> u32 spi = 0;
> for (h=0; h - spi = low + net_random()%(high-low+1);
> + spi = low + prandom_u32() % (high - low + 1);
> x0 = xfrm_state_lookup(net, mark, >id.daddr,
> htonl(spi), x->id.proto, x->props.family);
> if (x0 == NULL) {
> x->id.spi = htonl(spi);
> --
> 1.7.11.7
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 06/27] x86, 64bit: early #PF handler set page table
On 12/20/2012 08:56 AM, Yinghai Lu wrote: So in that case, kgdb is broken and will need to be fixed up. That happens all the time with debugging tools. If there is a way that we can make all parties happy, we really should not break KGDB. Please reconsider to stop #PF handler in x86_64_start_kernel. in that case 1. microcode update still can use #PF handler to find microcode in ramdisk and use it. 2. kernel that is loaded above 4G, could set mapping in C instead of set that in head_64.S and use ioremap to access zero_page 3. KGDB still can call early_trap_init early before init_mem_mapping. Yinghai, this is total and utter bullshit. We should *fix* kgdb, not pave around it. I refuse to have kgdb be yet another Xen turning random kernel internals into ABIs. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 00/27] x86, boot, 64bit: Add support for loading ramdisk and bzImage above 4G
On 12/23/2012 10:00 AM, Yinghai Lu wrote: > On Sun, Dec 23, 2012 at 6:33 AM, H. Peter Anvin wrote: >> Explanation please? >> > > you have following change in the patch > > /* Finally jump to run C code and to be on real kernel address > * Since we are running on identity-mapped space we have to jump > * to the full 64bit address, this is only possible as indirect > * jump. In addition we need to ensure %cs is set so we make this > -* a far return. > +* a far jump. > */ > - movqinitial_code(%rip),%rax > pushq $0 # fake return address to stop unwinder > - pushq $__KERNEL_CS# set correct cs > - pushq %rax# target address in negative space > - lretq > + /* gas 2.22 is buggy and mis-assembles ljmpq */ > + rex64 ljmp *initial_code(%rip) > > #ifdef CONFIG_HOTPLUG_CPU > /* > > remove that change, AMD systems works again. > That is not an explanation. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 24/27] x86: Add swiotlb force off support
On Mon, Dec 24, 2012 at 3:34 PM, H. Peter Anvin wrote: > On 12/21/2012 09:11 PM, Yinghai Lu wrote: >> On Fri, Dec 21, 2012 at 7:25 PM, H. Peter Anvin wrote: >>> On 12/21/2012 07:23 PM, Eric W. Biederman wrote: In this case YH has been working on the case of loading a kernel completely above 4G, and apparently he has also been testing the case of running a kernel with no memory below 4G. >>> >>> It is worth noting that we cannot run with *no* memory below 4G -- it is >>> not possible to run SMP at least without some memory below the 1M mark. >> >> yes need keep 8k or so for trampoline. >> >> but kdump only use one CPU. >> > > ... except we have an active request to change that, and the trampoline > is more like 20K depending on options. looks like we should not worry that this now. kdump conf scripts always append some low range under 1M for second kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Porting problem: ndo_set_multicast_list removed
On Mon, Dec 24, 2012 at 11:16:27AM -0800, Eric Dumazet wrote:
> On Tue, 2012-12-25 at 00:30 +0800, Woody Wu wrote:
> > Hi, list
> >
> > I am porting an ethernet driver from 2.6.x to 3.7.1. I found in the new
> > kernel, the ndo_set_multicast_list method in the net_device_ops had been
> > removed. What's the story behind? Can I simply ignore this method
> > defined in an old driver?
> >
> > Please also help to check the below code, is the list of the operations
> > defined for my driver enough or not?
> >
> > const struct net_device_ops ax_netdev_ops = {
> > .ndo_open = mydriver_open,
> > .ndo_stop = mydriver_close,
> > .ndo_start_xmit = mydriver_start_xmit,
> > .ndo_get_stats = mydriver_get_stats,
> > /*.ndo_set_multicast_list = mydriver_set_multicast_list,*/
> > .ndo_set_mac_address= mydriver_set_mac_address,
> > };
> >
> > Thanks in advance.
> >
>
> Take a look at :
>
> commit afc4b13df143122f99a0eb10bfefb216c2806de0
> Author: Jiri Pirko
> Date: Tue Aug 16 06:29:01 2011 +
>
> net: remove use of ndo_set_multicast_list in drivers
>
> replace it by ndo_set_rx_mode
>
> Signed-off-by: Jiri Pirko
> Signed-off-by: David S. Miller
>
>
Thanks for the info!
--
woody
I can't go back to yesterday - because I was a different person then.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 24/27] x86: Add swiotlb force off support
On 12/21/2012 09:11 PM, Yinghai Lu wrote: > On Fri, Dec 21, 2012 at 7:25 PM, H. Peter Anvin wrote: >> On 12/21/2012 07:23 PM, Eric W. Biederman wrote: >>> >>> In this case YH has been working on the case of loading a kernel >>> completely above 4G, and apparently he has also been testing the case of >>> running a kernel with no memory below 4G. >>> >> >> It is worth noting that we cannot run with *no* memory below 4G -- it is >> not possible to run SMP at least without some memory below the 1M mark. > > yes need keep 8k or so for trampoline. > > but kdump only use one CPU. > ... except we have an active request to change that, and the trampoline is more like 20K depending on options. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nfsd: Don't overuse NFS?ERR_PERM error code
From: Pawel Dziepak
Unlike EPERM, NFS?ERR_PERM error code applies only when the operation could
not be completed because the caller is either not the owner or not a
privileged user. Actually, only OPEN, CREATE and SETATTR are supposed to
ever return such error code when a problem occurs when changing or setting
access permissions.
Generally, this patch replaces NFS?ERR_PERM with NFS?ERR_ACCESS which is a more
appropriate error code indicating that the caller is not allowed to perform the
requested operation.
In case of incorrect {file,directory} names either NFS?ERR_INVAL or
NFS4ERR_BADNAME is returned.
Opening for write files with append-only bit set or mandatory locking enabled
results in NFS4ERR_SHARE_DENIED.
Signed-off-by: Pawel Dziepak
---
fs/nfsd/nfsfh.c | 2 +-
fs/nfsd/vfs.c | 28
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
index 814afaa..b18382c 100644
--- a/fs/nfsd/nfsfh.c
+++ b/fs/nfsd/nfsfh.c
@@ -91,7 +91,7 @@ static __be32 nfsd_setuser_and_check_port(struct
svc_rqst *rqstp,
dprintk(KERN_WARNING
"nfsd: request from insecure port %s!\n",
svc_print_addr(rqstp, buf, sizeof(buf)));
- return nfserr_perm;
+ return nfserr_acces;
}
/* Set user creds for this exportpoint */
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index d586117..a9964de 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -777,7 +777,7 @@ nfsd_open(struct svc_rqst *rqstp, struct svc_fh
*fhp, umode_t type,
/* Disallow write access to files with the append-only bit set
* or any access when mandatory locking enabled
*/
- err = nfserr_perm;
+ err = nfserr_share_denied;
if (IS_APPEND(inode) && (may_flags & NFSD_MAY_WRITE))
goto out;
/*
@@ -924,8 +924,6 @@ nfsd_vfs_read(struct svc_rqst *rqstp, struct
svc_fh *fhp, struct file *file,
__be32 err;
int host_err;
- err = nfserr_perm;
-
if (file->f_op->splice_read && rqstp->rq_splice_ok) {
struct splice_desc sd = {
.len = 0,
@@ -1246,7 +1244,7 @@ nfsd_create(struct svc_rqst *rqstp, struct svc_fh *fhp,
__be32 err2;
int host_err;
- err = nfserr_perm;
+ err = nfserr_inval;
if (!flen)
goto out;
err = nfserr_exist;
@@ -1387,7 +1385,7 @@ do_nfsd_create(struct svc_rqst *rqstp, struct svc_fh *fhp,
int host_err;
__u32 v_mtime=0, v_atime=0;
- err = nfserr_perm;
+ err = nfserr_inval;
if (!flen)
goto out;
err = nfserr_exist;
@@ -1675,7 +1673,7 @@ nfsd_link(struct svc_rqst *rqstp, struct svc_fh *ffhp,
err = nfserr_isdir;
if (S_ISDIR(tfhp->fh_dentry->d_inode->i_mode))
goto out;
- err = nfserr_perm;
+ err = nfserr_inval;
if (!len)
goto out;
err = nfserr_exist;
@@ -1761,8 +1759,11 @@ nfsd_rename(struct svc_rqst *rqstp, struct
svc_fh *ffhp, char *fname, int flen,
if (ffhp->fh_export != tfhp->fh_export)
goto out;
- err = nfserr_perm;
- if (!flen || isdotent(fname, flen) || !tlen || isdotent(tname, tlen))
+ err = nfserr_inval;
+ if (!flen || !tlen)
+ goto out;
+ err = nfsd_v4client(rqstp) ? nfserr_badname : nfserr_inval;
+ if (isdotent(fname, flen) || isdotent(tname, tlen))
goto out;
host_err = fh_want_write(ffhp);
@@ -1850,8 +1851,11 @@ nfsd_unlink(struct svc_rqst *rqstp, struct
svc_fh *fhp, int type,
__be32 err;
int host_err;
- err = nfserr_acces;
- if (!flen || isdotent(fname, flen))
+ err = nfserr_inval;
+ if (!flen)
+ goto out;
+ err = nfsd_v4client(rqstp) ? nfserr_badname : nfserr_inval;
+ if (isdotent(fname, flen))
goto out;
err = fh_verify(rqstp, fhp, S_IFDIR, NFSD_MAY_REMOVE);
if (err)
@@ -2120,10 +2124,10 @@ nfsd_permission(struct svc_rqst *rqstp, struct
svc_export *exp,
__mnt_is_readonly(exp->ex_path.mnt))
return nfserr_rofs;
if (/* (acc & NFSD_MAY_WRITE) && */ IS_IMMUTABLE(inode))
- return nfserr_perm;
+ return nfserr_acces;
}
if ((acc & NFSD_MAY_TRUNC) && IS_APPEND(inode))
- return nfserr_perm;
+ return nfserr_acces;
if (acc & NFSD_MAY_LOCK) {
/* If we cannot rely on authentication in NLM requests,
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/25] TMIO MMC: don't use [delayed_]work_pending()
Hi Tejun On Fri, 21 Dec 2012, Tejun Heo wrote: > There's no need to test whether a (delayed) work item in pending > before queueing, flushing or cancelling it. Most uses are unnecessary > and quite a few of them are buggy. > > Remove unnecessary pending tests from tmio mmc. Only compile tested. Thanks for the patch. It looks good to me. What happens below is upon mmc card detection IRQs, of which there are typically several due to pin debouncing, a delayed work is scheduled to verify a possibly new card state (plugged in or removed). So, the code below checks, that after the first of those interrupts the work is already scheduled and doesn't schedule it again. IIUC, this is indeed unneeded, since queue_delayed_work_on() only has any effect if the work isn't queued yet. Ah, there's a nitpick - you can remove one pair of parenthesis;-) Otherwise, I guess, this is an Acked-by: Guennadi Liakhovetski and Chris can take it (preferably, after the correction) via his queue. If you give me a bit more time I can also test this, but it really looks pretty obvious. Maybe Chris will prefer you to take this via your queue - that's up to you two to decide. Thanks Guennadi > > Signed-off-by: Tejun Heo > Cc: Guennadi Liakhovetski > Cc: Ian Molton > Cc: linux-...@vger.kernel.org > --- > Please let me know how this patch should be routed. I can take it > through the workqueue tree if necessary. > > Thanks. > > drivers/mmc/host/tmio_mmc_pio.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c > index 50bf495..f4f18b3 100644 > --- a/drivers/mmc/host/tmio_mmc_pio.c > +++ b/drivers/mmc/host/tmio_mmc_pio.c > @@ -573,8 +573,7 @@ static bool __tmio_mmc_card_detect_irq(struct > tmio_mmc_host *host, > tmio_mmc_ack_mmc_irqs(host, TMIO_STAT_CARD_INSERT | > TMIO_STAT_CARD_REMOVE); > if ireg & TMIO_STAT_CARD_REMOVE) && mmc->card) || > - ((ireg & TMIO_STAT_CARD_INSERT) && !mmc->card)) && > - !work_pending(>detect.work)) > + ((ireg & TMIO_STAT_CARD_INSERT) && !mmc->card))) > mmc_detect_change(host->mmc, msecs_to_jiffies(100)); > return true; > } > -- > 1.8.0.2 > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers: video: fix warnings int-to-pointer-cast
Fixed compile warnings cast to pointer from integer of different size Signed-off-by: Stefan Hasko --- drivers/video/arkfb.c|2 +- drivers/video/s3fb.c |2 +- drivers/video/vt8623fb.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/video/arkfb.c b/drivers/video/arkfb.c index 555dd4c..3e4ed96 100644 --- a/drivers/video/arkfb.c +++ b/drivers/video/arkfb.c @@ -1016,7 +1016,7 @@ static int __devinit ark_pci_probe(struct pci_dev *dev, const struct pci_device_ pcibios_bus_to_resource(dev, _res, _reg); - par->state.vgabase = (void __iomem *) vga_res.start; + par->state.vgabase = (void __iomem *)(unsigned long) vga_res.start; /* FIXME get memsize */ regval = vga_rseq(par->state.vgabase, 0x10); diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c index 1d00736..def0a86 100644 --- a/drivers/video/s3fb.c +++ b/drivers/video/s3fb.c @@ -1183,7 +1183,7 @@ static int __devinit s3_pci_probe(struct pci_dev *dev, const struct pci_device_i pcibios_bus_to_resource(dev, _res, _reg); - par->state.vgabase = (void __iomem *) vga_res.start; + par->state.vgabase = (void __iomem *)(unsigned long) vga_res.start; /* Unlock regs */ cr38 = vga_rcrt(par->state.vgabase, 0x38); diff --git a/drivers/video/vt8623fb.c b/drivers/video/vt8623fb.c index 4e74d26..2516808 100644 --- a/drivers/video/vt8623fb.c +++ b/drivers/video/vt8623fb.c @@ -729,7 +729,7 @@ static int __devinit vt8623_pci_probe(struct pci_dev *dev, const struct pci_devi pcibios_bus_to_resource(dev, _res, _reg); - par->state.vgabase = (void __iomem *) vga_res.start; + par->state.vgabase = (void __iomem *)(unsigned long) vga_res.start; /* Find how many physical memory there is on card */ memsize1 = (vga_rseq(par->state.vgabase, 0x34) + 1) >> 1; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] signal: add a helper for dequeuing signals from a specified queue
[CC+=linux-api]
On Mon, Dec 24, 2012 at 9:13 AM, Andrey Vagin wrote:
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Serge Hallyn
> Cc: Oleg Nesterov
> Cc: Andrew Morton
> Cc: "Eric W. Biederman"
> Cc: Al Viro
> Cc: Pavel Emelyanov
> CC: Cyrill Gorcunov
> Signed-off-by: Andrey Vagin
> ---
> include/linux/sched.h | 9 -
> kernel/signal.c | 13 +
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 0dd42a0..de9a4bf 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -2159,7 +2159,14 @@ extern void flush_signals(struct task_struct *);
> extern void __flush_signals(struct task_struct *);
> extern void ignore_signals(struct task_struct *);
> extern void flush_signal_handlers(struct task_struct *, int force_default);
> -extern int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t
> *info);
> +extern int do_dequeue_signal(struct task_struct *tsk,
> + sigset_t *mask, siginfo_t *info, int queue);
> +
> +static inline int dequeue_signal(struct task_struct *tsk,
> + sigset_t *mask, siginfo_t *info)
> +{
> + return do_dequeue_signal(tsk, mask, info, 0);
> +}
>
> static inline int dequeue_signal_lock(struct task_struct *tsk, sigset_t
> *mask, siginfo_t *info)
> {
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 0af8868..91bb76f2 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -597,17 +597,22 @@ static int __dequeue_signal(struct sigpending *pending,
> sigset_t *mask,
> * Dequeue a signal and return the element to the caller, which is
> * expected to free it.
> *
> + * @queue: dequeue from a private queue, if a value is not positive
if a value is not positive ==> if value is nonpositive
> + *dequeue from a shared queue, if a value if not negative
if a value is not negative ==> if value is nonnegative
Thanks,
Michael
--
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] signalfd: a kernel interface for dumping/restoring pending signals
[CC+=linux-api] Hi Andrey, On Mon, Dec 24, 2012 at 9:13 AM, Andrey Vagin wrote: > The idea is simple. We need to get the siginfo for each signal on dump, > and then return it back on restore. > > The first problem is that the kernel doesn’t report complete siginfo-s > in user-space. In a signal handler the kernel strips SI_CODE from > siginfo. When a siginfo is received from signalfd, it has a different > format with fixed sizes of fields. The interface of signalfd was > extended. If a signalfd is created with the flag SFD_RAW, it returns > siginfo in a raw format. We need to choose a queue, so two flags > SFD_GROUP and SFD_PRIVATE were added. > > rt_sigqueueinfo looks suitable for restoring signals, but it can’t send > siginfo with a positive si_code, because these codes are reserved for > the kernel. In the real world each person has right to do anything with > himself, so I think a process should able to send any siginfo to itself. I see that you CCed me on a couple of the patches in this series. Thanks for that. But, since most of the series concerns API changes, it would be good also to CC linux-api on (future revisions of) the entire series. I have a few largely cosmetic comments on some of the patches, which I'll add in the respective threads. Thanks, Michael > Cc: Serge Hallyn > Cc: Oleg Nesterov > Cc: Andrew Morton > Cc: "Eric W. Biederman" > Cc: Al Viro > Cc: Pavel Emelyanov > CC: Cyrill Gorcunov > > -- > 1.7.11.7 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface", http://blog.man7.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] signalfd: add ability to choose a private or shared queue
[CC+=linux-api]
Andrey,
(Among other things, some suggested wording fixes below to improve the
eventual commit log entry).
On Mon, Dec 24, 2012 at 9:13 AM, Andrey Vagin wrote:
> This patch is added two flags SFD_GROUP and SFD_SHARED.
> SFD_SHARED - read signals from a shared queue
> SFD_PRIVATE - read signals from a private queue
These names and comments are not quite meaningful I find. Also, you
use SFD_SHARED here, but the name below is SFD_GROUP. I had to read
further to confirm what I guessed the names meant. How about these
names and comments:
SFD_SHARED_QUEUE - read signals from a shared (process wide) queue
SFD_PER_THREAD_QUEUE - read signals from a per-thread queue
> Without this flags or with both flags signals are read from both queues.
Without these flags
> This functionality is requered for dumping pending signals.
"required"
> Cc: Alexander Viro
> Cc: "Paul E. McKenney"
> Cc: David Howells
> Cc: Thomas Gleixner
> Cc: Oleg Nesterov
> Cc: Michael Kerrisk
> Cc: Pavel Emelyanov
> CC: Cyrill Gorcunov
> Signed-off-by: Andrey Vagin
> ---
> fs/signalfd.c | 25 +++--
> include/uapi/linux/signalfd.h | 2 ++
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/fs/signalfd.c b/fs/signalfd.c
> index 95f1444..a35aeda 100644
> --- a/fs/signalfd.c
> +++ b/fs/signalfd.c
> @@ -170,13 +170,13 @@ static int signalfd_copyinfo(struct signalfd_siginfo
> __user *uinfo,
> }
>
> static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, siginfo_t *info,
> - int nonblock)
> + int nonblock, int queue)
> {
> ssize_t ret;
> DECLARE_WAITQUEUE(wait, current);
>
> spin_lock_irq(>sighand->siglock);
> - ret = dequeue_signal(current, >sigmask, info);
> + ret = do_dequeue_signal(current, >sigmask, info, queue);
> switch (ret) {
> case 0:
> if (!nonblock)
> @@ -223,14 +223,21 @@ static ssize_t signalfd_read(struct file *file, char
> __user *buf, size_t count,
> bool raw = file->f_flags & SFD_RAW;
> ssize_t ret, total = 0;
> siginfo_t info;
> + int queue = 0;
>
> count /= sizeof(struct signalfd_siginfo);
> if (!count)
> return -EINVAL;
>
> + if (file->f_flags & SFD_GROUP)
> + queue++;
> +
> + if (file->f_flags & SFD_PRIVATE)
> + queue--;
> +
> siginfo = (struct signalfd_siginfo __user *) buf;
> do {
> - ret = signalfd_dequeue(ctx, , nonblock);
> + ret = signalfd_dequeue(ctx, , nonblock, queue);
> if (unlikely(ret <= 0))
> break;
>
> @@ -274,6 +281,8 @@ static const struct file_operations signalfd_fops = {
> .llseek = noop_llseek,
> };
>
> +#define SIGNAFD_FLAGS (SFD_RAW | SFD_GROUP | SFD_PRIVATE)
This name is rather obtuse. What is the purpose of grouping these
three flags like this? Yes, I understand how you use the name below,
but the grouping seems arbitrary.
Why not have a grouping of all SFD_ 5 flags?
#define SFD_ALL_FLAGS (SFD_CLOEXEC | SFD_NONBLOCK | SFD_RAW |
SFD_GROUP | SFD_PRIVATE)
And use that appropriately below.
See also the comments below about individual flags.
> +
> SYSCALL_DEFINE4(signalfd4, int, ufd, sigset_t __user *, user_mask,
> size_t, sizemask, int, flags)
> {
> @@ -284,7 +293,7 @@ SYSCALL_DEFINE4(signalfd4, int, ufd, sigset_t __user *,
> user_mask,
> BUILD_BUG_ON(SFD_CLOEXEC != O_CLOEXEC);
> BUILD_BUG_ON(SFD_NONBLOCK != O_NONBLOCK);
>
> - if (flags & ~(SFD_CLOEXEC | SFD_NONBLOCK | SFD_RAW))
> + if (flags & ~(SFD_CLOEXEC | SFD_NONBLOCK | SIGNAFD_FLAGS))
> return -EINVAL;
>
> if (sizemask != sizeof(sigset_t) ||
> @@ -308,9 +317,9 @@ SYSCALL_DEFINE4(signalfd4, int, ufd, sigset_t __user *,
> user_mask,
>O_RDWR | (flags & (O_CLOEXEC |
> O_NONBLOCK)));
> if (ufd < 0)
> kfree(ctx);
> - else if (flags & SFD_RAW) {
> + else if (flags & SIGNAFD_FLAGS) {
> struct fd f = fdget(ufd);
> - f.file->f_flags |= flags & SFD_RAW;
> + f.file->f_flags |= flags & SIGNAFD_FLAGS;
> fdput(f);
> }
> } else {
> @@ -322,6 +331,10 @@ SYSCALL_DEFINE4(signalfd4, int, ufd, sigset_t __user *,
> user_mask,
> fdput(f);
> return -EINVAL;
> }
> +
> + f.file->f_flags = (f.file->f_flags & ~SIGNAFD_FLAGS) |
> + (flags & SIGNAFD_FLAGS);
> +
> spin_lock_irq(>sighand->siglock);
> ctx->sigmask = sigmask;
> spin_unlock_irq(>sighand->siglock);
> diff --git
usb issues with 3.6.X and 3.7.X
Hi all, I'm experiencing some usb-related issues with recent kernels (3.6.7 and 3.7.1 at least.) Basically I have a V500 epson scanner that worked just fine with older kernels; since last time I used it I've changed several kernels and now the oldest that I have on my machine is 3.6.7. Recently I tried to use the usb scanner without success. I've read the 3.6.4 changelog because there seems to be a very similar issue patched, commit e4e29779ec498f4905461a13b6ba58ba4f60152b Author: Henrik Rydberg Date: Sat Oct 13 12:20:36 2012 +0200 usbdevfs: Fix broken scatter-gather transfer commit 014639003c77a51fc319c9fdf225e7747cb6e18d upstream. The handling of large output bulk transfers is broken; the same user page is read over and over again. Fixed with this patch. But probably it is not the same issue, as I've tried with 3.7.1 and 3.6.7; the scanner works just fine if connected to a Mac, so I can exclude hardware issues. I've tried to look at usb traffic with usbmon, but honestly it's not my ground :) Basically, the scanner takes a lot of time to be identified by iscan and once identified iscan claims to be unable to speak with the scanner. If this can be useful, here comes the usbmon capture with 3.7.1: (it seems that some dialog happens only after 90 seconds from start, andh at that moment the device is recognized. Of course, on other laptops the scanner is identified at once) 09edf540 0.506456 S Co:2:009:0 s 00 09 0001 0 09edf540 0.506697 C Co:2:009:0 0 0 09edf540 0.506733 S Bo:2:009:2 - 2 = 1b66 . f 09edf540 0.507442 C Bo:2:009:2 0 2 > 09edf540 0.507456 S Bi:2:009:1 - 4 < 09edf540 0.508442 C Bi:2:009:1 0 1 = 15 09edf540 0.508450 S Bi:2:009:1 - 42 < 09edf540 30.508543 C Bi:2:009:1 -2 0 08706a80 30.508563 S Bi:2:009:1 - 42 < 08706a80 60.509511 C Bi:2:009:1 -2 0 08706a80 60.509529 S Bi:2:009:1 - 42 < 08706a80 90.509970 C Bi:2:009:1 -2 0 087dd840 90.510030 S Co:2:009:0 s 02 01 0081 0 087dd840 90.510591 C Co:2:009:0 0 0 087dd840 90.510599 S Co:2:009:0 s 02 01 0081 0 087dd840 90.510840 C Co:2:009:0 0 0 087dd840 90.510845 S Co:2:009:0 s 02 01 0002 0 087dd840 90.511092 C Co:2:009:0 0 0 087ddb40 90.511159 S Co:2:009:0 s 00 09 0001 0 087ddb40 90.511341 C Co:2:009:0 0 0 087ddb40 90.511356 S Co:2:009:0 s 02 01 0081 0 087ddb40 90.511591 C Co:2:009:0 0 0 087ddb40 90.511597 S Co:2:009:0 s 02 01 0002 0 087ddb40 90.511841 C Co:2:009:0 0 0 087ddb40 90.511950 S Co:2:009:0 s 00 09 0001 0 087ddb40 90.512215 C Co:2:009:0 0 0 087ddb40 90.512225 S Co:2:009:0 s 02 01 0081 0 087ddb40 90.512465 C Co:2:009:0 0 0 087ddb40 90.512470 S Co:2:009:0 s 02 01 0002 0 087ddb40 90.512717 C Co:2:009:0 0 0 087ddb40 90.512761 S Co:2:009:0 s 00 09 0001 0 087ddb40 90.513091 C Co:2:009:0 0 0 087ddb40 90.513101 S Co:2:009:0 s 02 01 0081 0 087ddb40 90.513341 C Co:2:009:0 0 0 087ddb40 90.513346 S Co:2:009:0 s 02 01 0002 0 087ddb40 90.513591 C Co:2:009:0 0 0 087ddb40 90.513630 S Co:2:009:0 s 00 09 0001 0 087ddb40 90.513841 C Co:2:009:0 0 0 087ddb40 90.513850 S Co:2:009:0 s 02 01 0081 0 087ddb40 90.514090 C Co:2:009:0 0 0 087ddb40 90.514096 S Co:2:009:0 s 02 01 0002 0 087ddb40 90.514342 C Co:2:009:0 0 0 eb0f5780 103.718860 S Co:2:009:0 s 00 09 0001 0 eb0f5780 103.719113 C Co:2:009:0 0 0 eb0f5780 103.719144 S Bo:2:009:2 - 2 = 1b66 . f eb0f5780 103.719612 C Bo:2:009:2 0 2 > eb0f5780 103.719626 S Bi:2:009:1 - 4 < eb0f5780 103.720612 C Bi:2:009:1 0 1 = 15 31ff63c0 103.720653 S Bi:2:009:1 - 42 < 31ff63c0 133.721562 C Bi:2:009:1 -2 0 0861ca80 133.721579 S Bi:2:009:1 - 42 < 0861ca80 163.721714 C Bi:2:009:1 -2 0 eb054000 163.721733 S Bi:2:009:1 - 42 < eb054000 193.722675 C Bi:2:009:1 -2 0 eb3d23c0 193.722707 S Co:2:009:0 s 02 01 0081 0 eb3d23c0 193.723171 C Co:2:009:0 0 0 eb3d23c0 193.723188 S Bo:2:009:2 - 2 = 1b40 . @ eb3d23c0 193.724046 C Bo:2:009:2 0 2 > eb3d23c0 193.724055 S Bi:2:009:1 - 1 < eb3d23c0 193.725044 C Bi:2:009:1 0 1 = 15 eb3d23c0 193.725054 S Bo:2:009:2 - 2 = 1b49 . I eb3d23c0 193.725169 C Bo:2:009:2 0 2 > eb3d23c0 193.725176 S Bi:2:009:1 - 4 < eb3d23c0 193.725294 C Bi:2:009:1 0 1 = 15 eb3d23c0 193.725321 S Bo:2:009:2 - 2 = 1c46 . F eb3d23c0 193.725421 C Bo:2:009:2 0 2 > eb3d23c0 193.725428 S Bi:2:009:1 - 16 < 0868d300 253.727305 C Bi:2:009:1 -2 0 087d6a80 253.727321 S Bi:2:009:1 - 16 < 087d6a80 283.728362 C Bi:2:009:1 -2 0 08522240 283.728384 S Co:2:009:0 s 02 01 0081 0 08522240 283.729358 C Co:2:009:0 0 0 08522240 283.729369 S Bo:2:009:2 - 2 = 1c49 . I 08522240 283.730234 C Bo:2:009:2 0 2 > 08522240 283.730242 S Bi:2:009:1 - 80 < 08522240 313.730875 C Bi:2:009:1 -2 0 35ecc3c0 313.730896 S Bi:2:009:1 - 80 < 35ecc3c0 343.731089 C Bi:2:009:1 -2 0 0846d900 343.73 S Bi:2:009:1 - 80 < 0846d900 373.731773 C Bi:2:009:1 -2 0 eb200180
Re: [B.A.T.M.A.N.] [PATCH] net, batman: don't crash on zero length strings in routing_algo
On Monday, December 24, 2012 23:42:15 Pau Koning wrote: > On Mon, Dec 24, 2012 at 3:38 PM, Marek Lindner wrote: > > On Monday, December 24, 2012 22:18:52 Pau Koning wrote: > >> On Mon, Nov 19, 2012 at 9:08 PM, Sasha Levin wrote: > >> > The code that works with routing_algo assumes that the string passed > >> > is non > >> > >> > empty, this assumption is wrong: > >> Why isn't this patch part of Linux 3.7? It seems to be a bugfix and it > >> was sent early enough? > > > > The patch received a reply mere 2 hours after it was sent. Again, please > > read all mails before making noise. > > Ok, leaving this problem unsolved is the correct way to handle it? > Nobody is allowed to say anything? No, of course you are allowed "to say" something. I was simply pointing you to the explanation why the patch wasn't merged yet. Cheers, Marek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 25/25] ipc: don't use [delayed_]work_pending()
On Mon, Dec 24, 2012 at 10:45:20AM -0800, Tejun Heo wrote: > I was confused a bit there. We can't. Nothing guarantees that the > queuer sees the cleared PENDING before the work item starts execution, > and I think ipc memory hotplug could also be broken from that. Stupid question: why not clear PENDING after execution is done? I'm looking at process_one_work() here. > It's highly unlikely to actually happen and there may be external > locking which prevents the race from actually happening, but there's > nothing synchronizing queueing and the execution of the work item. > Looking at that part of code only, it's possible that it fails to > queue the work item after a memory hotplug event even though the > previous queueing already started execution and processed a couple > notifiers. Maybe failure to queue could be signalled with a proper return value from __queue_work()? Btw, I'm afraid I don't understand the "memory hotplug event" aspect and how that can influence the queueing - all it does it is list_add_tail, basically. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 25/25] ipc: don't use [delayed_]work_pending()
On Mon, Dec 24, 2012 at 11:07:23AM -0800, Tejun Heo wrote: > And that's broken. It seems trivial but it really isn't and trying to > optimize things like that in cold paths is just a bad idea. Not enough > people will pay attention to them and they will stay subtly broken for > a very long time. So, having "not doing anything in code which isn't > necessary in code" as priority in cold paths is likely to hurt you. > A better one would be "doing straight-forward and simple thing with > acceptable overhead". Ok, understood. I have only one question: how do you make sure schedule_work() is used only in cold paths? Btw, there's __cancel_delayed_work() which is not used anywhere and it could be deleted AFAICT. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] RFC: Intel QST driver
On Mon, Dec 24, 2012 at 08:37:57AM +, Simon J. Rowe wrote:
> I've written a driver for the Intel Quiet System Technology (QST)
> function of the Management Engine Interface found on recent Intel
> chipsets.
>
> The git repo can be found here:
>
> http://mose.dyndns.org/mei.git
>
> A few questions / observations,
>
> 1) The code was developed and tested on 2.6.39. I would hope it
> compiles and runs on 3.x but I haven't tried it.
>
Hi Simon,
2.6.39 is pretty old. It doesn't include the new mei driver (which is now
in drivers/misc/mei).
> 2) The main hwmon code is in qst-hwmon.c. This implements QST v1, I
> don't have access to hardware that supports v2. I would imagine that
> implementing v2 would result in a new module (qst2-hwmon) which would
> be almost identical.
>
Is it that much different that it would require a separate driver, especially
if it is almost identical ?
> 3) I've gone a bit overboard with preprocessor macros but it does mean
> that the amount of duplicated code is kept to a minimum.
>
It also hides possible error cases, though, and makes review very complicated.
You would be better off using function parameters as much as possible. Plus,
after all, it is not correct that you avoid duplicate code. You only avoid
duplicate source code. Fore that, the additional cost (in terms of risk and
maintainability) is pretty high.
> 3) I've not implemented any PWM methods yet.
>
> 4) I don't believe the MEI (HECI) implementation that Intel have
> already submitted to the mainline kernel is usable by other kernel
> modules. I have re-implemented it in a way that is accessible to
> either the kernel or userspace.
>
2.6.39 does not include the new mei driver, so I don't think you can make
that claim.
I would suggest to have a look into the new driver and work with its
maintainer to make it better suitable for other drivers if needed.
Its main deficiency, as far as I could see when I looked into it, is that it
doesn't support out-of-directory drivers very well - which means the hwmon
driver might have to reside in drivers/misc/mei instead of drivers/hwmon.
Not an optimal solution, but better than nothing.
> 5) I had to patch libsensors to work with a new bus type
>
> diff -ur lm_sensors-3.3.1.org//lib/sysfs.c lm_sensors-3.3.1/lib/sysfs.c
> --- lm_sensors-3.3.1.org//lib/sysfs.c 2011-03-04 20:37:43.0 +
> +++ lm_sensors-3.3.1/lib/sysfs.c2012-11-14 21:48:52.144860375 +
> @@ -701,6 +701,12 @@
> /* As of kernel 2.6.32, the hid device names don't
> look good */
> entry.chip.bus.nr = bus;
> entry.chip.addr = id;
> + } else
> + if (subsys && !strcmp(subsys, "intel-mei") &&
> + sscanf(dev_name, "mei%d:%d", , ) == 2) {
> + entry.chip.bus.type = SENSORS_BUS_TYPE_PCI;
> + entry.chip.bus.nr = bus;
> + entry.chip.addr = fn;
> } else {
> /* Ignore unknown device */
> err = 0;
>
Is that really necessary ? Changing the ABI/API to userland is always
problematic.
> surely this sort of knowledge belongs in the driver not userspace?
> Could drivers not provide another set of sysfs attributes which expose
> bus type, number, addr etc?
>
> Please let me know if there's any changes or improvements I can make
> to it.
>
You might want to run your code through checkpatch and fix all errors and
warnings. The major problem, though, is that we can not have two instances
of mei core code in the kernel.
Copying the mei driver maintainer and the kernel mailing list for additional
input.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1)
Em Sun, 23 Dec 2012 14:29:04 -0800 Linus Torvalds escreveu: > On Sun, Dec 23, 2012 at 12:21 PM, Mauro Carvalho Chehab > wrote: > > > > Agreed: ENOENT was a bad choice, and it should be reverted. > > Well, *any* other error value is likely a bad choice. Well, UVC should return the same error codes as the other drivers, for the same error types. That's what that patch was trying to fix (unfortunately, doing the wrong thing). > > What I'm trying to understand is why pulseaudio is complaining. > > Is it because it only accepts EINVAL error code for media controls? > > What I am trying to understand is why you even care, and how you could > *possibly* ever even consider this to be a user-space bug. Because there are other error codes that can be returned by other drivers when this specific ioctl (VIDIOC_QUERYCTRL) is called. Let me take one step back and explain what this patch were trying to do. What happens is that the V4L2 API is very complex (~80 ioctls). In practice, that means that two drivers implementing the API might behave a little different than the others, with causes troubles on userspace. We're working to fix it, by testing all of them using userspace testing tools. In the specific case of VIDIOC_QUERYCTRL, most drivers now use some functions inside the v4l2 core that warrants that they all work the same way. UVC is an special case, as it can dynamically create media controls in runtime. The new uvc 1.5 spec will make it even harder to use the core. So, UVC has its own implementation for this ioctl, with can unfortunately led into a different behavior from userspace. This was actually happening, and Laurent's (broken) patch were trying to address it. Unfortunately, the tool he used to test had a bug. So, he didn't noticed that his patch were broken. >From my side, when I saw Rafael's complaint, what I wanted were just to understand a little more what happened, before applying his patch. Sorry if I miss-expressed. > Applications *do* care about error return values. There's no way in > hell you can willy-nilly just change them. And if you do change them, > and applications break, there is no way in hell you can then blame the > application. Yes. What we're trying to do is to make sure that all drivers will return the same error codes, and not to change the API. > Yes, I'm upset. Very upset. Why was the error value changed in the > first place? There was no reason given, and it was changed to a > completely idiotic value. And when applications - understandably - > broke, you start asking "why?" > > If applications didn't care about specific error values, then it > wouldn't make sense to have more than one to begin with, and you > shouldn't care which one that was. But since applications *do* care, > and since we *do* have multiple error values, we stick to the old > ones, unless there are some *very* good reasons not to. Fully agreed. > And those reasons really need to be very good, and spelled out and > explained. In this case, none of that was even remotely the case. > > So your question "why would pulseaudio care" is totally *irrelevant*, > senseless, and has nothing to do with anything. Pulseaudio cares, and > caring fundamentally makes sense. It's questioning that obvious fact > that does not make sense! With audio devices, pulseaudio opens devices on its start and keep it open forever. >From Rafael's email, it seemed that newer versions could also be doing something similar. On such case, this would likely break all drivers (even on kernel 2.6 or earlier), because the drivers lock the streaming capabilities to the firstly opened handler, due to hardware limitation (the DMA engines at the hardware only support one transfer at the same time). There's an ioctl that overrides its behavior, that should be called by an application that wants to force its ownership, but most applications don't use it. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] MIPS: MSP71xx: Move include files
Now that Yosemite's gone we can move the MSP71xx include files
one level up.
Signed-off-by: Shane McDonald
---
Patch history:
V1: Original patch
V2: Use format-patch's -M option to indicate file renames
.../cpu-feature-overrides.h|0
.../msp71xx => mach-pmcs-msp71xx}/gpio.h |0
.../msp71xx => mach-pmcs-msp71xx}/msp_cic_int.h|0
.../msp_gpio_macros.h |0
.../msp71xx => mach-pmcs-msp71xx}/msp_int.h|0
.../msp71xx => mach-pmcs-msp71xx}/msp_pci.h|0
.../msp71xx => mach-pmcs-msp71xx}/msp_prom.h |0
.../msp71xx => mach-pmcs-msp71xx}/msp_regops.h |0
.../msp71xx => mach-pmcs-msp71xx}/msp_regs.h |0
.../msp71xx => mach-pmcs-msp71xx}/msp_slp_int.h|0
.../msp71xx => mach-pmcs-msp71xx}/msp_usb.h|0
.../msp71xx => mach-pmcs-msp71xx}/war.h|0
arch/mips/pmcs-msp71xx/Platform|2 +-
13 files changed, 1 insertions(+), 1 deletions(-)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/cpu-feature-overrides.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx => mach-pmcs-msp71xx}/gpio.h
(100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_cic_int.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_gpio_macros.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_int.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_pci.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_prom.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_regops.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_regs.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_slp_int.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx =>
mach-pmcs-msp71xx}/msp_usb.h (100%)
rename arch/mips/include/asm/{pmc-sierra/msp71xx => mach-pmcs-msp71xx}/war.h
(100%)
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/cpu-feature-overrides.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/cpu-feature-overrides.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/cpu-feature-overrides.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/cpu-feature-overrides.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/gpio.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/gpio.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/gpio.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/gpio.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_cic_int.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_cic_int.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_cic_int.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_cic_int.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_gpio_macros.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_gpio_macros.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_gpio_macros.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_gpio_macros.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_int.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_int.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_int.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_int.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_pci.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_pci.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_pci.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_pci.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_prom.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_prom.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_prom.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_prom.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_regops.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_regops.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_regops.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_regops.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_regs.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_regs.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_regs.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_regs.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_slp_int.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_slp_int.h
similarity index 100%
rename from arch/mips/include/asm/pmc-sierra/msp71xx/msp_slp_int.h
rename to arch/mips/include/asm/mach-pmcs-msp71xx/msp_slp_int.h
diff --git a/arch/mips/include/asm/pmc-sierra/msp71xx/msp_usb.h
Re: Porting problem: ndo_set_multicast_list removed
On Tue, 2012-12-25 at 00:30 +0800, Woody Wu wrote:
> Hi, list
>
> I am porting an ethernet driver from 2.6.x to 3.7.1. I found in the new
> kernel, the ndo_set_multicast_list method in the net_device_ops had been
> removed. What's the story behind? Can I simply ignore this method
> defined in an old driver?
>
> Please also help to check the below code, is the list of the operations
> defined for my driver enough or not?
>
> const struct net_device_ops ax_netdev_ops = {
> .ndo_open = mydriver_open,
> .ndo_stop = mydriver_close,
> .ndo_start_xmit = mydriver_start_xmit,
> .ndo_get_stats = mydriver_get_stats,
> /*.ndo_set_multicast_list = mydriver_set_multicast_list,*/
> .ndo_set_mac_address= mydriver_set_mac_address,
> };
>
> Thanks in advance.
>
Take a look at :
commit afc4b13df143122f99a0eb10bfefb216c2806de0
Author: Jiri Pirko
Date: Tue Aug 16 06:29:01 2011 +
net: remove use of ndo_set_multicast_list in drivers
replace it by ndo_set_rx_mode
Signed-off-by: Jiri Pirko
Signed-off-by: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 25/25] ipc: don't use [delayed_]work_pending()
Hello, Borislav. On Mon, Dec 24, 2012 at 07:55:55PM +0100, Borislav Petkov wrote: > Basically, with the amount of bloat we're adding to the kernel, the > couple of instructions we're adding here and there and think they won't > harm us, tends to crop up with time until we're too damn slow to do > anything. Yeah, I think we need them for the operations to hold w/o outer synchronization. If you can think of ways to optimize them, please be my guest. > Now, you're saying that optimizing cold paths is something that calls > for serious reconsideration of a person's priorities, and I'm saying > just don't do anything in code that's not necessary. Fullstop. If this Not doing anything that's not necessary is an extreme and not necessary what you want in cold paths. If doing something extra makes your code much simpler and more maintainable and the path is cold enough for the extra to not matter, then that's the right trade-off. > is leading to convolutions, then the design is suboptimal and needs > adjustment. If [delayed_]work_pending is being abused, then fix it or > add a new primitive which only checks for pending work and doesn't > unconditionally toggle interrupts. "only checks for pending work" in a way which is race-free and usable from any context is a tricky thing to do. > > I don't think we have cases where this actually matters but it could > > be that we can add work_pending() tests to queue_work_on(). I *think* > > that shouldn't break work scheduling semantics. Not completely sure > > tho. Need to think about it more. > > Yes, something like that. And that's broken. It seems trivial but it really isn't and trying to optimize things like that in cold paths is just a bad idea. Not enough people will pay attention to them and they will stay subtly broken for a very long time. So, having "not doing anything in code which isn't necessary in code" as priority in cold paths is likely to hurt you. A better one would be "doing straight-forward and simple thing with acceptable overhead". Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 25/25] ipc: don't use [delayed_]work_pending()
On Mon, Dec 24, 2012 at 10:33:34AM -0800, Tejun Heo wrote: > If one looks at something happening in a path as cold as memory > hotplug and thinks about optimizing a coupld memory accesses, the > person's priorities need serious reconsideration. I think approaches > like that are actively harmful. They lead to unnecessary (and thus > difficult to comprehend) convolutions which don't really help anything > while deteoriorating code base. Maybe I'm not expressing myself clearly enough so let me try again: all I'm saying is, I don't like the idea of needlessly toggling interrupts and having a locked operation just to understand that there's work pending. Basically, with the amount of bloat we're adding to the kernel, the couple of instructions we're adding here and there and think they won't harm us, tends to crop up with time until we're too damn slow to do anything. Now, you're saying that optimizing cold paths is something that calls for serious reconsideration of a person's priorities, and I'm saying just don't do anything in code that's not necessary. Fullstop. If this is leading to convolutions, then the design is suboptimal and needs adjustment. If [delayed_]work_pending is being abused, then fix it or add a new primitive which only checks for pending work and doesn't unconditionally toggle interrupts. > I don't think we have cases where this actually matters but it could > be that we can add work_pending() tests to queue_work_on(). I *think* > that shouldn't break work scheduling semantics. Not completely sure > tho. Need to think about it more. Yes, something like that. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] resubmit w1_therm:Retries:remove old code add CRC
Hi Sorry for late reply - too much things to finish before the new year. On Tue, Dec 18, 2012 at 01:37:56AM +, david (da...@avoncliff.com) wrote: > w1_therm includes some obsolete code to detect bad_roms, this is no > longer relevant. > The retry code is only used for this bad_rom test, however there is a > CRC check that detects a bad read, but does not trigger a retry. This > patch removes all the bad_rom code and uses the CRC check to trigger > retries. > > Signed-off-by: David Stevenson Greg, patch is ok, we discussed it in private with David Please push it into your tree Acked-by: Evgeniy Polyakov -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 25/25] ipc: don't use [delayed_]work_pending()
Hello, again. On Mon, Dec 24, 2012 at 10:33:34AM -0800, Tejun Heo wrote: > I don't think we have cases where this actually matters but it could > be that we can add work_pending() tests to queue_work_on(). I *think* > that shouldn't break work scheduling semantics. Not completely sure > tho. Need to think about it more. I was confused a bit there. We can't. Nothing guarantees that the queuer sees the cleared PENDING before the work item starts execution, and I think ipc memory hotplug could also be broken from that. It's highly unlikely to actually happen and there may be external locking which prevents the race from actually happening, but there's nothing synchronizing queueing and the execution of the work item. Looking at that part of code only, it's possible that it fails to queue the work item after a memory hotplug event even though the previous queueing already started execution and processed a couple notifiers. And you can see why you don't want this type of tricky micro optimizations unless it's absolutely necessary and carefully considered. Cold paths get much less attention and testing. Adding micro optimizations to them is just a bad idea. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 00/27] x86, boot, 64bit: Add support for loading ramdisk and bzImage above 4G
On Mon, Dec 24, 2012 at 2:04 AM, Borislav Petkov wrote: > On Sun, Dec 23, 2012 at 08:54:37PM -0800, H. Peter Anvin wrote: >> Makes sense. Ljmpq it is. A comment might be useful. > > Yes, a LRETQ comment is definitely useful so that we know. Yinghai, > please add it the next time you're rebasing. Btw, which branch is the > current one for that patchset so that people can review and test it? for-x86-boot and it points to -v8 that does not break KGDB. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio_console: correct error message on failure of debugfs_create_dir
On Mon, Dec 24, 2012 at 01:24:52PM -0500, Sasha Levin wrote: > On Mon, Dec 24, 2012 at 12:39 PM, Greg Kroah-Hartman > wrote: > > On Mon, Dec 24, 2012 at 11:55:46AM +, Arnd Bergmann wrote: > >> On Friday 21 December 2012, Amit Shah wrote: > >> > On (Thu) 20 Dec 2012 [14:11:21], Sasha Levin wrote: > >> > > debugfs_create_dir() returns NULL if it fails, there's little point in > >> > > calling PTR_ERR on it. > >> > > >> > debugfs_create_dir() does return an error value if debugfs is not > >> > enabled. > >> > > >> > This check for !pdrvdata.debugfs_dir should infact use > >> > IS_ERR_OR_NULL(). Care to submit a patch for that? > >> > >> How about we fix the stub instead to return NULL when debugfs is disabled? > > > > No, please read debugfs.h for why I decided to not do this (i.e. we try > > to learn from our mistakes...) > > Why won't we fix it the other way around and return an actual error > code instead of a NULL on failure? Again, no, that doesn't make your code simpler/faster. You really don't need to check the return value of debugfs, just handle it as if it always works, and look, the code handles it all properly, no matter if debugfs is enabled or not. It's only debugging code, you shouldn't really care if it is present or not, right? If you do, perhaps you shouldn't be using debugfs? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 25/25] ipc: don't use [delayed_]work_pending()
Hello, Borislav. On Sat, Dec 22, 2012 at 12:09:29PM +0100, Borislav Petkov wrote: > Now you say those paths are not fast paths, but the reverse of > this optimization is also true: what happens if people start using > schedule_work() in fast paths without checking whether work is pending? > A useless IRQ disable + locked operation + IRQ enable. That's a really strange argument. If we extend from that, we have to optimize cold paths to prevent fast paths copy from them, which sounds really silly to me. If one looks at something happening in a path as cold as memory hotplug and thinks about optimizing a coupld memory accesses, the person's priorities need serious reconsideration. I think approaches like that are actively harmful. They lead to unnecessary (and thus difficult to comprehend) convolutions which don't really help anything while deteoriorating code base. I don't think we have cases where this actually matters but it could be that we can add work_pending() tests to queue_work_on(). I *think* that shouldn't break work scheduling semantics. Not completely sure tho. Need to think about it more. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio_console: correct error message on failure of debugfs_create_dir
On Mon, Dec 24, 2012 at 12:39 PM, Greg Kroah-Hartman wrote: > On Mon, Dec 24, 2012 at 11:55:46AM +, Arnd Bergmann wrote: >> On Friday 21 December 2012, Amit Shah wrote: >> > On (Thu) 20 Dec 2012 [14:11:21], Sasha Levin wrote: >> > > debugfs_create_dir() returns NULL if it fails, there's little point in >> > > calling PTR_ERR on it. >> > >> > debugfs_create_dir() does return an error value if debugfs is not >> > enabled. >> > >> > This check for !pdrvdata.debugfs_dir should infact use >> > IS_ERR_OR_NULL(). Care to submit a patch for that? >> >> How about we fix the stub instead to return NULL when debugfs is disabled? > > No, please read debugfs.h for why I decided to not do this (i.e. we try > to learn from our mistakes...) Why won't we fix it the other way around and return an actual error code instead of a NULL on failure? Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 17/25] wm97xx: don't use [delayed_]work_pending()
Hello, Dmitry. On Sun, Dec 23, 2012 at 01:54:50AM -0800, Dmitry Torokhov wrote: > This is not 100% equivalent transformation as now we schedule first and > disable IRQ later... Anyway, I think the driver shoudl be converted to > threaded IRQ instead. Mark, does the patch below make any sense to you? Yeah, I think the conversion is actually broken. There isn't anything which prevents work item execution racing against irq disabling. I agree the right thing to do is using threaded irq handler. Thanks! -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] namei.h: include errno.h
This solves: In file included from fs/ext3/symlink.c:20:0: include/linux/namei.h: In function 'retry_estale': include/linux/namei.h:114:19: error: 'ESTALE' undeclared (first use in this function) Signed-off-by: Stephen Warren --- include/linux/namei.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/namei.h b/include/linux/namei.h index e998c03..5a5ff57 100644 --- a/include/linux/namei.h +++ b/include/linux/namei.h @@ -2,6 +2,7 @@ #define _LINUX_NAMEI_H #include +#include #include #include -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] output the cpu number when printking.
On Mon, Dec 24, 2012 at 01:01:55PM +0800, he, bo wrote: > From: "he, bo" > > We often hit kernel panic issues on SMP machines because processes race > on multiple cpu. By adding a new parameter printk.cpu, kernel prints > cpu number at printk information line. It’s useful to debug what cpus > are racing. How useful is this really for normal developers? We complained when this option was proposed by the ARM developers who were, for the first time, handling more than one processor and the issues involved with that. You are enabling this as a default option, for all developers, and almost no one will ever need it. So, if you really want this, don't enable this by default. Also, go back and read the old thread about this option and why it was rejeted previously. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: debug clock tree
On Sun, Dec 23, 2012 at 4:26 AM, Prashant Gaikwad wrote: > On Saturday 22 December 2012 04:26 AM, Mike Turquette wrote: >> >> On Wed, Dec 19, 2012 at 11:53 PM, Prashant Gaikwad >> wrote: >>> >>> On Thursday 13 December 2012 11:31 PM, Stephen Warren wrote: On 12/13/2012 09:27 AM, Mike Turquette wrote: > > On Wed, Dec 12, 2012 at 7:49 PM, Prashant Gaikwad > wrote: >> >> Adds debug file "clock_tree" in /sys/kernel/debug/clk dir. >> It helps to view all the clock registered in tree format. >> > Prashant, > > Thanks for submitting this. We've been talking about having a single > file for representing the tree for some time. > > Regarding the output format had you considered using a well known > format which can be parsed using well known parsing libs? This avoids > needing a custom parser just for this one file. JSON springs to mind > as something lightweight and well-understood. One advantage of the format below is that it's very easily human-readable, and it's not too hard to parse (although I guess you'd have to parse the indent level to get parent/child relation, which would suck a bit). Is there room to provide both? Otherwise, I guess the kernel could include a script to convert from JSON/whatever into the format below. >> For example: >> clockenable_cnt prepare_cnt rate >> - >>i2s0_sync 0 02400 >>spdif_in_sync 0 02400 >> spdif_mux 0 02400 >> spdif0 02400 >> spdif_doubler 0 04800 >>spdif_div 0 04800 >> spdif_2x0 04800 >>> Even I think that output must be easily human-readable. How about adding >>> sysfs to switch between human-readable and machine-readable format? >>> I will try come up with a implementation. >>> >> Do you mean a sysfs file which controls the output format? How about >> just two different files? One can be clk-dump (machine readable) and >> the other is clk-summary (human readable). > > > It is also fine. Is this patch ok for human-readable format? or any > suggestions? > I will change the file name to clk-summary. > Prashant, Yes the format seems to be agreeable for human-readable format based on the feedback on the list. Go ahead and keep the column titles and the dashed lines that I commented on earlier... my comments are less relevant if a separate machine-readable clk-dump file exists. Are you going to take a crack at JSON-formatted output for clk-dump? Thanks, Mike >> >> Regards, >> Mike > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio_console: correct error message on failure of debugfs_create_dir
On Mon, Dec 24, 2012 at 11:55:46AM +, Arnd Bergmann wrote: > On Friday 21 December 2012, Amit Shah wrote: > > On (Thu) 20 Dec 2012 [14:11:21], Sasha Levin wrote: > > > debugfs_create_dir() returns NULL if it fails, there's little point in > > > calling PTR_ERR on it. > > > > debugfs_create_dir() does return an error value if debugfs is not > > enabled. > > > > This check for !pdrvdata.debugfs_dir should infact use > > IS_ERR_OR_NULL(). Care to submit a patch for that? > > How about we fix the stub instead to return NULL when debugfs is disabled? No, please read debugfs.h for why I decided to not do this (i.e. we try to learn from our mistakes...) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] signalfd: add ability to choose a private or shared queue
On 12/24, Andrey Vagin wrote:
>
> static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, siginfo_t *info,
> - int nonblock)
> + int nonblock, int queue)
> {
> ssize_t ret;
> DECLARE_WAITQUEUE(wait, current);
>
> spin_lock_irq(>sighand->siglock);
> - ret = dequeue_signal(current, >sigmask, info);
> + ret = do_dequeue_signal(current, >sigmask, info, queue);
Hmm. queue != 0 && !nonblock ?
And in this case you should also update signalfd_poll().
> + if (file->f_flags & SFD_GROUP)
> + queue++;
> +
> + if (file->f_flags & SFD_PRIVATE)
> + queue--;
To be honest, personally I think this looks ugly. If you add an
argumemt to dequeue_signal() it would be better to use bitmask.
But this is minor.
Well. Perhaps we can avoid all these complications? IIUC, all you
need is to know if the dequeued signal is private or shared. Since
you add SFD_RAW anyway perhaps we can report this fact instead?
This doesn't need any changes in signal.c, signalfd_dequeue() can
easily know which queue dequeue_signal() will use.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] signalfd: add ability to return siginfo in a raw format
On 12/24, Andrey Vagin wrote:
>
> signalfd should be called with the flag SFD_RAW for that.
>
> signalfd_siginfo is not full for siginfo with a negative si_code.
> copy_siginfo_to_user() is copied a full siginfo to user-space, if
> si_code is negative. signalfd_copyinfo() doesn't do that and can't be
> expanded, because it has not compatiable format with siginfo_t.
Yes, but otoh perhaps we should change (fix) signalfd_siginfo/copyinfo,
its "default" case makes no sense if si_code < 0.
> Another problem is that a constant __SI_* is removed from si_code.
OK, so you add the additional put_user(kinfo->si_code). Again, in
this case we can extend signalfd_siginfo perhaps...
Anyway, the patch doesn't look right.
> +static int signalfd_copy_raw_info(struct signalfd_siginfo __user *siginfo,
> + siginfo_t *kinfo)
> +{
> + siginfo_t *uinfo = (siginfo_t *) siginfo;
> + int err;
> +
> + BUILD_BUG_ON(sizeof(siginfo_t) != sizeof(struct signalfd_siginfo));
> +
> + err = __clear_user(uinfo, sizeof(*uinfo));
> + err |= copy_siginfo_to_user(uinfo, kinfo);
This probably needs copy_siginfo_to_user32() if is_compat_task...
> + err |= __put_user(kinfo->si_code, >si_code);
__put_user() is not safe? This allows to write to the kernel memory.
> @@ -286,6 +308,11 @@ SYSCALL_DEFINE4(signalfd4, int, ufd, sigset_t __user *,
> user_mask,
> O_RDWR | (flags & (O_CLOEXEC |
> O_NONBLOCK)));
> if (ufd < 0)
> kfree(ctx);
> + else if (flags & SFD_RAW) {
> + struct fd f = fdget(ufd);
> + f.file->f_flags |= flags & SFD_RAW;
Well, but this is racy. How we can know that fdget(ufd) still
points to the same file created by anon_inode_getfd? Not to
mention f.file can be NULL.
Another CLONE_FILES thread can do close() right after fd_install().
And it can also do dup3().
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/11] ARM: delete struct sys_timer
On 11/19/2012 11:30 AM, Stephen Warren wrote: > Russell, I'm mainly reposting this to see if you have any comments or > opinion, in particular on the core ARM changes. > > The aim of this series is to remove ARM's struct sys_timer. As a pre- > cursor, this requires a little re-arrangement of arch_gettimeoffset and > associated changes to other architectures. > > The full series can be found in git at: (now at): git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git arm-timer-rework I have put this branch into the Tegra tree's for-next branch. Once the holidays are over, I'll send a pull request to get this into arm-soc as a baseline branch for others to build on. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: twl: Convert twl[6030|4030]fixed_ops to regulator_list_voltage_linear
On Sat, Dec 22, 2012 at 01:31:19PM +0800, Axel Lin wrote: > Signed-off-by: Axel Lin Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 1/4] regulator: core: Allow specify apply_[reg|bit] for regmap based voltage_sel operations
On Tue, Dec 18, 2012 at 09:30:10AM +0800, Axel Lin wrote: > Some DVM regulators needs to update apply_bit after setting vsel_reg to > initiate voltage change on the output. This patch adds apply_reg and Applied all except patch 2 (where you've done a new version, I'll wait for Haojian to ack though) - thanks! signature.asc Description: Digital signature
Re: [PATCH v2] regulator: new driver for LP8755
On Mon, Dec 17, 2012 at 10:24:06AM +0900, Daniel Jeong wrote: > This patch is for new lp8755 regulator dirver and > several unsed variables were deleted and then test was done. Applied, thanks. signature.asc Description: Digital signature
Porting problem: ndo_set_multicast_list removed
Hi, list
I am porting an ethernet driver from 2.6.x to 3.7.1. I found in the new
kernel, the ndo_set_multicast_list method in the net_device_ops had been
removed. What's the story behind? Can I simply ignore this method
defined in an old driver?
Please also help to check the below code, is the list of the operations
defined for my driver enough or not?
const struct net_device_ops ax_netdev_ops = {
.ndo_open = mydriver_open,
.ndo_stop = mydriver_close,
.ndo_start_xmit = mydriver_start_xmit,
.ndo_get_stats = mydriver_get_stats,
/*.ndo_set_multicast_list = mydriver_set_multicast_list,*/
.ndo_set_mac_address= mydriver_set_mac_address,
};
Thanks in advance.
--
woody
I can't go back to yesterday - because I was a different person then.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC/RFT] regulator: core: Fix continuous_voltage_range case in regulator_can_change_voltage
On Wed, Dec 12, 2012 at 09:22:46AM +0800, Axel Lin wrote: > Regulator drivers with continuous_voltage_range flag set allows not setting > n_voltages. Thus if continuous_voltage_range is set, check the constraint > range > instead. Applied, thanks. signature.asc Description: Digital signature
[PATCH 2/2] mfd: max77693: Init max77693->dev before using it
Current code uses max77693->dev in the dev_err call before setting it to
>dev. Fix it.
This patch also includes below cleanups:
- Move checking pdata earlier and show dev_err if no platform data found.
- Remove unnecessary err_regmap goto label.
- Unregister i2c devices if regmap init for muic fails.
Signed-off-by: Axel Lin
---
drivers/mfd/max77693.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index cc5155e..9e60fed 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -114,35 +114,37 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
u8 reg_data;
int ret = 0;
+ if (!pdata) {
+ dev_err(>dev, "No platform data found.\n");
+ return -EINVAL;
+ }
+
max77693 = devm_kzalloc(>dev,
sizeof(struct max77693_dev), GFP_KERNEL);
if (max77693 == NULL)
return -ENOMEM;
- max77693->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
- if (IS_ERR(max77693->regmap)) {
- ret = PTR_ERR(max77693->regmap);
- dev_err(max77693->dev,"failed to allocate register map: %d\n",
- ret);
- goto err_regmap;
- }
-
i2c_set_clientdata(i2c, max77693);
max77693->dev = >dev;
max77693->i2c = i2c;
max77693->irq = i2c->irq;
max77693->type = id->driver_data;
- if (!pdata)
- goto err_regmap;
+ max77693->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
+ if (IS_ERR(max77693->regmap)) {
+ ret = PTR_ERR(max77693->regmap);
+ dev_err(max77693->dev, "failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
max77693->wakeup = pdata->wakeup;
- if (max77693_read_reg(max77693->regmap,
- MAX77693_PMIC_REG_PMIC_ID2, _data) < 0) {
+ ret = max77693_read_reg(max77693->regmap, MAX77693_PMIC_REG_PMIC_ID2,
+ _data);
+ if (ret < 0) {
dev_err(max77693->dev, "device not found on this channel\n");
- ret = -ENODEV;
- goto err_regmap;
+ return ret;
} else
dev_info(max77693->dev, "device ID: 0x%x\n", reg_data);
@@ -163,7 +165,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
ret = PTR_ERR(max77693->regmap_muic);
dev_err(max77693->dev,
"failed to allocate register map: %d\n", ret);
- goto err_regmap;
+ goto err_regmap_muic;
}
ret = max77693_irq_init(max77693);
@@ -184,9 +186,9 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
err_mfd:
max77693_irq_exit(max77693);
err_irq:
+err_regmap_muic:
i2c_unregister_device(max77693->muic);
i2c_unregister_device(max77693->haptic);
-err_regmap:
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] regulator: lp3972: Convert to get_voltage_sel
On Mon, Dec 10, 2012 at 07:50:12PM +0800, Axel Lin wrote: > regulator_list_voltage_table() returns -EINVAL if selector >= n_voltages. > Thus we don't need to check if reg is greater than LP3972_BUCK_VOL_MAX_IDX in > lp3972_dcdc_get_voltage_sel. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 1/2] regulator: lp3971: Convert to get_voltage_sel
On Mon, Dec 10, 2012 at 07:46:52PM +0800, Axel Lin wrote: > regulator_list_voltage_table() returns -EINVAL if selector >= n_voltages. > Thus we don't need to check if reg is greater than BUCK_TARGET_VOL_MAX_IDX in > lp3971_dcdc_get_voltage_sel. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] regulator: s5m8767: Fix probe failure due to stack corruption
On Wed, Dec 12, 2012 at 08:57:00AM +0530, Inderpal Singh wrote: > The function sec_reg_read invokes regmap_read which expects unsigned int * > as the destination address. The existing driver is passing address of local > variable "val" which is u8. This causes the stack corruption and following > dump is observed during probe. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] regmap: irq: enable wake support by default
On Wed, Dec 19, 2012 at 07:42:28PM +0530, Laxman Dewangan wrote: > regmap-irq framework is used vastly by mfd drivers and some of > devices like TPS65910, TPS80036 do not support the wake base > register to enable wake. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 17/25] wm97xx: don't use [delayed_]work_pending()
On Sun, Dec 23, 2012 at 01:54:50AM -0800, Dmitry Torokhov wrote: > This is not 100% equivalent transformation as now we schedule first and > disable IRQ later... Anyway, I think the driver shoudl be converted to > threaded IRQ instead. Mark, does the patch below make any sense to you? I'm a bit nervous about the fact that currently both the pen down IRQ and the coordinate read are pushed through a single workqueue so are serialised but after your patch they'll be split into the IRQ thread and the workqueue. It *should* be fine but I'd have to sit there and study it to convince myself that it's safe. signature.asc Description: Digital signature
[PATCH 1/2] mfd: max77686: Init max77686->dev before using it
Current code uses max77686->dev in the dev_err call before setting it to
>dev. Fix it.
Signed-off-by: Axel Lin
---
drivers/mfd/max77686.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
index f6878f8..4d73963 100644
--- a/drivers/mfd/max77686.c
+++ b/drivers/mfd/max77686.c
@@ -93,15 +93,6 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
if (max77686 == NULL)
return -ENOMEM;
- max77686->regmap = regmap_init_i2c(i2c, _regmap_config);
- if (IS_ERR(max77686->regmap)) {
- ret = PTR_ERR(max77686->regmap);
- dev_err(max77686->dev, "Failed to allocate register map: %d\n",
- ret);
- kfree(max77686);
- return ret;
- }
-
i2c_set_clientdata(i2c, max77686);
max77686->dev = >dev;
max77686->i2c = i2c;
@@ -111,6 +102,15 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
max77686->irq_gpio = pdata->irq_gpio;
max77686->irq = i2c->irq;
+ max77686->regmap = regmap_init_i2c(i2c, _regmap_config);
+ if (IS_ERR(max77686->regmap)) {
+ ret = PTR_ERR(max77686->regmap);
+ dev_err(max77686->dev, "Failed to allocate register map: %d\n",
+ ret);
+ kfree(max77686);
+ return ret;
+ }
+
if (regmap_read(max77686->regmap,
MAX77686_REG_DEVICE_ID, ) < 0) {
dev_err(max77686->dev,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/25] sound/wm8350: don't use [delayed_]work_pending()
On Fri, Dec 21, 2012 at 05:57:03PM -0800, Tejun Heo wrote: > There's no need to test whether a (delayed) work item in pending > before queueing, flushing or cancelling it. Most uses are unnecessary > and quite a few of them are buggy. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 7/7] MFD:rtsx: Fix checkpatch warning
On Mon, Dec 24, 2012 at 02:03:56PM +0800, wei_w...@realsil.com.cn wrote:
> From: Wei WANG
>
> WARNING: Avoid CamelCase:
> + u8 N, min_N, max_N, clk_divider;
>
> WARNING: Avoid CamelCase:
> + u8 N, min_N, max_N, clk_divider;
>
> Signed-off-by: Wei WANG
> ---
> drivers/mfd/rtsx_pcr.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
> index cc28f17..f843c73 100644
> --- a/drivers/mfd/rtsx_pcr.c
> +++ b/drivers/mfd/rtsx_pcr.c
> @@ -590,7 +590,7 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
> int card_clock,
> u8 ssc_depth, bool initial_mode, bool double_clk, bool vpclk)
> {
> int err, clk;
> - u8 N, min_N, max_N, clk_divider;
> + u8 n, min_n, max_n, clk_divider;
> u8 mcu_cnt, div, max_div;
> u8 depth[] = {
> [RTSX_SSC_DEPTH_4M] = SSC_DEPTH_4M,
> @@ -615,8 +615,8 @@ int rtsx_pci_switch_clock(struct rtsx_pcr *pcr, unsigned
> int card_clock,
> card_clock /= 100;
> dev_dbg(&(pcr->pci->dev), "Switch card clock to %dMHz\n", card_clock);
>
> - min_N = 80;
> - max_N = 208;
> + min_n = 80;
> + max_n = 208;
Naked magic values? Maybe macro defines with descriptive names instead?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How kernel handle interrupts[AX88796B network controller]
On Mon, Dec 24, 2012 at 10:10:17PM +0800, Woody Wu wrote: > On Fri, Dec 21, 2012 at 01:33:03PM -0800, anish kumar wrote: > > On Fri, 2012-12-21 at 23:34 +0800, Woody Wu wrote: > > > On Thu, Dec 20, 2012 at 10:05:05AM -0800, anish singh wrote: > > > > On Dec 20, 2012 6:30 AM, "Woody Wu" wrote: > > > > > > > > > > Hi, List > > > > > > > > > > Where is the Kernel code that handles external interrupts? I want to > > > > > have a look at it but haven't found out where it is. > > > > > > > > > > Actually, I have some basic questions about interrupt handling in > > > > > Linux. > > > > > 1. After Kernel's ISR received an interrupt, I believe it will invoke > > > > > a > > > > >handler defined in a device driver if any. But it should be the > > > > >device driver's responsibility or kernel ISR's responsibility to > > > > >clear (or acknowledge) the interrupt? > > > > If the interrupt in question is currently being handled then in > > > > the case of edge triggered interrupt we just mask the interrupt,set it > > > > pending and bail out.Once the interrupt handler completes then we check > > > > for > > > > pending interrupt and handle it.In level triggered we don't do that. > > > > Kerenel ISR -this is mixture of core kernel interrupt handling code + > > > > your > > > > device driver interrupt handler(if this is chip driver which is > > > > supposed to > > > > get one interrupt and is reponsible for calling other interrupt handlers > > > > based on the chip register status then you do explicit masking unmasking > > > > yourself). > > > > If you device driver is a interrupt controller driver then you register > > > > your driver with kernel interrupt handling code and need to write some > > > > callbacks such as .mask,.unmask and so on.This callbacks are called at > > > > appropiate places whenever the interrupt is raised.This interrupt is > > > > then > > > > passed to drivers who has requested for this interrupt by calling > > > > request_irq. > > > > > > > > > > 2. My device, an AX88796B network controller, asserting the interrupt > > > > >line in a level-triggered manner. Now I met problem with the device > > > > that > > > > >might caused by the CPU interrupt mode is not set as > > > > > level-triggered by > > > > >edge trigger. My CPU is Samsung S3C2410, an ARM920T powered one. > > > > > Does > > > > >anyone know usually where and how should I do this kind of setting? > > > > Just pass the parameter "level triggered" in request_irq in your device > > > > driver. > > > > > > Hi Sign, > > > > > > I searched the interrupt.h for the all the defined flags that I can pass > > > to the request_irq, but there is no a flag looks like "level triggered". > > > Would you tell me what you mean the parameter "level triggered"? > > irq_set_irq_type(info->irq, IRQ_TYPE_LEVEL_LOW) > > > > include/linux/irq.h > > IRQ_TYPE_LEVEL_HIGH - high level triggered > > IRQ_TYPE_LEVEL_LOW - low level triggered > > Thanks. You saved my ass. > > Be curious, I found the api changes from 2.6 to 3.7. In 2.6, there are > pair of funtions, set_irq_type and set_irq_handle (there is no > irq_set_irq_type in 2.6). Problem is, I cannot find something like > irq_set_irq_handle in 3.7. Does that mean, in 3.7, when > irq_set_irq_type is changed, the associated flow handler is also > changed? In my case, the interrupt was originally assgined with a edge > flow handler and set type as edge irq. After I, by invoking > irq_set_irq_type, change it to level irq, I think the flow handler > should also be changed to a level handle. Is that happened > automatically behind? I search through the code, but did not find where > is it. Make it simple, is it necessary to also change the irq flow handler after changed a irq type (from edge to level)? Is yes, what's the public api that let user change flow handler for an irq? Thanks in advance. > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > Thanks in advance. > > > > > > > > > > -- > > > > > woody > > > > > I can't go back to yesterday - because I was a different person then. > > > > > > > > > > ___ > > > > > Kernelnewbies mailing list > > > > > kernelnewb...@kernelnewbies.org > > > > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > > > -- > woody > I can't go back to yesterday - because I was a different person then. -- woody I can't go back to yesterday - because I was a different person then. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v4 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
On 12/23/2012 10:12 PM, Oleg Nesterov wrote:
> On 12/23, Srivatsa S. Bhat wrote:
>>
>> On 12/20/2012 07:12 PM, Oleg Nesterov wrote:
>>>
>>> We need mb() + rmb(). Plust cli/sti unless this arch has optimized
>>> this_cpu_add() like x86 (as you pointed out).
>>>
>>
>> Hey, IIUC, we actually don't need mb() in the reader!! Just an rmb() will do.
>
> Well. I don't think so. But when it comes to the barriers I am never sure
> until Paul confirms my understanding ;)
>
>> #define reader_nested_percpu()
>> \
>> (__this_cpu_read(reader_percpu_refcnt) & READER_REFCNT_MASK)
>>
>> #define writer_active()
>> \
>> (__this_cpu_read(writer_signal))
>>
>>
>> #define READER_PRESENT (1UL << 16)
>> #define READER_REFCNT_MASK (READER_PRESENT - 1)
>>
>> void get_online_cpus_atomic(void)
>> {
>> preempt_disable();
>>
>> /*
>> * First and foremost, make your presence known to the writer.
>> */
>> this_cpu_add(reader_percpu_refcnt, READER_PRESENT);
>>
>> /*
>> * If we are already using per-cpu refcounts, it is not safe to switch
>> * the synchronization scheme. So continue using the refcounts.
>> */
>> if (reader_nested_percpu()) {
>> this_cpu_inc(reader_percpu_refcnt);
>> } else {
>> smp_rmb();
>> if (unlikely(writer_active())) {
>> ... //take hotplug_rwlock
>> }
>> }
>>
>> ...
>>
>> /* Prevent reordering of any subsequent reads of cpu_online_mask. */
>> smp_rmb();
>> }
>>
>> The smp_rmb() before writer_active() ensures that LOAD(writer_signal) follows
>> LOAD(reader_percpu_refcnt) (at the 'if' condition). And in turn, that load is
>> automatically going to follow the STORE(reader_percpu_refcnt)
>
> But why this STORE should be visible on another CPU before we
> LOAD(writer_signal)?
>
> Lets discuss the simple and artificial example. Suppose we have
>
> int X, Y;
>
> int func(void)
> {
> X = 1; // suppose that nobody else can change it
> mb();
> return Y;
> }
>
> Now you are saying that we can change it and avoid the costly mb():
>
> int func(void)
> {
> X = 1;
>
> if (X != 1)
> BUG();
>
> rmb();
> return Y;
> }
>
> I doubt. rmb() can only guarantee that the preceding LOAD's should be
> completed. Without mb() it is possible that this CPU won't write X to
> memory at all.
>
Oh, ok :-( Thanks for correcting me and for the detailed explanation!
For a moment, I really thought we had it solved at last! ;-(
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [B.A.T.M.A.N.] [PATCH] net, batman: don't crash on zero length strings in routing_algo
On Mon, Dec 24, 2012 at 3:38 PM, Marek Lindner wrote: > On Monday, December 24, 2012 22:18:52 Pau Koning wrote: >> On Mon, Nov 19, 2012 at 9:08 PM, Sasha Levin wrote: >> > The code that works with routing_algo assumes that the string passed is >> > non >> >> > empty, this assumption is wrong: >> Why isn't this patch part of Linux 3.7? It seems to be a bugfix and it >> was sent early enough? > > The patch received a reply mere 2 hours after it was sent. Again, please read > all mails before making noise. Ok, leaving this problem unsolved is the correct way to handle it? Nobody is allowed to say anything? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: core: giving WARN when device starting from non-off bias with idle_bias_off
On Fri, Dec 21, 2012 at 06:17:12PM +0800, Chuansheng Liu wrote: > > Just found some cases that some codec drivers set the bias to _STANDBY and > set idle_bias_off to 1 during probing. > It will cause unpaired runtime_get_sync/put() issue. Also as Mark suggested, > there is no reason to start from _STANDBY bias with idle_bias_off == 1. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] kvm: Fix memory slot generation updates
On Sun, 2012-12-23 at 10:55 +0200, Gleb Natapov wrote:
> On Fri, Dec 21, 2012 at 08:20:16AM -0700, Alex Williamson wrote:
> > Previous patch "kvm: Minor memory slot optimization" overlooked the
> > generation field of the memory slots. Re-using the original memory
> > slots left us with with two slightly different memory slots with the
> > same generation. To fix this, make update_memslots() take a new
> > parameter to specify the last generation. This also makes generation
> > management more explicit to avoid such problems in the future.
> >
> > Reported-by: Takuya Yoshikawa
> > Signed-off-by: Alex Williamson
> Applied, thanks. What about this small cleanup on to of the patch:
Nice cleanup
Reviewed-by: Alex Williamson
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 14cbae8..e45c20c 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -702,6 +702,17 @@ static int check_memory_region_flags(struct
> kvm_userspace_memory_region *mem)
> return 0;
> }
>
> +static struct kvm_memslots *install_new_memslots(struct kvm *kvm,
> + struct kvm_memslots *slots, struct kvm_memory_slot *new)
> +{
> + struct kvm_memslots *old_memslots = kvm->memslots;
> +
> + update_memslots(slots, new, kvm->memslots->generation);
> + rcu_assign_pointer(kvm->memslots, slots);
> + synchronize_srcu_expedited(>srcu);
> + return old_memslots;
> +}
> +
> /*
> * Allocate some memory and give it an address in the guest physical address
> * space.
> @@ -820,11 +831,8 @@ int __kvm_set_memory_region(struct kvm *kvm,
> slot = id_to_memslot(slots, mem->slot);
> slot->flags |= KVM_MEMSLOT_INVALID;
>
> - update_memslots(slots, NULL, kvm->memslots->generation);
> + old_memslots = install_new_memslots(kvm, slots, NULL);
>
> - old_memslots = kvm->memslots;
> - rcu_assign_pointer(kvm->memslots, slots);
> - synchronize_srcu_expedited(>srcu);
> /* slot was deleted or moved, clear iommu mapping */
> kvm_iommu_unmap_pages(kvm, );
> /* From this point no new shadow pages pointing to a deleted,
> @@ -868,10 +876,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
> memset(, 0, sizeof(new.arch));
> }
>
> - update_memslots(slots, , kvm->memslots->generation);
> - old_memslots = kvm->memslots;
> - rcu_assign_pointer(kvm->memslots, slots);
> - synchronize_srcu_expedited(>srcu);
> + old_memslots = install_new_memslots(kvm, slots, );
>
> kvm_arch_commit_memory_region(kvm, mem, old, user_alloc);
>
> --
> Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] drivers: mailbox: framework creation
Hi Omar, On Fri, Dec 21, 2012 at 9:33 PM, Omar Ramirez Luna wrote: > Yes, I made the changes, for tidspbridge and remoteproc, I will submit > both for review, based on this series. Great, thanks. Please note that when we do eventually merge this, we need your updates to be squashed into Loic's patches so we don't break bisectibility. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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, batman: don't crash on zero length strings in routing_algo
On Mon, Nov 19, 2012 at 9:08 PM, Sasha Levin wrote: > The code that works with routing_algo assumes that the string passed is non > empty, this assumption is wrong: Why isn't this patch part of Linux 3.7? It seems to be a bugfix and it was sent early enough? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [B.A.T.M.A.N.] [PATCH] net, batman: don't crash on zero length strings in routing_algo
On Monday, December 24, 2012 22:18:52 Pau Koning wrote: > On Mon, Nov 19, 2012 at 9:08 PM, Sasha Levin wrote: > > The code that works with routing_algo assumes that the string passed is > > non > > > empty, this assumption is wrong: > Why isn't this patch part of Linux 3.7? It seems to be a bugfix and it > was sent early enough? The patch received a reply mere 2 hours after it was sent. Again, please read all mails before making noise. Thanks, Marek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Suggestion] drivers/staging/tidspbridge: strcpy and strncpy, src length checking issue.
Hi Gchen, On Mon, Dec 17, 2012 at 8:40 PM, Chen Gang wrote: > Hello Omar Ramirez Luna: > > excuse me to bother you (maybe you are busy in these days). > please help checking this suggestion when you have free time. Yes, I'm checking your suggestions, I was a little busy last week, for the compile breaks I had a patch but I was waiting for them to show on staging 3.8-rc1. > By the way: > this week, I need work for 2 patches which relative with usb sub-system. > if still get no reply for tidspbridge until next week. > I should work for it, it is my duty (since I have provided 'suggestion' > to it). > "work for it" means: >if tidspbridge is still useful > I need construct relative environments for unit test. > then provide relative patches. >else (useless) > I need delete it from Open Source. > (since it can not pass compiling, and no response from *@ti.com, it > almost means useless) Please DON'T assume it's useless if you don't get replies from @ti.com . > (at least, fix the 2 compiling issues which I have suggested, can > pass compiling) Done. Cheers, Omar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Suggestion] drivers/staging/tidspbridge: pr_err and pr_debug for uninitialized buffer (name buf not initialized).
Hi, On Thu, Dec 13, 2012 at 7:30 PM, Chen Gang wrote: > also another suggestions: > I built ti otmap with ti dsp bridge by arm cross-compiler under i386 > platform. > the version tag is next-20121213 > I met 2 compiling issues. > > a: module dependency: > Multifunction device drivers --> Texas Instruments > TWL/4030/TWL5030 is required for TI OTMAP. > it need depend on CONFIG_REGMAP (maybe also inculde CONFIG_REGMAP*) > if CONFIG_REGMAP* not defined, building will be failed. This is not related to tidspbridge, I sent a patch anyway as it looks to be a valid build dependency bug. > b: version merging issue: > in drivers/staging/tidspbridge/core/_tiomap.h > need use "#include " instead of "#include > " > the macro OMAP3430_CM_AUTOIDLE_PLL has already move from > cm2xxx_3xxx.h to cm3xxx.h. > (it seems arch/arm/mach-omap2/ is not a suitable place for > including, but we have to) > if not change, compiling will be failed. Done. Cheers, Omar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: How kernel handle interrupts[AX88796B network controller]
On Fri, Dec 21, 2012 at 01:33:03PM -0800, anish kumar wrote: > On Fri, 2012-12-21 at 23:34 +0800, Woody Wu wrote: > > On Thu, Dec 20, 2012 at 10:05:05AM -0800, anish singh wrote: > > > On Dec 20, 2012 6:30 AM, "Woody Wu" wrote: > > > > > > > > Hi, List > > > > > > > > Where is the Kernel code that handles external interrupts? I want to > > > > have a look at it but haven't found out where it is. > > > > > > > > Actually, I have some basic questions about interrupt handling in Linux. > > > > 1. After Kernel's ISR received an interrupt, I believe it will invoke a > > > >handler defined in a device driver if any. But it should be the > > > >device driver's responsibility or kernel ISR's responsibility to > > > >clear (or acknowledge) the interrupt? > > > If the interrupt in question is currently being handled then in > > > the case of edge triggered interrupt we just mask the interrupt,set it > > > pending and bail out.Once the interrupt handler completes then we check > > > for > > > pending interrupt and handle it.In level triggered we don't do that. > > > Kerenel ISR -this is mixture of core kernel interrupt handling code + your > > > device driver interrupt handler(if this is chip driver which is supposed > > > to > > > get one interrupt and is reponsible for calling other interrupt handlers > > > based on the chip register status then you do explicit masking unmasking > > > yourself). > > > If you device driver is a interrupt controller driver then you register > > > your driver with kernel interrupt handling code and need to write some > > > callbacks such as .mask,.unmask and so on.This callbacks are called at > > > appropiate places whenever the interrupt is raised.This interrupt is then > > > passed to drivers who has requested for this interrupt by calling > > > request_irq. > > > > > > > > 2. My device, an AX88796B network controller, asserting the interrupt > > > >line in a level-triggered manner. Now I met problem with the device > > > that > > > >might caused by the CPU interrupt mode is not set as level-triggered > > > > by > > > >edge trigger. My CPU is Samsung S3C2410, an ARM920T powered one. > > > > Does > > > >anyone know usually where and how should I do this kind of setting? > > > Just pass the parameter "level triggered" in request_irq in your device > > > driver. > > > > Hi Sign, > > > > I searched the interrupt.h for the all the defined flags that I can pass > > to the request_irq, but there is no a flag looks like "level triggered". > > Would you tell me what you mean the parameter "level triggered"? > irq_set_irq_type(info->irq, IRQ_TYPE_LEVEL_LOW) > > include/linux/irq.h > IRQ_TYPE_LEVEL_HIGH - high level triggered > IRQ_TYPE_LEVEL_LOW - low level triggered Thanks. You saved my ass. Be curious, I found the api changes from 2.6 to 3.7. In 2.6, there are pair of funtions, set_irq_type and set_irq_handle (there is no irq_set_irq_type in 2.6). Problem is, I cannot find something like irq_set_irq_handle in 3.7. Does that mean, in 3.7, when irq_set_irq_type is changed, the associated flow handler is also changed? In my case, the interrupt was originally assgined with a edge flow handler and set type as edge irq. After I, by invoking irq_set_irq_type, change it to level irq, I think the flow handler should also be changed to a level handle. Is that happened automatically behind? I search through the code, but did not find where is it. > > > > Thanks. > > > > > > > > > > > > > > Thanks in advance. > > > > > > > > -- > > > > woody > > > > I can't go back to yesterday - because I was a different person then. > > > > > > > > ___ > > > > Kernelnewbies mailing list > > > > kernelnewb...@kernelnewbies.org > > > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > -- woody I can't go back to yesterday - because I was a different person then. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Revert "perf: Require exclude_guest to use PEBS - kernel side enforcement"
On Sat, Dec 22, 2012 at 12:21:23PM -0700, David Ahern wrote: > On 12/19/12 8:07 AM, Jiri Olsa wrote: > >This reverts commit 20b279ddb38ca42f8863cec07b4d45ec24589f13. > > > >Cc: Corey Ashford > >Cc: Frederic Weisbecker > >Cc: Ingo Molnar > >Cc: Namhyung Kim > >Cc: Paul Mackerras > >Cc: Peter Zijlstra > >Cc: Arnaldo Carvalho de Melo > > As a courtesy please CC people involved in a commit on any revert request. > > Arnaldo: please do not take this patch; I have proposed an > alternative. Just waiting to hear back on its acceptability. > > David this one was not meant to be applied.. just wanted the precise to work, so I could test other stuff.. I did mention that in: [RFC 0/3] perf tests: Adding precise event attribute test --- I based this on revert (Patch 1) discussed in [1]. I'm not sure this revert will tak place at the end, but I wanted to get some feedback on the 'precise' attribute first. ... [1] http://marc.info/?l=linux-kernel=135536724805356=2 --- jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
