[PROBLEM] interrupt 24 happens
Hi, Recently, when I trying to destroy a virtual machine, I came across a panic. The stack is listed at the end of this mail. After analyze, I think it is a problem of cpu, it generate an interrupt of vector 24. SS/ESP/EFLAGS/CS/RIP are push into stack. and EFLAGS is changed from 0x286 to 0x10086, IF is cleared. And the interrupt came after "HLT" (native_safe_halt+0x6/0x10) RIP is 81aa00d8, which is set to vector 24 during boot, but then freed. I would like to confirm if it is the problem of kernel or CPU. Could anyone give some help? P.S. The problem happened on a machine with: CPU: Intel(R) Xeon(R) CPU E5-2658 v4 @ 2.30GHz Memory: Micron 36ASF2G72PZ-2G1A2 DDR4 2133 MHz -- [681483.002217] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [681483.010107] BUG: unable to handle kernel paging request at 81aa00d8 [681483.017338] IP: [] early_idt_handlers+0xd8/0x120 [681483.023790] PGD 195d067 PUD 195e063 PMD 3fcdcca063 PTE 81aa0163 [681483.030716] Oops: 0011 [#1] SMP [681483.072006] Modules linked in: vfat fat loop scsi_transport_iscsi sch_htb 8021q garp stp mrp llc xt_multiport xt_conntrack iptable_filter ip6table_filter ip6_tables softdog dev_connlimit(O) binfmt_misc bum(O) ip_set nfnetlink prio(O) nat(O) vport_vxlan(O) openvswitch(O) nf_defrag_ipv6 gre ib_uverbs(OVE) kboxdriver(O) kbox(O) hotpatch(OE) pmcint(O) signo_catch(O) ipmi_devintf ipmi_si uio ipmi_msghandler bonding mlx4_ib(OVE) mlx4_en(OVE) ib_sa(OVE) ib_mad(OVE) ib_core(OVE) ib_addr(OVE) ib_netlink(OVE) kvm_intel(O) kvm(O) ixgbe(O) coretemp intel_rapl crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw gf128mul mlx4_core(OVE) vxlan ip6_udp_tunnel udp_tunnel ptp pps_core dca glue_helper ablk_helper cryptd pcspkr mei_me compat(OVE) lpc_ich mfd_core sb_edac edac_core i2c_i801 i2c_core mei acpi_power_meter [681483.146336] sg shpchp vhost_net(O) tun(O) vhost(O) macvtap macvlan nf_nat_proto_sctp nf_nat ip_tables ext3 mbcache jbd sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common ahci libahci mpt3sas libata raid_class scsi_transport_sas dm_mod nf_conntrack_ipv4 nf_defrag_ipv4 vfio_pci irqbypass vfio_iommu_type1 vfio xt_sctp nf_conntrack_proto_sctp nf_conntrack sctp libcrc32c [last unloaded: nxup] [681483.182672] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE V--- 3.10.0-327.36.58.10_2.x86_64 #1 [681483.200539] task: 81961440 ti: 8194c000 task.ti: 8194c000 [681483.208428] RIP: 0010:[] [] early_idt_handlers+0xd8/0x120 [681483.217410] RSP: 0018:8194fe78 EFLAGS: 00010086 [681483.222968] RAX: ffed RBX: 8194c000 RCX: 0100 [681483.230510] RDX: RSI: RDI: 0046 [681483.238050] RBP: 8194fea0 R08: R09: 0002 [681483.245540] R10: R11: R12: [681483.256972] R13: 8194c000 R14: 8194c000 R15: 8194ffa8 [681483.264519] FS: () GS:881fffa0() knlGS: [681483.273007] CS: 0010 DS: ES: CR0: 80050033 [681483.278993] CR2: 81aa00d8 CR3: 001fc77b7000 CR4: 003427f0 [681483.286530] DR0: DR1: DR2: [681483.294077] DR3: DR6: fffe0ff0 DR7: 0400 [681483.301613] Stack: [681483.303853] 81058ee6 0010 0286 8194fea0 [681483.311725] 0018 8194fec0 8101dd6f 8194c000 [681483.319588] 81a79a20 8194fed0 8101e686 8194ff28 [681483.327456] Call Trace: [681483.330164] [] ? native_safe_halt+0x6/0x10 [681483.336162] [] default_idle+0x1f/0xc0 [681483.341725] [] arch_cpu_idle+0x26/0x30 [681483.347346] [] cpu_startup_entry+0x245/0x290 [681483.353521] [] rest_init+0x7c/0x80 [681483.358816] [] start_kernel+0x429/0x44a [681483.364551] [] ? repair_env_string+0x5c/0x5c [681483.370716] [] ? early_idt_handlers+0x120/0x120 [681483.377130] [] x86_64_start_reservations+0x2a/0x2c [681483.383812] [] x86_64_start_kernel+0x152/0x175 [681483.390117] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [681483.410777] RIP [] early_idt_handlers+0xd8/0x120 [681483.417312] RSP [681483.421047] CR2: 81aa00d8 [681483.425086] ---[ end trace c26409feeec75903 ]--- -- -- Regards NuoHan Qiao
Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block
Oleksij, Am 09.05.2017 um 07:52 schrieb Oleksij Rempel: >> >> If VFS maintainers are fine with that, I'll take it. >> From UBIFS' POV it does not matter much. :-) >> >> >> Ping to VFS maintainers? >> >> >> What ping? Al made it clear that a flag is not needed. >> BTW, xfs s_uuid patch was merged to master. > > > I'm talking about ubifs patch. Then we can queue this patch for 4.13. Please resend and make sure it addresses everything what was also suggested for the xfs s_uuid patch. Thanks, //richard
[tip:timers/urgent] clocksource/arm_arch_timer: Fix arch_timer_mem_find_best_frame()
Commit-ID: f63d947c1673930bfc5f2f9bd1073a02c179a890
Gitweb: http://git.kernel.org/tip/f63d947c1673930bfc5f2f9bd1073a02c179a890
Author: Sudeep Holla
AuthorDate: Mon, 8 May 2017 13:32:27 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 9 May 2017 08:56:41 +0200
clocksource/arm_arch_timer: Fix arch_timer_mem_find_best_frame()
arch_timer_mem_find_best_frame() looks through ARCH_TIMER_MEM_MAX_FRAMES
frames even after finding matches to ensure the best frame is chosen,
which means the variable frame will point to the last valid frame but
not necessarily the best frame.
On Juno, we get the following error as the wrong frame is returned as the
best frame from arch_timer_mem_find_best_frame():
arch_timer: Unable to map frame @ 0x
arch_timer: Frame missing phys irq.
Failed to initialize '/timer@2a81': -22
Fix the issue by correctly returning the best frame from
arch_timer_mem_find_best_frame().
Fixes: c389d701dfb7 ("clocksource: arm_arch_timer: split MMIO timer probing.")
Signed-off-by: Sudeep Holla
Acked-by: Mark Rutland
Cc: Marc Zyngier
Cc: Daniel Lezcano
Cc: linux-arm-ker...@lists.infradead.org
Link:
http://lkml.kernel.org/r/1494246747-17267-1-git-send-email-sudeep.ho...@arm.com
Signed-off-by: Thomas Gleixner
---
drivers/clocksource/arm_arch_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index a1fb918..4bed671 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1268,7 +1268,7 @@ arch_timer_mem_find_best_frame(struct arch_timer_mem
*timer_mem)
pr_err("Unable to find a suitable frame in timer @ %pa\n",
&timer_mem->cntctlbase);
- return frame;
+ return best_frame;
}
static int __init
Re: [PATCH] x86/intel_rdt: Fix a typo in Documentation
On Wed, 3 May 2017, Xiaochen Shen wrote: > The typo is in example 3. > > "C0" in "# echo C0 > p0/cpus" is wrong because it specifies core > 6-7 instead of wanted core 4-7. > > Correct this typo to avoid confusion. > > Signed-off-by: Xiaochen Shen > Signed-off-by: Fenghua Yu That SOB chain is wrong. Thanks, tglx
Re: CFP: KVM Forum 2017
- Original Message - > From: "Jon Masters" > To: "Paolo Bonzini" , "KVM list" , > linux-kernel@vger.kernel.org, "Linux > Virtualization" > Sent: Tuesday, May 9, 2017 7:42:48 AM > Subject: Re: CFP: KVM Forum 2017 > > On 05/02/2017 06:41 AM, Paolo Bonzini wrote: > > > > KVM Forum 2017: Call For Participation > > October 25-27, 2017 - Hilton Prague - Prague, Czech Republic > > > > (All submissions must be received before midnight June 15, 2017) > > = > > (please provide a timezone for the deadline - not including one in the > podcast, just saying "midnight", but it would be nice next time) Thanks for mentioning KVM Forum in the podcast! The deadline is usually extended unofficially by 24-36 hours, since we always get one or two people who mess up. :) This makes the timezone less important. Paolo
Re: [PATCH] qca_debug: Reduce function calls for sequence output in qcaspi_info_show()
Am 08.05.2017 um 19:29 schrieb SF Markus Elfring: > From: Markus Elfring > Date: Mon, 8 May 2017 19:21:27 +0200 > > A bit of data was put into a sequence by separate function calls. > Print the same data together with adjusted seq_printf() calls instead. Sorry, i'm not happy with this patch. It doesn't increase readabilityand mixes the output of multiple lines. The only benefit is a little bit higher performance. But for debugfs this won't be necessary. Stefan > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/net/ethernet/qualcomm/qca_debug.c | 10 ++ > 1 file changed, 2 insertions(+), 8 deletions(-) >
Re: [PATCH] Fix NR_IRQS printk()
On Wed, 3 May 2017, Vincent Legoll wrote: > Subject : [PATCH] Fix NR_IRQS printk() The subject line is missing a subsystem token. Please consult Documentation/process/submitting-patches.rst and run 'git log path/to/affected.file' to see how a proper subject line should look like. > - Missing some whitespace > - Tell that the third number is "initcnt" (whatever that is) Your changelog is telling WHAT the patch is doing, but not WHY and despite the subject claiming to fix something the changelog lacks any information about the problem it "fixes". Aside of that: "(whatever that is)" is not really convincing that you know what you are doing. Thanks, tglx
Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block
On Tue, May 9, 2017 at 10:01 AM, Richard Weinberger wrote: > > Oleksij, > > Am 09.05.2017 um 07:52 schrieb Oleksij Rempel: > >> > >> If VFS maintainers are fine with that, I'll take it. > >> From UBIFS' POV it does not matter much. :-) > >> > >> > >> Ping to VFS maintainers? > >> > >> > >> What ping? Al made it clear that a flag is not needed. > >> BTW, xfs s_uuid patch was merged to master. > > > > > > I'm talking about ubifs patch. Me too. > > Then we can queue this patch for 4.13. > Please resend and make sure it addresses everything what was also > suggested for the xfs s_uuid patch. > Just to be clear, the xfs s_uuid patch is just a memcpy, no different from Oleksij's patch. Thanks, Amir.
Re: [regression, bisected] 4.11+ imx uarts broken
Hello Mika, On Tue, May 09, 2017 at 07:18:09AM +0300, Mika Penttilä wrote: > The following commit e61c38d85b7 makes the uarts on i.MX6 nonfunctional (no > data transmitted or received). > With e61c38d85b7 reverted the uarts work ok. > > --- > commit e61c38d85b7392e033ee03bca46f1d6006156175 > Author: Uwe Kleine-König > Date: Tue Apr 4 11:18:51 2017 +0200 > > serial: imx: setup DCEDTE early and ensure DCD and RI irqs to be off > > are you operating the UART in DTE or DCE mode? Does this affect all UARTs or only those that are not used in the bootloader? Looking at the patch I wonder if setting IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP is missing for you. Can you please check which hunk of e61c38d85b73 is giving you problems? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v7 4/5] i2c: aspeed: added driver for Aspeed I2C
On Mon, 2017-05-08 at 16:28 -0700, Brendan Higgins wrote: > > I am curious what everyone thinks about this. It seemed that, earlier > on, people did not like me disabling multi-master mode, but I think > that it would make bus recovery not work as well. Given that, I think > it makes the most sense to provide a device tree option either to > enable multi-master support or disable it. Thoughts? I think we probably want to keep it enabled yes. Another reason is that SMBus notifications are in effect a type of multi-master (well slave really), and we should really add support for them even when the slave is not enabled. We are hitting some PMbus devices that apparently can't be prevented from sending those and that's causing issues. Cheers, Ben.
Re: [patch 0/6] hwmon/coretemp: Hotplug fixes, cleanups and state machine conversion
On Thu, 4 May 2017, Tommi Rantala wrote: > 2017-04-23 18:01 GMT+03:00 Thomas Gleixner : > > On Sat, 15 Apr 2017, Tommi Rantala wrote: > > > >> Testing with 4.10.8-200.fc25.x86_64: freezer, devices and platform are > >> OK, it breaks at "processors". > >> The screen stays off, and the machine no longer answers to ping. > >> > >> (Without coretemp loaded, the machine survives all the states. There > >> are some graphics glitches and radeon error messages) > > > > That's odd. I tried on a similar machine (w/o a radeon card) and it just > > works with the coretemp module loaded. > > > > Can you please do a CPU hotplug cycle (just one CPU) with the cpuhp events > > in the tracer enabled. Send me the trace output so I might be able to spot > > whats different and what interdependencies between other callbacks might be > > there. > > Hi, > > Here's the trace output, does it help? Not much. Can you please try the following: 1) Offline all CPUs except CPU0 before suspend/resume 2) Offline all CPUs except CPU0 and CPU1 before suspend/resume 3) Offline all CPUs except CPU0 and CPU2 before suspend/resume Thanks, tglx
Re: [PATCH] x86/intel_rdt: Fix a typo in Documentation
Hi Thomas, I am sorry, this is the reason why I added Fenghua in SOB list: I have sent this patch to Fenghua for internal review. After that, I sent it out to LKML. What is your suggestion to fix? Move Fenghua from "Signed-off-by:" to "Cc:"? Thank you. Best regards, Xiaochen On 2017/5/9 15:03, Thomas Gleixner wrote: > On Wed, 3 May 2017, Xiaochen Shen wrote: > >> The typo is in example 3. >> >> "C0" in "# echo C0 > p0/cpus" is wrong because it specifies core >> 6-7 instead of wanted core 4-7. >> >> Correct this typo to avoid confusion. >> >> Signed-off-by: Xiaochen Shen >> Signed-off-by: Fenghua Yu > > That SOB chain is wrong. > > Thanks, > > tglx >
Re: [PATCH] x86/intel_rdt: Fix a typo in Documentation
On Tue, 9 May 2017, Xiaochen Shen wrote: > Hi Thomas, > > I am sorry, this is the reason why I added Fenghua in SOB list: > I have sent this patch to Fenghua for internal review. After that, I sent it > out to LKML. The SOB chain would have been correct, if Fenghua would have sent your patch. > What is your suggestion to fix? Move Fenghua from "Signed-off-by:" to "Cc:"? Yes, and if Fenghua want's to add his acked/reviewed-by he can do this on the mailing list. Thanks, tglx
Re: [PATCH v2 02/16] fpga: bridge: support getting bridge from device
On Mon, May 08, 2017 at 03:44:12PM -0500, Alan Tull wrote: > On Mon, May 8, 2017 at 3:44 AM, Wu, Hao wrote: > >> On Wed, May 3, 2017 at 3:07 PM, Alan Tull wrote: > >> > On Wed, May 3, 2017 at 6:58 AM, Wu Hao wrote: > >> >> On Thu, Apr 20, 2017 at 09:09:47AM -0500, Alan Tull wrote: > >> >>> Add two functions for getting the FPGA bridge from the device > >> >>> rather than device tree node. This is to enable writing code > >> >>> that will support using FPGA bridges without device tree. > >> >>> Rename one old function to make it clear that it is device > >> >>> tree-ish. This leaves us with 3 functions for getting a bridge: > >> >>> > >> >>> * fpga_bridge_get > >> >>> Get the bridge given the device. > >> >>> > >> >>> * fpga_bridges_get_to_list > >> >>> Given the device, get the bridge and add it to a list. > >> >>> > >> >>> * of_fpga_bridges_get_to_list > >> >>> Renamed from priviously existing fpga_bridges_get_to_list. > >> >>> Given the device node, get the bridge and add it to a list. > >> >>> > >> >> > >> >> Hi Alan > >> >> > >> >> Thanks a lot for providing this patch set for non device tree support. > >> >> :) > >> >> Actually I am reworking the Intel FPGA device drivers based on this > >> >> patch > >> >> set, and I find some problems with the existing APIs including fpga > >> >> bridge > >> >> and manager. My idea is to create all fpga bridges/regions/manager under > >> >> the same platform device (FME), it allows FME driver to establish the > >> >> relationship for the bridges/regions/managers it creates in an easy way. > >> >> But I found current fpga class API doesn't support this very well. > >> >> e.g fpga_bridge_get/get_to_list only accept parent device as the input > >> >> parameter, but it doesn't work if we have multiple bridges (and > >> >> regions/manager) under the same platform device. fpga_mgr has similar > >> >> issue, but fpga_region APIs work better, as they accept fpga_region as > >> >> parameter not the shared parent device. > >> > > >> > That's good feedback. I can post a couple patches that apply on top > >> > of that patchset to add the APIs you need. > >> > > >> > Probably what I'll do is add > >> > > >> > struct fpga_manager *fpga_mgr_get(struct fpga_manager *mgr); > >> > > >> > And rename fpga_bridge_get() to fpga_bridge_dev_get() and add the > >> following: > >> > > >> > struct fpga_bridge *fpga_bridge_get(struct fpga_bridge *br, > >> > struct fpga_image_info *info); > >> > > >> > int of_fpga_bridge_get_to_list(struct fpga_bridge *br, > >> >struct fpga_image_info *info, > >> >struct list_head *bridge_list); > >> > > >> > Working on it now. > >> > > >> >> > >> >> Do you think if having multiple fpga-* under one parent device is in the > >> >> right direction? > >> > > >> > That should be fine as long as it's coded with an eye on making things > >> > reusable and seeing beyond the current project. Just thinking of the > >> > future and of what can be of general usefulness for others. And there > >> > will be others interested in reusing this. > >> > > >> > Alan > >> > >> Actually, I don't think you will need the additional APIs we were > >> just discussing after all. What you have is a multifunction device > >> (single piece of hardware, multi functions such as in drivers/mfd). > >> It will have child devices for the mgr, bridges, and regions. When > >> registering the mgr and bridges you will need to allocate child > >> devices and use them to create the mgr and bridges. > >> > >> Alan > > > > Hi Alan > > > > I tried to create child devices as the parent device for the mgr and > > bridges in fme platform driver module. If only creates the device without > > driver, it doesn't work as try_module_get(dev->parent->driver->owner) > > always failed in mgr_get and bridge_get functions. > > I tried it and it wasn't hard. > > Each mgr or bridge driver should be a separate file which registers > its driver using 'module_platform_driver". That way the drivers are > registered with the kernel in a normal fashion. The thing we want > here is to not bypass the kernel driver model. > > You'll need to keep the platform_device pointers in private data somewhere. > > For each child platform device, do a platform_device_alloc and > platform_device_add. > > Then to get the manager, you can do > > mgr = fpga_mgr_get(&priv->mgr_pdev->dev); > > If this is in your probe function, you can use -EPROBE_DEFER if > platform_device_alloc or fpga_mgr_get fail. Then you could destroy > whatever you've created and return -EPROBE_DEFER to wait for the > drivers you need to be registered and ready for devices to be added. > > > > > If it creates platform devices as child devices, and introduce new platform > > device drivers for bridge and mgr, then it will be difficult to establish > > the > > relationship for region/mgr/bridges (e.g when should region->mgr be > > configured and
Re: [PATCH] key: Convert big_key payload.data to struct
Eric Biggers wrote: > It probably would be easier to kmalloc() this struct and store a pointer to > it in key->payload.data[0] Yeah, but it's a waste of resources if you don't have to do it. David
[PATCH 0/3] ath9k: Fine-tuning for some function implementations
From: Markus Elfring Date: Tue, 9 May 2017 09:19:09 +0200 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Reduce function calls for sequence output in read_file_dma() Replace four seq_printf() calls by seq_putc() Adjust a null pointer check in three functions drivers/net/wireless/ath/ath9k/debug.c | 25 ++--- 1 file changed, 10 insertions(+), 15 deletions(-) -- 2.12.2
Re: [regression, bisected] 4.11+ imx uarts broken
On 05/09/2017 10:14 AM, Uwe Kleine-König wrote: > Hello Mika, > > On Tue, May 09, 2017 at 07:18:09AM +0300, Mika Penttilä wrote: >> The following commit e61c38d85b7 makes the uarts on i.MX6 nonfunctional (no >> data transmitted or received). >> With e61c38d85b7 reverted the uarts work ok. >> >> --- >> commit e61c38d85b7392e033ee03bca46f1d6006156175 >> Author: Uwe Kleine-König >> Date: Tue Apr 4 11:18:51 2017 +0200 >> >> serial: imx: setup DCEDTE early and ensure DCD and RI irqs to be off >> >> > > are you operating the UART in DTE or DCE mode? Does this affect all > UARTs or only those that are not used in the bootloader? I am operating in DCE mode. The debug/console uart works ok, but two others don't. > > Looking at the patch I wonder if setting IMX21_UCR3_RXDMUXSEL | > UCR3_ADNIMP is missing for you. > Probably yes, but I can verify this later and get back to you. > Can you please check which hunk of e61c38d85b73 is giving you problems? > > Best regards > Uwe > --Mika
[PATCH 1/3] ath9k: Reduce function calls for sequence output in read_file_dma()
From: Markus Elfring
Date: Mon, 8 May 2017 21:55:09 +0200
Some data were put into a sequence by separate function calls.
Print the same data with two function calls less.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/net/wireless/ath/ath9k/debug.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index 2e64977a8ab6..981b38a1e352 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -427,9 +427,7 @@ static int read_file_dma(struct seq_file *file, void *data)
seq_printf(file, "%d: %08x ", i, val[i]);
}
- seq_puts(file, "\n\n");
- seq_puts(file, "Num QCU: chain_st fsp_ok fsp_st DCU: chain_st\n");
-
+ seq_puts(file, "\n\nNum QCU: chain_st fsp_ok fsp_st DCU: chain_st\n");
for (i = 0; i < ATH9K_NUM_QUEUES; i++, qcuOffset += 4, dcuOffset += 5) {
if (i == 8) {
qcuOffset = 0;
@@ -448,9 +446,8 @@ static int read_file_dma(struct seq_file *file, void *data)
(*dcuBase & (0x1f << dcuOffset)) >> dcuOffset);
}
- seq_puts(file, "\n");
-
- seq_printf(file, "qcu_stitch state: %2xqcu_fetch state:
%2x\n",
+ seq_printf(file,
+ "\nqcu_stitch state: %2xqcu_fetch state:%2x\n",
(val[3] & 0x003c) >> 18, (val[3] & 0x03c0) >> 22);
seq_printf(file, "qcu_complete state: %2xdcu_complete state:
%2x\n",
(val[3] & 0x1c00) >> 26, (val[6] & 0x3));
--
2.12.2
[PATCH 2/3] ath9k: Replace four seq_printf() calls by seq_putc()
From: Markus Elfring
Date: Mon, 8 May 2017 22:04:47 +0200
Four single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/net/wireless/ath/ath9k/debug.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index 981b38a1e352..0d215598193c 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -421,7 +421,7 @@ static int read_file_dma(struct seq_file *file, void *data)
for (i = 0; i < ATH9K_NUM_DMA_DEBUG_REGS; i++) {
if (i % 4 == 0)
- seq_puts(file, "\n");
+ seq_putc(file, '\n');
val[i] = REG_READ_D(ah, AR_DMADBG_0 + (i * sizeof(u32)));
seq_printf(file, "%d: %08x ", i, val[i]);
@@ -702,8 +702,7 @@ static int read_file_misc(struct seq_file *file, void *data)
if (rxfilter & ATH9K_RX_FILTER_CONTROL_WRAPPER)
seq_puts(file, " CONTROL_WRAPPER");
- seq_puts(file, "\n");
-
+ seq_putc(file, '\n');
reg = sc->sc_ah->imask;
seq_printf(file, "INTERRUPT-MASK: 0x%x", reg);
@@ -723,8 +722,7 @@ static int read_file_misc(struct seq_file *file, void *data)
if (reg & ATH9K_INT_BB_WATCHDOG)
seq_puts(file, " BB_WATCHDOG");
- seq_puts(file, "\n");
-
+ seq_putc(file, '\n');
i = 0;
ath_for_each_chanctx(sc, ctx) {
if (list_empty(&ctx->vifs))
@@ -981,7 +979,7 @@ static int read_file_dump_nfcal(struct seq_file *file, void
*data)
seq_printf(file, " %d\t %d\t %d\t\t", i, h[i].privNF, nread);
for (j = 0; j < nread; j++)
seq_printf(file, " %d", h[i].nfCalBuffer[j]);
- seq_puts(file, "\n");
+ seq_putc(file, '\n');
}
return 0;
--
2.12.2
Re: [PATCH] pinctrl: imx: Check for memory allocation failure
On Sun, May 07, 2017 at 04:40:38AM +0900, Stafford Horne wrote: > Hi Christophe, > > On Sat, May 06, 2017 at 10:23:59AM +0200, Christophe JAILLET wrote: > > If 'devm_kzalloc' fails, a NULL pointer will be dereferenced. > > Return -ENOMEM instead, as done for the other memory allocation just a > > few lines below. > > This looks fine. > > > BTW, change the 'devm_kzalloc' into a 'devm_kcalloc'. > > Any reason for the devm_kcalloc change? It looks like the next for loop > does set all of the group_name values. > The advantage of kcalloc() over kzalloc() is the integer overflow checking. There is kmalloc_array() if we don't need to zero the memory. regards, dan carpenter
Re: [PATCH] x86/intel_rdt: Fix two typos in Documentation
On Fri, Apr 07, 2017 at 01:09:41AM +0800, Xiaochen Shen wrote: > Both typos are in example 3. > > Because cache id 0 is the only cache id, the ";" is redundant in > "# echo "L3:0=ffc00;" > p0/schemata". > > And "C0" in "# echo C0 > p0/cpus" is wrong because it specifies core > 6-7 instead of wanted core 4-7. > > Correct the typos to avoid confusion. > > Signed-off-by: Xiaochen Shen Acked-by: Fenghua Yu
[PATCH 3/3] ath9k: Adjust a null pointer check in three functions
From: Markus Elfring
Date: Mon, 8 May 2017 22:17:13 +0200
The script "checkpatch.pl" pointed information out like the following.
Comparison to NULL could be written "!buf"
Thus adjust this expression.
Signed-off-by: Markus Elfring
---
drivers/net/wireless/ath/ath9k/debug.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index 0d215598193c..5f2c1d8e8e70 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -161,7 +161,7 @@ static ssize_t read_file_ani(struct file *file, char __user
*user_buf,
};
buf = kzalloc(size, GFP_KERNEL);
- if (buf == NULL)
+ if (!buf)
return -ENOMEM;
len += scnprintf(buf + len, size - len, "%15s: %s\n", "ANI",
@@ -315,7 +315,7 @@ static ssize_t read_file_antenna_diversity(struct file
*file,
};
buf = kzalloc(size, GFP_KERNEL);
- if (buf == NULL)
+ if (!buf)
return -ENOMEM;
if (!(pCap->hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB)) {
@@ -1008,7 +1008,7 @@ static ssize_t read_file_btcoex(struct file *file, char
__user *user_buf,
size_t retval;
buf = kzalloc(size, GFP_KERNEL);
- if (buf == NULL)
+ if (!buf)
return -ENOMEM;
if (!sc->sc_ah->common.btcoex_enabled) {
--
2.12.2
Re: RFC: WMI Enhancements
On Tuesday 09 May 2017 01:10:54 mario.limoncie...@dell.com wrote: > > > > I found dmsdos implementation of that DS compression at: > > http://cmp.felk.cvut.cz/~pisa/dmsdos > > > > Then took relevant decompression code and it really decompressed that > > binary MOF WMI buffer. But still decompressed format is binary, but I > > now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again > > "FOMB" magic header. > > Well that's great. Is it possible that this compression is used for every > time > a class was declared? Looks like not. That decompressed output seems to be not compressed anymore. Just use same magic header. Now it looks like binary representation of MOF. Where structures and types are encoded by binary sequences. > > > > I pushed my decompression utility here: > > https://github.com/pali/bmfdec > > Did you forget another commit for pulling in arguments and opening a file > or were you just putting the whole buffer into pin? Whole BMF file should be on stdin (with that 16 bytes header) and is decompressed on stdout. > > > > So next step is to decode that decompressed binary MOF file. > > > > > 44 53 looks promising to be quantum compression. So... it is not Quantum compression. BMF content does not pass Quantum header where is number of files (too huge). -- Pali Rohár pali.ro...@gmail.com
Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block
Amir, Am 09.05.2017 um 09:08 schrieb Amir Goldstein: >> Then we can queue this patch for 4.13. >> Please resend and make sure it addresses everything what was also >> suggested for the xfs s_uuid patch. >> > > Just to be clear, the xfs s_uuid patch is just a memcpy, > no different from Oleksij's patch. Wasn't there a huge discussion about LE/BE/uniqueness and more details on UUID that hurt my brain. Thanks, //richard
Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block
On 05/09/2017 09:08 AM, Amir Goldstein wrote: On Tue, May 9, 2017 at 10:01 AM, Richard Weinberger wrote: Oleksij, Am 09.05.2017 um 07:52 schrieb Oleksij Rempel: If VFS maintainers are fine with that, I'll take it. From UBIFS' POV it does not matter much. :-) Ping to VFS maintainers? What ping? Al made it clear that a flag is not needed. BTW, xfs s_uuid patch was merged to master. I'm talking about ubifs patch. Me too. :) ok Then we can queue this patch for 4.13. Please resend and make sure it addresses everything what was also suggested for the xfs s_uuid patch. Just to be clear, the xfs s_uuid patch is just a memcpy, no different from Oleksij's patch. So, should i change something? here is the patch: https://patchwork.kernel.org/patch/9674817/
Re: [PATCH v5 2/8] [media] stm32-dcmi: STM32 DCMI camera interface driver
Hi Hans, It's OK, feel free to change. BR Hugues. On 05/06/2017 10:54 AM, Hans Verkuil wrote: > Hi Hugues, > > On 05/05/2017 05:31 PM, Hugues Fruchet wrote: >> This V4L2 subdev driver enables Digital Camera Memory Interface (DCMI) >> of STMicroelectronics STM32 SoC series. >> >> Reviewed-by: Hans Verkuil >> Signed-off-by: Yannick Fertre >> Signed-off-by: Hugues Fruchet >> --- >> drivers/media/platform/Kconfig| 12 + >> drivers/media/platform/Makefile |2 + >> drivers/media/platform/stm32/Makefile |1 + >> drivers/media/platform/stm32/stm32-dcmi.c | 1403 >> + >> 4 files changed, 1418 insertions(+) >> create mode 100644 drivers/media/platform/stm32/Makefile >> create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c >> >> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig >> index ac026ee..de6e18b 100644 >> --- a/drivers/media/platform/Kconfig >> +++ b/drivers/media/platform/Kconfig >> @@ -114,6 +114,18 @@ config VIDEO_S3C_CAMIF >>To compile this driver as a module, choose M here: the module >>will be called s3c-camif. >> >> +config VIDEO_STM32_DCMI >> +tristate "Digital Camera Memory Interface (DCMI) support" > > Is it OK with you if I change this to: > > tristate "STM32 Digital Camera Memory Interface (DCMI) support" > > Right now the text gives no indication that this driver is for an STM32 > platform. > > No need to spin a new patch, just let me know you're OK with it and I'll make > the change. > > Regards, > > Hans > >> +depends on VIDEO_V4L2 && OF && HAS_DMA >> +depends on ARCH_STM32 || COMPILE_TEST >> +select VIDEOBUF2_DMA_CONTIG >> +---help--- >> + This module makes the STM32 Digital Camera Memory Interface (DCMI) >> + available as a v4l2 device. >> + >> + To compile this driver as a module, choose M here: the module >> + will be called stm32-dcmi. >> + >> source "drivers/media/platform/soc_camera/Kconfig" >> source "drivers/media/platform/exynos4-is/Kconfig" >> source "drivers/media/platform/am437x/Kconfig"
Re: [PATCH] x86/intel_rdt: Fix a typo in Documentation
Thank you, Thomas. I will send out v2 patch with the fix soon. Best regards, Xiaochen On 2017/5/9 15:22, Thomas Gleixner wrote: > On Tue, 9 May 2017, Xiaochen Shen wrote: > >> Hi Thomas, >> >> I am sorry, this is the reason why I added Fenghua in SOB list: >> I have sent this patch to Fenghua for internal review. After that, I sent it >> out to LKML. > > The SOB chain would have been correct, if Fenghua would have sent your > patch. > >> What is your suggestion to fix? Move Fenghua from "Signed-off-by:" to "Cc:"? > > Yes, and if Fenghua want's to add his acked/reviewed-by he can do this on > the mailing list. > > Thanks, > > tglx >
Re: [PATCH v5 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
On 09/05/17 02:16, Randy Li wrote: On 05/09/2017 12:27 AM, Heiko Stübner wrote: Am Mittwoch, 3. Mai 2017, 10:56:24 CEST schrieb Guillaume Tucker: The ARM Mali Midgard GPU kernel driver is only available out-of-tree and is not going to be merged in its current form. However, it would be useful to have its device tree bindings merged. In particular, this would enable distributions to create working driver packages (dkms...) without having to patch the kernel. The bindings for the earlier Mali Utgard GPU family have already been merged, so this is essentially the same scenario but for newer GPUs (Mali-T604 ~ Mali-T880). This series of patches first imports the bindings from the latest driver release with some clean-up then adds a gpu node for the rk3288 SoC. This was successfully tested on Radxa Rock2 Square, Firefly, Veyron Minnie and Jerry boards using Mali kernel driver r16p0 and r12p0 user-space binary. I won't suggest such combine. We meet some problems at mali 400 serial. I would suggest the kernel version would match the user library. Well, I can test it again with r12p0 kernel driver (out-of-tree) if you want. The user-space driver checks the version of the kernel driver and gives up if it's not compatible. With Midgard, there's a range of versions that maintain kernel/userspace compatibility unlike Utgard and older Midgard releases where they had to exactly match. Again, if there was a mismatch then the user-space would fail to initialise and report an error. Also please notice there is rk3288w, the hardware version becomes r1p0. Sounds like a new SoC? Does rk3288w affect rk3288 in any way? Unless it's a special case, it seems to me that any new SoC with a Midgard GPU would need an extra vendor compatible string in the binding documentation and maybe a separate gpu dt node. The actual devicetree parts are all Rockchip-specific, so I guess I'll just pick up the whole series, including the binding doc, after the merge window if nobody complains before that :-) Thanks! Guillaume
[PATCH v2] kthread: fix use-after-free if kthread fork fails
If a kthread forks (e.g. usermodehelper since commit 1da5c46fa965) but
fails in copy_process() between calling dup_task_struct() and setting
p->set_child_tid, then the value of p->set_child_tid will be inherited
from the parent and get prematurely freed by free_kthread_struct().
kthread()
- worker_thread()
- process_one_work()
| - call_usermodehelper_exec_work()
| - kernel_thread()
|- _do_fork()
| - copy_process()
| - dup_task_struct()
| - arch_dup_task_struct()
|- tsk->set_child_tid = current->set_child_tid //
implied
| - ...
| - goto bad_fork_*
| - ...
| - free_task(tsk)
| - free_kthread_struct(tsk)
|- kfree(tsk->set_child_tid)
- ...
- schedule()
- __schedule()
- wq_worker_sleeping()
- kthread_data(task)->flags // UAF
The problem started showing up with commit 1da5c46fa965 since it reused
->set_child_tid for the kthread worker data.
A better long-term solution might be to get rid of the ->set_child_tid
abuse. The comment in set_kthread_struct() also looks slightly wrong.
Fixes: 1da5c46fa965ff90f5ffc080b6ab3fae5e227bc3 ("kthread: Make struct kthread
kmalloc'ed")
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Andy Lutomirski
Debugged-by: Jamie Iles
Signed-off-by: Vegard Nossum
---
kernel/fork.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index dd5a371c392a..03b2f9606a54 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1554,6 +1554,18 @@ static __latent_entropy struct task_struct *copy_process(
if (!p)
goto fork_out;
+ /*
+* This _must_ happen before we call free_task(), i.e. before we jump
+* to any of the bad_fork_* labels. This is to avoid freeing
+* p->set_child_tid which is (ab)used as a kthread's data pointer for
+* kernel threads (PF_KTHREAD).
+*/
+ p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr :
NULL;
+ /*
+* Clear TID on mm_release()?
+*/
+ p->clear_child_tid = (clone_flags & CLONE_CHILD_CLEARTID) ?
child_tidptr : NULL;
+
ftrace_graph_init_task(p);
rt_mutex_init_task(p);
@@ -1720,11 +1732,6 @@ static __latent_entropy struct task_struct *copy_process(
}
}
- p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr :
NULL;
- /*
-* Clear TID on mm_release()?
-*/
- p->clear_child_tid = (clone_flags & CLONE_CHILD_CLEARTID) ?
child_tidptr : NULL;
#ifdef CONFIG_BLOCK
p->plug = NULL;
#endif
--
2.12.0.rc0
Re: [PATCH] Fix NR_IRQS printk()
On Tue, May 9, 2017 at 9:08 AM, Thomas Gleixner wrote: > On Wed, 3 May 2017, Vincent Legoll wrote: > >> Subject : [PATCH] Fix NR_IRQS printk() > > The subject line is missing a subsystem token. Please consult > > Documentation/process/submitting-patches.rst > > and run 'git log path/to/affected.file' to see how a proper subject line > should look like. OK, looks like this is "genirq", is that right ? >> - Missing some whitespace >> - Tell that the third number is "initcnt" (whatever that is) > > Your changelog is telling WHAT the patch is doing, but not WHY and despite > the subject claiming to fix something the changelog lacks any information > about the problem it "fixes". OK, will change, what about: "[PATCH] genirq: Fix early_irq_init() printing the nr of preallocated irqs" > Aside of that: "(whatever that is)" is not really convincing that you know > what you are doing. Is the above better ? If OK, I'll resend properly. Thanks for the help -- Vincent Legoll
Re: CFP: KVM Forum 2017
:) Podcast drops sometime next couple days - double header this week to cover every pull request in 4.12...just that part is 4500 words of summary and that's not counting ongoing dev. I think the merge window is basically some kind of ultimate curse. Sorry for top post...time to z. -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On May 9, 2017, at 03:06, Paolo Bonzini wrote: > > > > - Original Message - >> From: "Jon Masters" >> To: "Paolo Bonzini" , "KVM list" >> , linux-kernel@vger.kernel.org, "Linux >> Virtualization" >> Sent: Tuesday, May 9, 2017 7:42:48 AM >> Subject: Re: CFP: KVM Forum 2017 >> >>> On 05/02/2017 06:41 AM, Paolo Bonzini wrote: >>> >>> KVM Forum 2017: Call For Participation >>> October 25-27, 2017 - Hilton Prague - Prague, Czech Republic >>> >>> (All submissions must be received before midnight June 15, 2017) >>> = >> >> (please provide a timezone for the deadline - not including one in the >> podcast, just saying "midnight", but it would be nice next time) > > Thanks for mentioning KVM Forum in the podcast! The deadline is usually > extended unofficially by 24-36 hours, since we always get one or two people > who mess up. :) This makes the timezone less important. > > Paolo >
Re: [BUG] crash when removing sun4i_gpadc_iio module
Hi, On 07/05/2017 17:14, Jonathan Cameron wrote: > On 02/05/17 07:46, Corentin Labbe wrote: >> Hello > > Beyond picking up in a quick code inspection I'm afraid. Quentin > can you take a look at this? I guess its triggering as a result > of the call to read the temperature failing, but beyond that - no > idea! > Hadn't had time to look at it last week. Will do this week and keep you updated on this bug. Quentin > Jonathan >> >> When inserting sun4i_gpadc_iio I got the following error in dmesg: >> [79961.039826] thermal thermal_zone0: failed to read out thermal zone (-110) >> >> Then removing the module cause an oops: >> [80105.370937] Unable to handle kernel paging request at virtual address >> bf0ad1d0 >> [80105.370958] pgd = c0004000 >> [80105.370968] [bf0ad1d0] *pgd=6e470811, *pte=, *ppte= >> [80105.371009] Internal error: Oops: 8007 [#1] PREEMPT SMP ARM >> [80105.376940] Modules linked in: algif_aead ccm gcm algif_rng crypto_user >> algif_skcipher algif_hash af_alg ghash_generic aes_arm_bs axp20x_ac_power >> axp20x_usb_power axp20x_adc gpio_axp209 nvmem_sunxi_sid sun4i_ss sun4i_dma >> virt_dma [last unloaded: sun4i_gpadc_iio] >> [80105.400199] CPU: 0 PID: 14663 Comm: kworker/0:0 Tainted: GW >> 4.11.0-rc8-next-20170428+ #96 >> [80105.409581] Hardware name: Allwinner sun7i (A20) Family >> [80105.414821] Workqueue: events_freezable thermal_zone_device_check >> [80105.420915] task: ee7d2880 task.stack: ea4fa000 >> [80105.425447] PC is at 0xbf0ad1d0 >> [80105.428594] LR is at arch_timer_read_counter_long+0x14/0x18 >> [80105.434166] pc : []lr : []psr: 60070013 >>sp : ea4fbea8 ip : ee7d2e00 fp : 0001 >> [80105.445630] r10: ea4fbed4 r9 : 007b r8 : >> [80105.450852] r7 : ee7ffc14 r6 : ee7ff800 r5 : c09e2260 r4 : 005a >> [80105.457373] r3 : c058e3d4 r2 : fac81000 r1 : 01bf r0 : 5dbf >> [80105.463897] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment >> none >> [80105.471025] Control: 10c5387d Table: 66c9c06a DAC: 0051 >> [80105.476766] Process kworker/0:0 (pid: 14663, stack limit = 0xea4fa210) >> [80105.483288] Stack: (0xea4fbea8 to 0xea4fc000) >> [80105.487648] bea0: 0001 0010 ee7ffbc0 ea4fbefc >> ef26dad4 ef7c2500 >> [80105.495821] bec0: ea4fbf28 bf0ad7e0 0001 c070e80c >> c055d600 ef26d800 >> [80105.503994] bee0: ea4fbefc c055d614 ef26d800 ef7bef00 c055b040 >> ea4fbf28 ef26db20 >> [80105.512167] bf00: ef26db20 edf65680 ef7bef00 c013b374 0001 >> c013b304 c013b798 >> [80105.520340] bf20: c12624a4 c0dcdf20 c09c0e10 >> c0c04900 ef7bef00 >> [80105.528512] bf40: edf65698 0008 c0c04900 ef7bef34 ea4fa000 ef7bef00 >> edf65680 c013b6f8 >> [80105.536685] bf60: ef7bf09c edf65680 edf65380 e6c90700 >> edf65680 c013b6c0 >> [80105.544858] bf80: edf653b8 edf91e84 c01415c0 e6c90700 c0141484 >> >> [80105.553030] bfa0: c01079b8 >> >> [80105.561202] bfc0: >> >> [80105.569374] bfe0: 0013 >> 6fffd861 6fffdc61 >> [80105.577558] [] (arch_timer_read_counter_long) from [<0010>] >> (0x10) >> [80105.584952] Code: bad PC value >> [80105.588283] ---[ end trace ff84d9d449c6a5b5 ]--- >> >> Regards >> Corentin Labbe >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- Quentin Schulz, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH 4.10 0/5] 4.10.15-stable review
On Mon, May 08, 2017 at 01:16:56PM -0600, Shuah Khan wrote: > On 05/06/2017 02:39 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.10.15 release. > > There are 5 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Mon May 8 20:38:36 UTC 2017. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.15-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.10.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing both of these and letting me know. greg k-h
Re: [PATCH v5 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
On 05/09/2017 03:40 PM, Guillaume Tucker wrote: On 09/05/17 02:16, Randy Li wrote: On 05/09/2017 12:27 AM, Heiko Stübner wrote: Am Mittwoch, 3. Mai 2017, 10:56:24 CEST schrieb Guillaume Tucker: The ARM Mali Midgard GPU kernel driver is only available out-of-tree and is not going to be merged in its current form. However, it would be useful to have its device tree bindings merged. In particular, this would enable distributions to create working driver packages (dkms...) without having to patch the kernel. The bindings for the earlier Mali Utgard GPU family have already been merged, so this is essentially the same scenario but for newer GPUs (Mali-T604 ~ Mali-T880). This series of patches first imports the bindings from the latest driver release with some clean-up then adds a gpu node for the rk3288 SoC. This was successfully tested on Radxa Rock2 Square, Firefly, Veyron Minnie and Jerry boards using Mali kernel driver r16p0 and r12p0 user-space binary. I won't suggest such combine. We meet some problems at mali 400 serial. I would suggest the kernel version would match the user library. Well, I can test it again with r12p0 kernel driver (out-of-tree) if you want. The user-space driver checks the version of the kernel driver and gives up if it's not compatible. With Midgard, there's a range of versions that maintain kernel/userspace compatibility unlike Utgard and older Midgard releases where they had to exactly match. Again, if there was a mismatch then the user-space would fail to initialise and report an error. Anyway, could you verify the mali userspace library r13p0? Rockchip would use this version to offer the support of X11, wayland and gbm. Also please notice there is rk3288w, the hardware version becomes r1p0. Sounds like a new SoC? Does rk3288w affect rk3288 in any way? It is not a new SoC, just a new version of rk3288. It fixes a various of the chip bug of the rk3288. Unless it's a special case, it seems to me that any new SoC with a Midgard GPU would need an extra vendor compatible string in the binding documentation and maybe a separate gpu dt node. The actual devicetree parts are all Rockchip-specific, so I guess I'll just pick up the whole series, including the binding doc, after the merge window if nobody complains before that :-) Thanks! Guillaume -- Randy Li
Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode
2017-05-08 17:17 GMT+02:00 William Breathitt Gray :
> On Sun, May 07, 2017 at 02:49:16PM +0100, Jonathan Cameron wrote:
>>On 01/05/17 01:50, Jonathan Cameron wrote:
>>> On 27/04/17 14:29, Benjamin Gaignard wrote:
Add validate function to be use to use the correct trigger.
Add an attribute to configure device mode like for quadrature and
enable modes
Signed-off-by: Benjamin Gaignard
>>> Hmm. I think I quite like this as an approach but have changed my
>>> mind several times over the last few days :)
>>>
>>> Hence I'd ideally like some more opinions and will be leaving it
>>> on the list for at least a short time longer.
>>>
>>> It's missed the current merge window anyway so plenty of time to
>>> tick off this last element of your support.
>>>
>>> I also just checked and our docs for the existing modes is rubbish
>>> (or I can't find it with a quick grep ;)
>>> so we should tidy that up and add some description of this as well.
>>Still looking for more input on this!
>>
>>Lars - do you have time for a quick look?
>>
>>No real rush though as we are early in the cycle.
>>
>>Thanks,
>>
>>Jonathan
>
> I haven't used triggers before in my drivers so perhaps I can provide
> the naive perspective of someone approaching the API for the first time.
>
> From what I gather, the INDIO_BUFFERED_TRIGGERED option is used for
> triggers associated with a buffer; for example, a device keeping track
> of ambient temperature may periodically sample its sensors and store the
> data in a buffer for later evaluation.
>
> The INDIO_EVENT_TRIGGERED option appears to be used for triggers
> associated with some sort of event; for example, a threshold voltage is
> reached on an ADC device.
>
> I'm having trouble groking how the INDIO_HARDWARE_TRIGGERED option
> differs from the INDIO_EVENT_TRIGGERED option. It looks like the
> INDIO_HARDWARE_TRIGGERED option is used in this case to associate a
> trigger with a clock edge (first timer chained to second timer).
> Wouldn't an INDIO_EVENT_TRIGGERED option be sufficient in this case
> where the event is defined as the clock edge input to the second timer?
The main difference I have introduce between INDIO_EVENT_TRIGGERED and
INDIO_HARDWARE_TRIGGERED is that this last one doesn't have poll function
(i.e. userland can't wait on the event).
For me userland doesn't need to be informed of each clock rising edge.
More generally this new mode can be used when the event can't/doesn't need be
notified to userland which is the case in my hardware where it is a
signal on internal
wire.
>
> William Breathitt Gray
>
>>>
>>> Jonathan
---
.../ABI/testing/sysfs-bus-iio-timer-stm32 | 15 ++
drivers/iio/trigger/stm32-timer-trigger.c | 61
++
2 files changed, 76 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
index 230020e..cccdf57 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
+++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
@@ -90,3 +90,18 @@ Description:
Counting is enabled on rising edge of the connected
trigger, and remains enabled for the duration of this
selected mode.
+
+What:
/sys/bus/iio/devices/iio:deviceX/in_count_trigger_mode_available
+KernelVersion: 4.13
+Contact: benjamin.gaign...@st.com
+Description:
+ Reading returns the list possible trigger modes.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_count0_trigger_mode
+KernelVersion: 4.13
+Contact: benjamin.gaign...@st.com
+Description:
+ Configure the device counter trigger mode
+ counting direction is set by in_count0_count_direction
+ attribute and the counter is clocked by the connected trigger
+ rising edges.
diff --git a/drivers/iio/trigger/stm32-timer-trigger.c
b/drivers/iio/trigger/stm32-timer-trigger.c
index 0f1a2cf..7c6e90e 100644
--- a/drivers/iio/trigger/stm32-timer-trigger.c
+++ b/drivers/iio/trigger/stm32-timer-trigger.c
@@ -347,12 +347,70 @@ static int stm32_counter_write_raw(struct iio_dev
*indio_dev,
return -EINVAL;
}
+static int stm32_counter_validate_trigger(struct iio_dev *indio_dev,
+ struct iio_trigger *trig)
+{
+ struct stm32_timer_trigger *priv = iio_priv(indio_dev);
+ const char * const *cur = priv->valids;
+ unsigned int i = 0;
+
+ if (!is_stm32_timer_trigger(trig))
+ return -EINVAL;
+
+ while (cur && *cur) {
+ if (!strncmp(trig->name, *cur, strlen(trig->name))) {
+ regmap_update_bits(priv->regmap,
+
Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
Hi Richard, I'm still worried about this failure case, do we really believe that the flash could fail in such a way that the fastmap is corrupted in an undetectable way? If we do detect corruption we should be no worse off than earlier since we should ignore the fastmap, IIRC. Could you please elaborate on the problem you were thinking about? Right now I'm hesitant to use fastmap in any production code, even if it works with my current hardware, since there is no guarantee that the flash chips won't get replaced with a second source option down the line... /Jesper On Mon, Apr 03, 2017 at 01:17:36PM +0200, Jesper Nilsson wrote: > Hi Richard, > > On Thu, Mar 30, 2017 at 11:29:15PM +0200, Richard Weinberger wrote: > > Jesper, > > > > Am 30.03.2017 um 19:39 schrieb Jesper Nilsson: > > >> So we should document this with a big fat warning and set fastmap to > > >> default=n ? > > > > > > Does this sound reasonable? > > > > > > Note that this feature makes UBI less robust, since Fastmap does not scan > > > the full flash, which might lead to problems on misbehaving NAND chips. > > > Only enable this if the speedup in attach is really important and > > > > I'm not a native English speaker, but shouldn't this be > > "...if speedup of the attach time is important ..." > > > > > you can be sure that the NAND works as expected. > > > > Looks fine! > > As you saw I resent the patch with this formulation added. > > However, after thinking about it (and with input from some coworkers), > could we pinpoint the failure case a bit more here? > > What is the exact problem behaviour on NAND chips that we're > worried about, and in which case will UBI be less robust if > we don't scan the full flash? > > My first reaction was that this was a natural conclusion, > but if the NAND flash is failing, we should either be in the > case that the FASTMAP is corrupted or that the original data > is corrupted. Both should be found by current implementation. > Or am I missing additional failure cases here? > > I getting a bit worried about using the feature at all, > even if it seems to work right now... > > > Thanks, > > //richard > > /^JN - Jesper Nilsson > -- >Jesper Nilsson -- jesper.nils...@axis.com /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 1/3] staging: iio: meter: Add the comment for mutex definition
On Mon, May 08, 2017 at 10:00:37PM -0400, Harinath Nampally wrote:
> This patch fixes below checkpatch.pl warning:
> CHECK: struct mutex definition without comment
>
> Signed-off-by: Harinath Nampally
> ---
> drivers/staging/iio/meter/ade7753.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/iio/meter/ade7753.c
> b/drivers/staging/iio/meter/ade7753.c
> index b71fbd3..cffe6bf 100644
> --- a/drivers/staging/iio/meter/ade7753.c
> +++ b/drivers/staging/iio/meter/ade7753.c
> @@ -78,12 +78,13 @@
> /**
> * struct ade7753_state - device instance specific data
> * @us: actual spi_device
> + * @buf_lock: mutex to protect tx and rx
> * @tx: transmit buffer
> * @rx: receive buffer
> - * @buf_lock: mutex to protect tx and rx
> **/
> struct ade7753_state {
> struct spi_device *us;
> + /* mutex to protect tx and rx */
Not aligned. We don't need two duplicate comments anyway.
> struct mutexbuf_lock;
regards,
dan carpenter
Re: [PATCH 3.18 00/68] 3.18.52-stable review
On 08/05/2017 at 11:13:51 -0700, Kevin Hilman wrote: > + relevant soc/board maintainers > > kernelci.org bot writes: > > > stable-rc/linux-3.18.y boot: 77 boots: 2 failed, 75 passed > > (v3.18.51-69-gdab3331ef5e9) > > > > Full Boot Summary: > > https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.18.51-69-gdab3331ef5e9/ > > Full Build Summary: > > https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.51-69-gdab3331ef5e9/ > > > > Tree: stable-rc > > Branch: linux-3.18.y > > Git Describe: v3.18.51-69-gdab3331ef5e9 > > Git Commit: dab3331ef5e9aa7d0fa3a88776051028c2f1ed20 > > Git URL: > > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > Tested: 14 unique boards, 8 SoC families, 20 builds out of 204 > > > > Boot Failures Detected: > > > > arm: > > > > at91_dt_defconfig > > at91sam9261ek: 1 failed lab > > Alexandre, can you have a look at this one? > I think we already solved that in a 4.x stable but I don't remember the details right now. I'll check. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[tip:x86/urgent] x86/intel_rdt: Fix a typo in Documentation
Commit-ID: fb8fb46c56289b3f34b5d90a4ec65e9e4e4544a5 Gitweb: http://git.kernel.org/tip/fb8fb46c56289b3f34b5d90a4ec65e9e4e4544a5 Author: Xiaochen Shen AuthorDate: Wed, 3 May 2017 11:15:56 +0800 Committer: Thomas Gleixner CommitDate: Tue, 9 May 2017 09:41:42 +0200 x86/intel_rdt: Fix a typo in Documentation Example 3 contains a typo: "C0" in "# echo C0 > p0/cpus" is wrong because it specifies core 6-7 instead of wanted core 4-7. Correct this typo to avoid confusion. Signed-off-by: Xiaochen Shen Acked-by: Fenghua Yu Cc: vikas.shiva...@linux.intel.com Cc: tony.l...@intel.com Link: http://lkml.kernel.org/r/1493781356-24229-1-git-send-email-xiaochen.s...@intel.com Signed-off-by: Thomas Gleixner --- Documentation/x86/intel_rdt_ui.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/x86/intel_rdt_ui.txt b/Documentation/x86/intel_rdt_ui.txt index 0f6d847..c491a1b 100644 --- a/Documentation/x86/intel_rdt_ui.txt +++ b/Documentation/x86/intel_rdt_ui.txt @@ -295,7 +295,7 @@ kernel and the tasks running there get 50% of the cache. They should also get 50% of memory bandwidth assuming that the cores 4-7 are SMT siblings and only the real time threads are scheduled on the cores 4-7. -# echo C0 > p0/cpus +# echo F0 > p0/cpus 4) Locking between applications
include/linux/spinlock_api_smp.h:169:9: sparse: context imbalance in 'fixup_pi_state_owner' - unexpected unlock
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: bf5f89463f5b3109a72ed13ca62b57e90213387d
commit: 734009e96d1983ad739e5b656e03430b3660c913 futex: Change locking rules
date: 7 weeks ago
reproduce:
# apt-get install sparse
git checkout 734009e96d1983ad739e5b656e03430b3660c913
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
arch/x86/include/asm/futex.h:113:16: sparse: incorrect type in initializer
(different address spaces)
arch/x86/include/asm/futex.h:113:16:expected unsigned int [noderef]
[usertype] *__uval
arch/x86/include/asm/futex.h:113:16:got unsigned int [usertype] *uval
arch/x86/include/asm/futex.h:113:16: sparse: dereference of noderef
expression
include/linux/list.h:78:19: sparse: context imbalance in 'wake_futex_pi' -
unexpected unlock
kernel/futex.c:1573:33: sparse: context imbalance in 'futex_wake_op' -
different lock contexts for basic block
kernel/futex.c:1855:41: sparse: context imbalance in 'futex_requeue' -
different lock contexts for basic block
>> include/linux/spinlock_api_smp.h:169:9: sparse: context imbalance in
>> 'fixup_pi_state_owner' - unexpected unlock
kernel/futex.c:2392:13: sparse: context imbalance in 'futex_wait_queue_me' -
unexpected unlock
kernel/futex.c:2495:9: sparse: context imbalance in 'futex_wait_setup' -
different lock contexts for basic block
kernel/futex.c:2805:22: sparse: context imbalance in 'futex_unlock_pi' -
different lock contexts for basic block
kernel/futex.c:2965:29: sparse: context imbalance in 'futex_wait_requeue_pi'
- unexpected unlock
vim +/fixup_pi_state_owner +169 include/linux/spinlock_api_smp.h
69d0ee73 Heiko Carstens 2009-08-31 153 }
69d0ee73 Heiko Carstens 2009-08-31 154
9c1721aa Thomas Gleixner 2009-12-03 155 static inline void
__raw_spin_unlock_irqrestore(raw_spinlock_t *lock,
69d0ee73 Heiko Carstens 2009-08-31 156
unsigned long flags)
69d0ee73 Heiko Carstens 2009-08-31 157 {
69d0ee73 Heiko Carstens 2009-08-31 158spin_release(&lock->dep_map, 1,
_RET_IP_);
9828ea9d Thomas Gleixner 2009-12-03 159do_raw_spin_unlock(lock);
69d0ee73 Heiko Carstens 2009-08-31 160local_irq_restore(flags);
69d0ee73 Heiko Carstens 2009-08-31 161preempt_enable();
69d0ee73 Heiko Carstens 2009-08-31 162 }
69d0ee73 Heiko Carstens 2009-08-31 163
9c1721aa Thomas Gleixner 2009-12-03 164 static inline void
__raw_spin_unlock_irq(raw_spinlock_t *lock)
69d0ee73 Heiko Carstens 2009-08-31 165 {
69d0ee73 Heiko Carstens 2009-08-31 166spin_release(&lock->dep_map, 1,
_RET_IP_);
9828ea9d Thomas Gleixner 2009-12-03 167do_raw_spin_unlock(lock);
69d0ee73 Heiko Carstens 2009-08-31 168local_irq_enable();
69d0ee73 Heiko Carstens 2009-08-31 @169preempt_enable();
69d0ee73 Heiko Carstens 2009-08-31 170 }
69d0ee73 Heiko Carstens 2009-08-31 171
9c1721aa Thomas Gleixner 2009-12-03 172 static inline void
__raw_spin_unlock_bh(raw_spinlock_t *lock)
69d0ee73 Heiko Carstens 2009-08-31 173 {
69d0ee73 Heiko Carstens 2009-08-31 174spin_release(&lock->dep_map, 1,
_RET_IP_);
9828ea9d Thomas Gleixner 2009-12-03 175do_raw_spin_unlock(lock);
9ea4c380 Peter Zijlstra 2013-11-19 176__local_bh_enable_ip(_RET_IP_,
SOFTIRQ_LOCK_OFFSET);
69d0ee73 Heiko Carstens 2009-08-31 177 }
:: The code at line 169 was first introduced by commit
:: 69d0ee7377eef808e34ba5542b554ec97244b871 locking: Move spinlock function
bodies to header file
:: TO: Heiko Carstens
:: CC: Ingo Molnar
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v2 29/30] dt-bindings: add vendor prefix for bananapi
Hi Sean, Hi Arnd, +Eddie who pinged me about this in a private mail. 2017-05-08 13:36 GMT+02:00 Arnd Bergmann : > On Mon, May 8, 2017 at 11:53 AM, Sean Wang wrote: >> Hi Rob, >> >> thanks for helping me looping in the right group >> >> >> Hi Arnd and Olof >> >> I found Matthias is inactive for a while (his branch in his tree seemed >> to stop at 4.10 since the end of February) maybe he was busy at other >> things. Is there a good way to break the stuck situation and keeping >> linux-mediatek moving on? >> >> I have the willing to fork his tree, prepare dt-for-4.12 and send >> pull-requests to you. > > Hi Sean, > > Thanks for offering to help out. I've added Matthias' other email address > to Cc here, let's see if he notices the discussion now. Ideally any > important platform should have multiple maintainers so there is > always a backup person when the primary contact is unavailable > for any reason. > > I'm not sure how much we can still do for 4.12, if you can prepare a > branch now we can definitely have a look and see what we can > realistically take for a late merge, but as we are in the second half > of the merge window already, we would normally put new features > into a 4.13 branch and only take bug fixes for 4.12. If there are > some entirely new files for additional boards, or only small changes > to the existing files, we might make an exception this time. > >> But I am worried in that way violating the reviewing process if >> Matthias no reads it. > > Don't worry about that at the moment, if Matthias cannot be reached > at all, we have to find an alternative way to get patches in. > I'm very sorry for the situation. Actually I was struggling lately to do my maintainer work in an acceptable manner. And this merge window I definitely wasn't able to follow the discussions. I hope that this will change in the very near future. I would propose to send a merge request or a summary with the relevant patches now and I will look at it today and forward them to Arnd. For the future we should start to think about who could step-in as co-maintainer to avoid situation like this. Once again, sorry for the inconvenience, Matthias > Arnd > >> On Tue, 2017-05-02 at 08:52 -0500, Rob Herring wrote: >>> +arm-soc >>> >>> On Mon, May 1, 2017 at 1:58 AM, Sean Wang wrote: >>> > On Fri, 2017-04-28 at 15:37 -0500, Rob Herring wrote: >>> >> On Wed, Apr 26, 2017 at 05:26:13PM +0800, sean.w...@mediatek.com wrote: >>> >> > From: Sean Wang >>> >> > >>> >> > Banana Pi team in Sinovoip Co., Limited which are dedicated to >>> >> > design and manufacture open hardware product. >>> >> > >>> >> > Website: http://www.banana-pi.org/ >>> >> > >>> >> > Signed-off-by: Sean Wang >>> >> > --- >>> >> > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + >>> >> > 1 file changed, 1 insertion(+) >>> >> > >>> >> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt >>> >> > b/Documentation/devicetree/bindings/vendor-prefixes.txt >>> >> > index ec0bfb9..8ca0f3c 100644 >>> >> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt >>> >> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt >>> >> > @@ -44,6 +44,7 @@ avia avia semiconductor >>> >> > avic Shanghai AVIC Optoelectronics Co., Ltd. >>> >> > axentiaAxentia Technologies AB >>> >> > axis Axis Communications AB >>> >> > +bananapi Banana Pi SINOVOP CO., LIMITED >>> >> >>> >> s/SINOVOP/SINOVOIP/ >>> > >>> > Hi Rob, >>> > >>> > thanks for your careful reviewing , i will correct it in the next >>> > version. >>> > >>> > BTW, Could those related dts changes go through your tree if everything >>> > looks good? Because I find Matthias have been inactive for a while and >>> > the latest branch in his tree seems still staying on 4.10. >>> >>> Happy to take binding doc changes, but I don't take dts changes >>> because those go thru arm-soc. If the platform maintainer is not >>> responsive, then we should replace or add maintainers. >>> >>> Rob -- motzblog.wordpress.com
Re: drivers/scsi/pmcraid.c:3350:48: sparse: incorrect type in argument 2 (different address spaces)
On Tue, May 9, 2017 at 2:32 AM, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 2d3e4866dea96b0506395b47bfefb234f2088dac > commit: beba3a20bf90ce1b93e24592c3ebf0d0bb581bbe x86: switch to RAW_COPY_USER > date: 6 weeks ago > reproduce: > # apt-get install sparse > git checkout beba3a20bf90ce1b93e24592c3ebf0d0bb581bbe > make ARCH=x86_64 allmodconfig > make C=1 CF=-D__CHECK_ENDIAN__ > > > sparse warnings: (new ones prefixed by >>) > >drivers/scsi/pmcraid.c:163:22: sparse: cast from restricted __le16 >drivers/scsi/pmcraid.c:163:22: sparse: cast to restricted __be16 >drivers/scsi/pmcraid.c:163:22: sparse: cast from restricted __le16 >drivers/scsi/pmcraid.c:163:22: sparse: cast to restricted __be16 >drivers/scsi/pmcraid.c:163:22: sparse: cast from restricted __le16 >drivers/scsi/pmcraid.c:178:57: sparse: restricted __le16 degrades to > integer >drivers/scsi/pmcraid.c:333:41: sparse: invalid assignment: &= >drivers/scsi/pmcraid.c:333:41:left side has type restricted __le64 >drivers/scsi/pmcraid.c:333:41:right side has type unsigned long long >drivers/scsi/pmcraid.c:348:29: sparse: Using plain integer as NULL pointer >drivers/scsi/pmcraid.c:901:19: sparse: cast to restricted __le32 >drivers/scsi/pmcraid.c:901:19: sparse: cast from restricted __le64 >drivers/scsi/pmcraid.c:5727:30: sparse: incorrect type in initializer > (different base types) >drivers/scsi/pmcraid.c:5727:30:expected int [signed] cfg_table_size >drivers/scsi/pmcraid.c:5727:30:got restricted __be32 [usertype] > >drivers/scsi/pmcraid.c:5729:13: sparse: cast to restricted __be16 >drivers/scsi/pmcraid.c:5729:13: sparse: cast from restricted __le16 >drivers/scsi/pmcraid.c:5729:13: sparse: cast to restricted __be16 I'm not entirely sure why these all show up now, but my guess is that the friendly robot got confused by my patches that I sent a few weeks ago to fix all the sparse warnings in this driver, leading it to tag the warnings as regressions even though they are all old. Arnd
Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block
On Tue, May 9, 2017 at 10:35 AM, Richard Weinberger wrote: > Amir, > > Am 09.05.2017 um 09:08 schrieb Amir Goldstein: >>> Then we can queue this patch for 4.13. >>> Please resend and make sure it addresses everything what was also >>> suggested for the xfs s_uuid patch. >>> >> >> Just to be clear, the xfs s_uuid patch is just a memcpy, >> no different from Oleksij's patch. See upstream commit 8f720d9 xfs: publish UUID in struct super_block > > Wasn't there a huge discussion about LE/BE/uniqueness and more details > on UUID that hurt my brain. > LE/BE discussions are more about which variants of uuid helpers should be created, among other things, for consumers of s_uuid to check that s_uuid was filled by fs. Converting s_uuid type to uuid_t or whatever is for the far future. uniqueness of s_uuid does not exist with current filesystems, so no reason whatsoever to act differently with ubifs. Fixing uniqueness of s_uuid (if at all is needed) is a future VFS task. Bottom line, for Oleksij's original patch: Reviewed-by: Amir Goldstein If it's not too late for 4.12 that could be nice, because then ubifs+overlayfs would gain a new feature (constant inode numbers)
[PATCH] wil6210: Replace five seq_puts() calls by seq_putc()
From: Markus Elfring
Date: Mon, 8 May 2017 22:22:04 +0200
Five single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/net/wireless/ath/wil6210/debugfs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c
b/drivers/net/wireless/ath/wil6210/debugfs.c
index 5648ebbd0e16..90118d286fb9 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -76,11 +76,11 @@ static void wil_print_vring(struct seq_file *s, struct
wil6210_priv *wil,
volatile struct vring_tx_desc *d = &vring->va[i].tx;
if ((i % 128) == 0 && (i != 0))
- seq_puts(s, "\n");
+ seq_putc(s, '\n');
seq_printf(s, "%c", (d->dma.status & BIT(0)) ?
_s : (vring->ctx[i].skb ? _h : 'h'));
}
- seq_puts(s, "\n");
+ seq_putc(s, '\n');
}
seq_puts(s, "}\n");
}
@@ -233,7 +233,7 @@ static void wil_print_ring(struct seq_file *s, const char
*prefix,
wil_seq_hexdump(s, databuf, len, " : ");
}
} else {
- seq_puts(s, "\n");
+ seq_putc(s, '\n');
}
}
out:
@@ -1366,7 +1366,7 @@ static void wil_print_rxtid_crypto(struct seq_file *s,
int tid,
seq_printf(s, " [%i%s]%6phN", i, cc->key_set ? "+" : "-",
cc->pn);
}
- seq_puts(s, "\n");
+ seq_putc(s, '\n');
}
static int wil_sta_debugfs_show(struct seq_file *s, void *data)
@@ -1423,7 +1423,7 @@ __acquires(&p->tid_rx_lock) __releases(&p->tid_rx_lock)
mcs++)
seq_printf(s, " %lld",
p->stats.rx_per_mcs[mcs]);
- seq_puts(s, "\n");
+ seq_putc(s, '\n');
}
}
--
2.12.2
[PATCH 0/6] tty: serial: lpuart: add imx7ulp support
This patch series mainly intends to add imx7ulp support which is also using FSL lpuart. The lpuart in imx7ulp is basically the same as ls1021a. It's also 32 bit width register, but unlike ls1021a, it's little endian. Besides that, imx7ulp lpuart has a minor different register layout from ls1021a that it has four extra registers (verid, param, global, pincfg) located at the beginning of register map, which are currently not used by the driver and less to be used later. Furthermore, this patch serial also add a new more accurate baud rate calculation method as MX7ULP can't divide a suitable baud rate with the default setting. Currently the new baud rate calculation is only enabled on MX7ULP. However, i guess the Layerscape may also be able to use it as there seems to be no difference in baud rate setting register after checking the Layerscape Reference Manual. As i don't have Layerscape boards, i can't test it, so i only enable it for MX7ULP by default to avoid a potential break. I copied LayerScape guys in this series and hope they can help test later. If it works on Layerscape as well, then they can switch to the new setting too and totally remove the old stuff. Dong Aisheng (6): tty: serial: lpuart: introduce lpuart_soc_data to represent SoC property tty: serial: lpuart: add little endian 32 bit register support dt-bindings: serial: fsl-lpuart: add i.MX7ULP support tty: serial: lpuart: add imx7ulp support tty: serial: lpuart: add earlycon support for imx7ulp tty: serial: lpuart: add a more accurate baud rate calculation method .../devicetree/bindings/serial/fsl-lpuart.txt | 2 + drivers/tty/serial/fsl_lpuart.c| 149 ++--- 2 files changed, 136 insertions(+), 15 deletions(-) -- 2.7.4
[PATCH 3/6] dt-bindings: serial: fsl-lpuart: add i.MX7ULP support
The lpuart of imx7ulp is basically the same as ls1021a. It's also 32 bit width register, but unlike ls1021a, it's little endian. Besides that, imx7ulp lpuart has a minor different register layout from ls1021a. Cc: devicet...@vger.kernel.org Cc: Rob Herring Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Fugang Duan Cc: Stefan Agner Cc: Mingkai Hu Cc: Yangbo Lu Signed-off-by: Dong Aisheng --- Documentation/devicetree/bindings/serial/fsl-lpuart.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt index c95005e..a1252a0 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt @@ -6,6 +6,8 @@ Required properties: on Vybrid vf610 SoC with 8-bit register organization - "fsl,ls1021a-lpuart" for lpuart compatible with the one integrated on LS1021A SoC with 32-bit big-endian register organization + - "fsl,imx7ulp-lpuart" for lpuart compatible with the one integrated +on i.MX7ULP SoC with 32-bit little-endian register organization - reg : Address and length of the register set for the device - interrupts : Should contain uart interrupt - clocks : phandle + clock specifier pairs, one for each entry in clock-names -- 2.7.4
[PATCH 2/6] tty: serial: lpuart: add little endian 32 bit register support
It's based on the exist lpuart32 read/write implementation.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby (supporter:TTY LAYER)
Cc: Fugang Duan
Cc: Stefan Agner
Cc: Mingkai Hu
Cc: Yangbo Lu
Signed-off-by: Dong Aisheng
---
drivers/tty/serial/fsl_lpuart.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index cd4e905..bddd041 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -231,6 +231,8 @@
#define DEV_NAME "ttyLP"
#define UART_NR6
+static bool lpuart_is_be;
+
struct lpuart_port {
struct uart_portport;
struct clk *clk;
@@ -260,6 +262,7 @@ struct lpuart_port {
struct lpuart_soc_data {
boolis_32;
+ boolis_be;
};
static struct lpuart_soc_data vf_data = {
@@ -268,6 +271,7 @@ static struct lpuart_soc_data vf_data = {
static struct lpuart_soc_data ls_data = {
.is_32 = true,
+ .is_be = true,
};
static const struct of_device_id lpuart_dt_ids[] = {
@@ -282,12 +286,15 @@ static void lpuart_dma_tx_complete(void *arg);
static u32 lpuart32_read(void __iomem *addr)
{
- return ioread32be(addr);
+ return lpuart_is_be ? ioread32be(addr) : readl(addr);
}
static void lpuart32_write(u32 val, void __iomem *addr)
{
- iowrite32be(val, addr);
+ if (lpuart_is_be)
+ iowrite32be(val, addr);
+ else
+ writel(val, addr);
}
static void lpuart_stop_tx(struct uart_port *port)
@@ -2000,6 +2007,7 @@ static int lpuart_probe(struct platform_device *pdev)
}
sport->port.line = ret;
sport->lpuart32 = sdata->is_32;
+ lpuart_is_be = sdata->is_be;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sport->port.membase = devm_ioremap_resource(&pdev->dev, res);
--
2.7.4
[PATCH 4/6] tty: serial: lpuart: add imx7ulp support
The lpuart of imx7ulp is basically the same as ls1021a. It's also
32 bit width register, but unlike ls1021a, it's little endian.
Besides that, imx7ulp lpuart has a minor different register layout
from ls1021a that it has four extra registers (verid, param, global,
pincfg) located at the beginning of register map, which are currently
not used by the driver and less to be used later.
To ease the register difference handling, we add a reg_off member
in lpuart_soc_data structure to represent if the normal
lpuart32_{read|write} requires plus a offset to hide the issue.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Fugang Duan
Cc: Stefan Agner
Cc: Mingkai Hu
Cc: Yangbo Lu
Signed-off-by: Dong Aisheng
---
drivers/tty/serial/fsl_lpuart.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index bddd041..1cdb3f9 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -231,7 +231,11 @@
#define DEV_NAME "ttyLP"
#define UART_NR6
+/* IMX lpuart has four extra unused regs located at the beginning */
+#define IMX_REG_OFF0x10
+
static bool lpuart_is_be;
+static u8 lpuart_reg_off;
struct lpuart_port {
struct uart_portport;
@@ -263,6 +267,7 @@ struct lpuart_port {
struct lpuart_soc_data {
boolis_32;
boolis_be;
+ u8 reg_off;
};
static struct lpuart_soc_data vf_data = {
@@ -272,11 +277,19 @@ static struct lpuart_soc_data vf_data = {
static struct lpuart_soc_data ls_data = {
.is_32 = true,
.is_be = true,
+ .reg_off = 0x0,
+};
+
+static struct lpuart_soc_data imx_data = {
+ .is_32 = true,
+ .is_be = false,
+ .reg_off = IMX_REG_OFF,
};
static const struct of_device_id lpuart_dt_ids[] = {
{ .compatible = "fsl,vf610-lpuart", .data = &vf_data, },
{ .compatible = "fsl,ls1021a-lpuart", .data = &ls_data, },
+ { .compatible = "fsl,imx7ulp-lpuart", .data = &imx_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, lpuart_dt_ids);
@@ -286,15 +299,16 @@ static void lpuart_dma_tx_complete(void *arg);
static u32 lpuart32_read(void __iomem *addr)
{
- return lpuart_is_be ? ioread32be(addr) : readl(addr);
+ return lpuart_is_be ? ioread32be(addr + lpuart_reg_off) :
+ readl(addr + lpuart_reg_off);
}
static void lpuart32_write(u32 val, void __iomem *addr)
{
if (lpuart_is_be)
- iowrite32be(val, addr);
+ iowrite32be(val, addr + lpuart_reg_off);
else
- writel(val, addr);
+ writel(val, addr + lpuart_reg_off);
}
static void lpuart_stop_tx(struct uart_port *port)
@@ -2008,6 +2022,7 @@ static int lpuart_probe(struct platform_device *pdev)
sport->port.line = ret;
sport->lpuart32 = sdata->is_32;
lpuart_is_be = sdata->is_be;
+ lpuart_reg_off = sdata->reg_off;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sport->port.membase = devm_ioremap_resource(&pdev->dev, res);
--
2.7.4
[PATCH 5/6] tty: serial: lpuart: add earlycon support for imx7ulp
earlycon is executed quite early before the device tree probe,
so we need configure the correct reg_off for imx7ulp during
early console setup.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Fugang Duan
Cc: Stefan Agner
Cc: Mingkai Hu
Cc: Yangbo Lu
Signed-off-by: Dong Aisheng
---
drivers/tty/serial/fsl_lpuart.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 1cdb3f9..5b485e8 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1978,8 +1978,20 @@ static int __init lpuart32_early_console_setup(struct
earlycon_device *device,
return 0;
}
+static int __init lpuart32_imx_early_console_setup(struct earlycon_device
*device,
+ const char *opt)
+{
+ if (!device->port.membase)
+ return -ENODEV;
+
+ lpuart_reg_off = IMX_REG_OFF;
+ device->con->write = lpuart32_early_write;
+
+ return 0;
+}
OF_EARLYCON_DECLARE(lpuart, "fsl,vf610-lpuart", lpuart_early_console_setup);
OF_EARLYCON_DECLARE(lpuart32, "fsl,ls1021a-lpuart",
lpuart32_early_console_setup);
+OF_EARLYCON_DECLARE(lpuart32, "fsl,imx7ulp-lpuart",
lpuart32_imx_early_console_setup);
EARLYCON_DECLARE(lpuart, lpuart_early_console_setup);
EARLYCON_DECLARE(lpuart32, lpuart32_early_console_setup);
--
2.7.4
[PATCH 6/6] tty: serial: lpuart: add a more accurate baud rate calculation method
On new LPUART versions, the oversampling ratio for the receiver can be
changed from 4x (00011) to 32x (1) which could help us get a more
accurate baud rate divider.
The idea is to use the best OSR (over-sampling rate) possible.
Note, OSR is typically hard-set to 16 in other LPUART instantiations.
Loop to find the best OSR value possible, one that generates minimum
baud diff iterate through the rest of the supported values of OSR.
Currently only i.MX7ULP is using it.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Fugang Duan
Cc: Stefan Agner
Cc: Mingkai Hu
Cc: Yangbo Lu
Signed-off-by: Dong Aisheng
---
drivers/tty/serial/fsl_lpuart.c | 85 ++---
1 file changed, 79 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 5b485e8..6b2abb7 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -140,6 +140,8 @@
#define UARTBAUD_SBNS 0x2000
#define UARTBAUD_SBR 0x
#define UARTBAUD_SBR_MASK 0x1fff
+#define UARTBAUD_OSR_MASK 0x1f
+#define UARTBAUD_OSR_SHIFT 24
#define UARTSTAT_LBKDIF0x8000
#define UARTSTAT_RXEDGIF 0x4000
@@ -1508,6 +1510,72 @@ lpuart_set_termios(struct uart_port *port, struct
ktermios *termios,
}
static void
+lpuart32_serial_setbrg(struct lpuart_port *sport, unsigned int baudrate)
+{
+ u32 sbr, osr, baud_diff, tmp_osr, tmp_sbr, tmp_diff, tmp;
+ u32 clk = sport->port.uartclk;
+
+ /*
+* The idea is to use the best OSR (over-sampling rate) possible.
+* Note, OSR is typically hard-set to 16 in other LPUART instantiations.
+* Loop to find the best OSR value possible, one that generates minimum
+* baud_diff iterate through the rest of the supported values of OSR.
+*
+* Calculation Formula:
+* Baud Rate = baud clock / ((OSR+1) × SBR)
+*/
+ baud_diff = baudrate;
+ osr = 0;
+ sbr = 0;
+
+ for (tmp_osr = 4; tmp_osr <= 32; tmp_osr++) {
+ /* calculate the temporary sbr value */
+ tmp_sbr = (clk / (baudrate * tmp_osr));
+ if (tmp_sbr == 0)
+ tmp_sbr = 1;
+
+ /*
+* calculate the baud rate difference based on the temporary
+* osr and sbr values
+*/
+ tmp_diff = clk / (tmp_osr * tmp_sbr) - baudrate;
+
+ /* select best values between sbr and sbr+1 */
+ tmp = clk / (tmp_osr * (tmp_sbr + 1));
+ if (tmp_diff > (baudrate - tmp)) {
+ tmp_diff = baudrate - tmp;
+ tmp_sbr++;
+ }
+
+ if (tmp_diff <= baud_diff) {
+ baud_diff = tmp_diff;
+ osr = tmp_osr;
+ sbr = tmp_sbr;
+ }
+ }
+
+ /* handle buadrate outside acceptable rate */
+ if (baud_diff > ((baudrate / 100) * 3))
+ dev_warn(sport->port.dev,
+"unacceptable baud rate difference of more than
3%%\n");
+
+ tmp = lpuart32_read(sport->port.membase + UARTBAUD);
+
+ if ((osr > 3) && (osr < 8))
+ tmp |= UARTBAUD_BOTHEDGE;
+
+ tmp &= ~(UARTBAUD_OSR_MASK << UARTBAUD_OSR_SHIFT);
+ tmp |= (((osr-1) & UARTBAUD_OSR_MASK) << UARTBAUD_OSR_SHIFT);
+
+ tmp &= ~UARTBAUD_SBR_MASK;
+ tmp |= sbr & UARTBAUD_SBR_MASK;
+
+ tmp &= ~(UARTBAUD_TDMAE | UARTBAUD_RDMAE);
+
+ lpuart32_write(tmp, sport->port.membase + UARTBAUD);
+}
+
+static void
lpuart32_set_termios(struct uart_port *port, struct ktermios *termios,
struct ktermios *old)
{
@@ -1613,12 +1681,17 @@ lpuart32_set_termios(struct uart_port *port, struct
ktermios *termios,
lpuart32_write(old_ctrl & ~(UARTCTRL_TE | UARTCTRL_RE),
sport->port.membase + UARTCTRL);
- sbr = sport->port.uartclk / (16 * baud);
- bd &= ~UARTBAUD_SBR_MASK;
- bd |= sbr & UARTBAUD_SBR_MASK;
- bd |= UARTBAUD_BOTHEDGE;
- bd &= ~(UARTBAUD_TDMAE | UARTBAUD_RDMAE);
- lpuart32_write(bd, sport->port.membase + UARTBAUD);
+ if (of_device_is_compatible(port->dev->of_node, "fsl,imx7ulp-lpuart")) {
+ lpuart32_serial_setbrg(sport, baud);
+ } else {
+ sbr = sport->port.uartclk / (16 * baud);
+ bd &= ~UARTBAUD_SBR_MASK;
+ bd |= sbr & UARTBAUD_SBR_MASK;
+ bd |= UARTBAUD_BOTHEDGE;
+ bd &= ~(UARTBAUD_TDMAE | UARTBAUD_RDMAE);
+ lpuart32_write(bd, sport->port.membase + UARTBAUD);
+ }
+
lpuart32_write(modem, sport->port.membase + UARTMODIR);
lpuart32_write(ctrl, sport->port.membase + UARTCTRL);
/* restore control register */
--
2.7.4
Re: [PATCH v2] usb: cdc-wdm: use memdup_user
Am Montag, den 08.05.2017, 23:14 +0800 schrieb Geliang Tang: > Use memdup_user() helper instead of open-coding to simplify the code. > > Signed-off-by: Geliang Tang Acked-by: Oliver Neukum
Re: [PATCH] wil6210: Replace five seq_puts() calls by seq_putc()
On Tue, 2017-05-09 at 09:50 +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 8 May 2017 22:22:04 +0200 > > Five single characters (line breaks) should be put into a sequence. > Thus use the corresponding function "seq_putc". Please stop, this isn't really an issue worth worrying about. johannes
Re: BUG: rcu_sched detected stalls on CPUs
On 2017-05-08 16:24, Paul E. McKenney wrote: On Mon, May 08, 2017 at 09:43:15AM +0300, mi...@stz-bg.com wrote: On 2017-01-20 17:19, Steven Rostedt wrote: >On Fri, 20 Jan 2017 10:43:50 +0200 >mi...@stz-bg.com wrote: > >>[1.] One line summary of the problem: >> >>rcu_sched detected stalls on CPUs and few minutes server not respond. > >Is this reproducible? Or was this a one time ordeal? > >> >>[2.] Full description of the problem/report: >> >>Load of my server (postgres database) isnt big less then 0.50 and when >>error occured rcu_sched detected stalls on CPUs >>server freeze and nothing is work for 3-5 minute. >>No network, no video signal, no keyboard, no mouse. Nothing is worked. >>After these few minutes everything continue normal. >>This usual is happend once per day. When I check in google find a lots >>of ppl complain of this error, but no solution. >>Do any one know can help me to resolve it ? I spoke with few >>friends and >>they trying to convince me the problem is in CPU. >>I did not believe after a 3 years working CPU suddenly stop working >>correctly, but I might be wrong. >> >>[3.] Keywords (i.e., modules, networking, kernel): >> >>kernel >> >>[4.] Kernel information >>[4.1.] Kernel version (from /proc/version): >> >>Linux version 4.4.38 (root@hive64) (gcc version 5.4.0 (GCC) ) #2 >>SMP Sun >>Dec 11 16:11:02 CST 2016 >> > >Have you tried a newer version of the kernel? > >-- Steve Hello, yesterday I change to new kernel: 4.9.26 and still no effect. I trying to figure out what I need to buy because I read on google a lots of posts about that problem, some ppl suggest is BIOS firmware bug, some ppl tell that when they swap CPU problem is resolved. May be problem was started when I first time boot 4.x kernel and there have cpu microcode updates. Im 3.x kernels this feature was not in kernel, but I don't know, only guess. Can some one point me clearly: You need to change this one and problem will be solved ? Looking back at your earlier email, I see the following: [Wed Jan 4 10:19:12 2017] rcu_sched kthread starved for 60004 jiffies! g61967937 c61967936 f0x0 s3 ->state=0x1 That indicates that the task "rcu_sched" isn't being allowed to run. The "->state=0x1" indicates that this task is currently asleep and the "s3" indicates that it is looking to start a grace period, but has not progressed through this task. My guess is that your system get very busy, and that rcu_sched's normal scheduling priority is not sufficient for it to be allowed to run. I therefore suggest that you try raising the rcu_sched task's priority. You can find this task like this: ps -ef | grep rcu_sched On my laptop, I get this: $ ps -ef | grep rcu_sched root 7 2 0 Apr11 ?00:19:19 [rcu_sched] paulmck 18307 22926 0 06:11 pts/35 00:00:00 grep --color=auto rcu_sche You can use the chrt command to set the priority. For example, given that on my laptop, rcu_sched is PID 7: sudo chrt -f -p 1 7 You can double-check as follows: $ chrt -p 7 pid 7's current scheduling policy: SCHED_FIFO pid 7's current scheduling priority: 1 Does that help? Thanx, Paul Hi, interesting ... I change priority as you suggest and will keep you in touch if the problem happens again because I cant reproduce it. Replay on your next email, I don't have any virtual servers / guest os on the server. It's server with only one process - redis server and in this time when error it's happened actually one of other servers start loading data into redis sever. Data is small 3-4 mil. keys every key contain around 150 symbols. I have that problem on two servers, next server is database server with postgresql and that problem happened more often, usual once per day or for few days. I never play before with changing priority of processes. When I check iLO log I saw logged error: power lost but server does not lost the power actually, it's just stop respond for 2-3 minutes and then continue normal operation with uptime more then 100 days. Thanks for your suggestion. Regards, Mitko [239940.067938] clocksource: timekeeping watchdog on CPU26: Marking clocksource 'tsc' as unstable because the skew is too large: [239940.067943] clocksource: 'hpet' wd_now: ecb521ce wd_last: ca45912d mask: [239940.067946] clocksource: 'tsc' cs_now: 2d12df5f88d08 cs_last: 29fffbe2d36d6 mask: [239940.068357] clocksource: Switched to clocksource hpet [24.066457] INFO: rcu_sched detected stalls on CPUs/tasks: [24.066488] 2-...: (38 GPs behind) idle=f1a/0/0 softirq=2417028/2417028 fqs=0 [24.066491] 3-...: (27 GPs behind) idle=0bc/0/0 softirq=3076046/3076047 fqs=0 [24.066494] 4-...: (1006 GPs behind) idle=308/0/0 softirq=1474922/1474922 fqs=0 [24.066497] 5-...: (8034 GPs behind) idle=7b4/0/0 softirq=69
[PATCH 1/6] tty: serial: lpuart: introduce lpuart_soc_data to represent SoC property
This is used to dynamically check the SoC specific lpuart properies.
Currently only the checking of 32 bit register width is added which
functions the same as before. More will be added later for supporting
new chips.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Fugang Duan
Cc: Stefan Agner
Cc: Mingkai Hu
Cc: Yangbo Lu
Signed-off-by: Dong Aisheng
---
drivers/tty/serial/fsl_lpuart.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 15df1ba7..cd4e905 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -258,13 +258,21 @@ struct lpuart_port {
wait_queue_head_t dma_wait;
};
+struct lpuart_soc_data {
+ boolis_32;
+};
+
+static struct lpuart_soc_data vf_data = {
+ .is_32 = false,
+};
+
+static struct lpuart_soc_data ls_data = {
+ .is_32 = true,
+};
+
static const struct of_device_id lpuart_dt_ids[] = {
- {
- .compatible = "fsl,vf610-lpuart",
- },
- {
- .compatible = "fsl,ls1021a-lpuart",
- },
+ { .compatible = "fsl,vf610-lpuart", .data = &vf_data, },
+ { .compatible = "fsl,ls1021a-lpuart", .data = &ls_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, lpuart_dt_ids);
@@ -1971,6 +1979,9 @@ static struct uart_driver lpuart_reg = {
static int lpuart_probe(struct platform_device *pdev)
{
+ const struct of_device_id *of_id = of_match_device(lpuart_dt_ids,
+ &pdev->dev);
+ const struct lpuart_soc_data *sdata = of_id->data;
struct device_node *np = pdev->dev.of_node;
struct lpuart_port *sport;
struct resource *res;
@@ -1988,7 +1999,7 @@ static int lpuart_probe(struct platform_device *pdev)
return ret;
}
sport->port.line = ret;
- sport->lpuart32 = of_device_is_compatible(np, "fsl,ls1021a-lpuart");
+ sport->lpuart32 = sdata->is_32;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sport->port.membase = devm_ioremap_resource(&pdev->dev, res);
--
2.7.4
[PATCH v2] platform/x86: peaq-wmi: Add new peaq-wmi driver
PEAQ is a new European OEM, I've bought one of their 2-in-1 x86
devices, which is actually quite a nice device. Under Windows it has
Dolby software for "better" sound and you can select different equalizer
presets using a special button.
This WMI interface for this button is not really nice, as it does not do
notifies (it really does not I tripple checked), but since I had already
figured out the entire WMI interface for this I decided to go the full
mile anyways and also implent a WMI based input driver for this using
input_polldev since, well, we need to poll.
This commit adds support for this button making it report KEY_SOUND input
events. KEY_SOUND is already used in various places to switch sound into
theatre mode and things like that so it seems appropriate here.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Drop unneeded #include
-Add and use PEAQ_POLL_IGNORE_MS and PEAQ_POLL_MAX_MS defines
-Make globals static
-Call input_sync between reporting the button down and up
-Ignore events for at least 1 poll after an event even if the user has set
poll_interval > PEAQ_POLL_IGNORE_MS
---
drivers/platform/x86/Kconfig| 7 +++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/peaq-wmi.c | 97 +
3 files changed, 105 insertions(+)
create mode 100644 drivers/platform/x86/peaq-wmi.c
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index be2ffbd6eb6c..2bac2b2644f9 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -660,6 +660,13 @@ config MSI_WMI
To compile this driver as a module, choose M here: the module will
be called msi-wmi.
+config PEAQ_WMI
+ tristate "PEAQ 2-in-1 WMI hotkey driver"
+ depends on ACPI_WMI
+ depends on INPUT
+ help
+Say Y here if you want to support WMI-based hotkeys on PEAQ 2-in-1s.
+
config TOPSTAR_LAPTOP
tristate "Topstar Laptop Extras"
depends on ACPI
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index de4ffb594ba5..02487f95dd27 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_PANASONIC_LAPTOP)+= panasonic-laptop.o
obj-$(CONFIG_INTEL_MENLOW) += intel_menlow.o
obj-$(CONFIG_ACPI_WMI) += wmi.o
obj-$(CONFIG_MSI_WMI) += msi-wmi.o
+obj-$(CONFIG_PEAQ_WMI) += peaq-wmi.o
obj-$(CONFIG_SURFACE3_WMI) += surface3-wmi.o
obj-$(CONFIG_TOPSTAR_LAPTOP) += topstar-laptop.o
diff --git a/drivers/platform/x86/peaq-wmi.c b/drivers/platform/x86/peaq-wmi.c
new file mode 100644
index ..47b36b2fa895
--- /dev/null
+++ b/drivers/platform/x86/peaq-wmi.c
@@ -0,0 +1,97 @@
+/*
+ * PEAQ 2-in-1 WMI hotkey driver
+ * Copyright (C) 2017 Hans de Goede
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#define PEAQ_DOLBY_BUTTON_GUID "ABBC0F6F-8EA1-11D1-00A0-C9062910"
+#define PEAQ_DOLBY_BUTTON_METHOD_ID5
+#define PEAQ_POLL_INTERVAL_MS 250
+#define PEAQ_POLL_IGNORE_MS500
+#define PEAQ_POLL_MAX_MS 1000
+
+MODULE_ALIAS("wmi:"PEAQ_DOLBY_BUTTON_GUID);
+
+static struct input_polled_dev *peaq_poll_dev;
+static unsigned int peaq_ignore_events_counter;
+
+/*
+ * The Dolby button (yes really a Dolby button) causes an ACPI variable to get
+ * set on both press and release. The WMI method checks and clears that flag.
+ * So for a press + release we will get back One from the WMI method either
once
+ * (if polling after the release) or twice (polling between press and release).
+ * We ignore events for 0.5s after the first event to avoid reporting 2
presses.
+ */
+static void peaq_wmi_poll(struct input_polled_dev *dev)
+{
+ union acpi_object obj;
+ struct acpi_buffer buffer = { sizeof(obj), &obj };
+ acpi_status status;
+
+ status = wmi_evaluate_method(PEAQ_DOLBY_BUTTON_GUID, 1,
+PEAQ_DOLBY_BUTTON_METHOD_ID,
+NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ return;
+
+ if (obj.type != ACPI_TYPE_INTEGER) {
+ dev_err(&peaq_poll_dev->input->dev,
+ "Error WMBC did not return an integer\n");
+ return;
+ }
+
+ if (peaq_ignore_events_counter && --peaq_ignore_events_counter > 0)
+ return;
+
+ if (obj.integer.value) {
+ input_event(peaq_poll_dev->input, EV_KEY, KEY_SOUND, 1);
+ input_sync(peaq_poll_dev->input);
+ input_event(peaq_poll_dev->input, EV_KEY, KEY_SOUND, 0);
+ input_sync(peaq_poll_dev->input);
+ peaq_ignore_events_counter = max(1u,
+ PEAQ_POLL_IGNORE_MS / peaq_poll_dev
Re: [PATCH 1/2] block, dax: move "select DAX" from BLOCK to FS_DAX
Hi Dan,
On Tue, May 9, 2017 at 12:36 AM, kbuild test robot wrote:
> [auto build test ERROR on linus/master]
> [also build test ERROR on next-20170508]
> [cannot apply to v4.11]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Dan-Williams/block-dax-move-select-DAX-from-BLOCK-to-FS_DAX/20170509-051522
> config: parisc-c3000_defconfig (attached as .config)
> compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=parisc
>
> All errors (new ones prefixed by >>):
>
>fs/built-in.o: In function `bdev_dax_supported':
>>> (.text.bdev_dax_supported+0x4c): undefined reference to `dax_get_by_host'
>fs/built-in.o: In function `bdev_dax_supported':
>>> (.text.bdev_dax_supported+0x5c): undefined reference to `dax_read_lock'
>fs/built-in.o: In function `bdev_dax_supported':
>>> (.text.bdev_dax_supported+0x7c): undefined reference to `dax_direct_access'
>fs/built-in.o: In function `bdev_dax_supported':
>>> (.text.bdev_dax_supported+0x88): undefined reference to `dax_read_unlock'
>fs/built-in.o: In function `bdev_dax_supported':
>>> (.text.bdev_dax_supported+0x90): undefined reference to `put_dax'
I ran into the same issue if CONFIG_DAX=m (it's still selected by some other
modular symbol). #if IS_ENABLED(CONFIG_DAX) is true in the modular case, so
the dummies provided by include/linux/dax.h are not used.
However, while changing it to #ifdef CONFIG_DAX allows to build vmlinux, it
leads to other issues as DAX is compiled as a module:
drivers/dax/super.c:35: error: redefinition of ‘dax_read_lock’
include/linux/dax.h:30: error: previous definition of
‘dax_read_lock’ was here
Yes, calling into optional modular code from builtin code in fs/blockdev.c is
tricky ;-( Perhaps you can make bdev_dax_supported() a small wrapper
that calls into the real code through a function pointer, when the DAX module
is available?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: qca_debug: Reduce function calls for sequence output in qcaspi_info_show()
> The only benefit is a little bit higher performance. I would prefer such a small code reduction. I am not so concerned about an other readability impression at this place. > But for debugfs this won't be necessary. I would appreciate also another improvement there. Regards, Markus
Re: [PATCH v1] ACPI: Switch to use generic UUID API
Hi,
Andy Shevchenko writes:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
> get rid of it.
>
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
>
> Cc: Rafael J. Wysocki
> Cc: Mika Westerberg
> Cc: Borislav Petkov
> Cc: Dan Williams
> Cc: Amir Goldstein
> Cc: Jarkko Sakkinen
> Cc: Jani Nikula
> Cc: Ben Skeggs
> Cc: Benjamin Tissoires
> Cc: Joerg Roedel
> Cc: Adrian Hunter
> Cc: Yisen Zhuang
> Cc: Bjorn Helgaas
> Cc: Zhang Rui
> Cc: Felipe Balbi
> Cc: Mathias Nyman
> Cc: Heikki Krogerus
> Cc: Liam Girdwood
> Cc: Mark Brown
> Signed-off-by: Andy Shevchenko
> diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> index a15ec71d0423..6b5284ec76df 100644
> --- a/drivers/usb/dwc3/dwc3-pci.c
> +++ b/drivers/usb/dwc3/dwc3-pci.c
> @@ -56,7 +56,7 @@ struct dwc3_pci {
> struct platform_device *dwc3;
> struct pci_dev *pci;
>
> - u8 uuid[16];
> + uuid_le uuid;
>
> unsigned int has_dsm_for_pm:1;
> };
> @@ -118,7 +118,7 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
>
> if (pdev->device == PCI_DEVICE_ID_INTEL_BXT ||
> pdev->device == PCI_DEVICE_ID_INTEL_BXT_M) {
> - acpi_str_to_uuid(PCI_INTEL_BXT_DSM_UUID, dwc->uuid);
> + uuid_le_to_bin(PCI_INTEL_BXT_DSM_UUID, &dwc->uuid);
> dwc->has_dsm_for_pm = true;
> }
>
> @@ -288,7 +288,7 @@ static int dwc3_pci_dsm(struct dwc3_pci *dwc, int param)
> tmp.type = ACPI_TYPE_INTEGER;
> tmp.integer.value = param;
>
> - obj = acpi_evaluate_dsm(ACPI_HANDLE(&dwc->pci->dev), dwc->uuid,
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(&dwc->pci->dev), &dwc->uuid,
> 1, PCI_INTEL_BXT_FUNC_PMU_PWR, &argv4);
> if (!obj) {
> dev_err(&dwc->pci->dev, "failed to evaluate _DSM\n");
Acked-by: Felipe Balbi
--
balbi
Re: [PATCH] staging : rtl8188eu : remove unnecessary else
On Mon, May 08, 2017 at 02:13:00PM +0530, Surender Polsani wrote:
> according to coding style else is not generally
> useful after a break or return
>
> Signed-off-by: Surender Polsani
> ---
> drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
> b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
> index d04b7fb..7420f55 100644
> --- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
> +++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
> @@ -212,8 +212,7 @@ u8 rtw_hal_antdiv_before_linked(struct adapter *Adapter)
>
> rtw_antenna_select_cmd(Adapter, dm_swat_tbl->CurAntenna, false);
> return true;
> - } else {
> + }
> dm_swat_tbl->SWAS_NoLink_State = 0;
> return false;
> - }
Nope.
I think you really need to learn C programming before you send any more
patches.
regards,
dan carpenter
Re: [PATCH v2 29/30] dt-bindings: add vendor prefix for bananapi
Hi, On Mon, May 1, 2017 at 2:58 PM, Sean Wang wrote: > On Fri, 2017-04-28 at 15:37 -0500, Rob Herring wrote: >> On Wed, Apr 26, 2017 at 05:26:13PM +0800, sean.w...@mediatek.com wrote: >> > From: Sean Wang >> > >> > Banana Pi team in Sinovoip Co., Limited which are dedicated to >> > design and manufacture open hardware product. >> > >> > Website: http://www.banana-pi.org/ >> > >> > Signed-off-by: Sean Wang >> > --- >> > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt >> > b/Documentation/devicetree/bindings/vendor-prefixes.txt >> > index ec0bfb9..8ca0f3c 100644 >> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt >> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt >> > @@ -44,6 +44,7 @@ avia avia semiconductor >> > avic Shanghai AVIC Optoelectronics Co., Ltd. >> > axentiaAxentia Technologies AB >> > axis Axis Communications AB >> > +bananapi Banana Pi SINOVOP CO., LIMITED >> >> s/SINOVOP/SINOVOIP/ > > Hi Rob, > > thanks for your careful reviewing , i will correct it in the next > version. > > BTW, Could those related dts changes go through your tree if everything > looks good? Because I find Matthias have been inactive for a while and > the latest branch in his tree seems still staying on 4.10. Chiming in from the linux-sunxi side. We've been using the "lemaker" prefix for the original Banana Pi, and the "sinovoip" prefix for all the later ones by SINOVOIP. Both prefixes are still undocumented. Given the complicated history behind the Banana Pi brand, do we know what prefix they prefer, and what company should be tied to it? Thanks ChenYu > > Sean > >> >> > boeBOE Technology Group Co., Ltd. >> > bosch Bosch Sensortec GmbH >> > boundary Boundary Devices Inc. >> > -- >> > 1.9.1 >> > > > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 3/9] VFS: Introduce a mount context
On Tue, May 9, 2017 at 12:57 AM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> > + (3) Validate and pre-process the mount context.
>>
>> (3.5) Create super block
>>
>> I think this need to be triggered by something like a "commit" command
>> from userspace. Basically this is where the options are atomically
>> set on the new (create) or existing (reconfigure) superblock.
>
> Why do you need to expose this step to userspace? Assuming in the "new" case
> you do, say:
>
> fd = fsopen("nfs");
> write(fd, "s foo.bar:/bar", ...);
> write(fd, "o intr", ...);
> write(fd, "o fsc", ...);
> ...
> write(fd, "c", ...); /* commit operation to get a superblock */
> fsmount(fd, AT_FDCWD, "/mnt"); /* mount the superblock we just got */
>
> Then the "commit" op is dissimilar to "mount -o remount" since remount may
> alter the superblock parameters *and* the mountpoint parameters, but commit
> can only affect the superblock.
Forget remount, it's a historical remnant. We need fsreconfig(sb) and
setmntattr(mnt). They are changing properties of different objects.
Remount is like fcntl(fd, F_SETFL) and fchmod(fd, ...) rolled into
one. They have nothing in common except the fact that the old
mount(2) API included both in one single operation, and I'm sure that
was a "oh we don't want to introduce a new flag for this, so lets
reuse the old one" sort of design decision.
>
> On the other hand, I could see that you might want to do:
>
> fd = fsopen("nfs");
> ...
> write(fd, "c", ...); /* commit operation to get a superblock */
> fstatfs(fd, &buf); /* get info about the superblock */
> fsmount(fd, AT_FDCWD, "/mnt"); /* mount the superblock we just got */
>
>> > + (4) Perform the mount.
>> > +
>> > + (5) Return an error message attached to the mount context.
>>
>> Swap the order of the above. There's no fs specific actions performed
>> at fsmount() time, and normal errno reporting should be perfectly
>> fine.
>
> There's no reason not to allow error messages to be attached by the actual
> vfsmount creation and insertion - and reasons that one might want to do so.
> Think LSMs, for instance. We don't look up the mountpoint until this point,
> and so we can't do the security checks on them till this point. It could make
> it easier to debug problems if we can return a more comprehensive message at
> this point.
I think that's crazy. We don't return detailed errors for any other
syscall for path lookup, so why would path lookup for mount be
special.
And why would
fd = open("/foo/bar", O_PATH);
fsmount(fsfd, fd, NULL);
behave differently from
fsmount(fsfd, -1, "/foo/bar");
?
>
>> I think reconfigure (don't call it remount, there's no "mounting"
>> going on there)
>
> There's adjustment of the vfsmount structure too; besides, it is called
> MS_REMOUNT in the UAPI and "mount -o remount", so we're somewhat stuck with
> the label whether we like it or not.
Oh, uapi compatibility: they can use the old mount(2) API for that and
introduce saner utils for the new stuff. I'm sure we don't need to be
100% feature compatible with old mount(2).
What we need is mount(2) to stay 100% compatible with itself while the
kernel internal APIs are reshuffled.
>> should start out with a context populated with with the current state of the
>> superblock.
>
> Hence why ->fsopen() takes a super_block parameter.
>
>> User can then reset and start over
>
> No, not really. You cannot reset all options - the source for example,
> probably has to remain the same. IP addresses on NFS mounts possibly should
> remain the same - though I can see situations where it might be convenient to
> change these.
Well, the current remount API is like that: you give a new set of
options (i.e. reset and replace anything that can be changed and leave
the rest). Obviously "reset options" wouldn't allow you to change
options that cannot be changed.
>
>> or individually add/remove options.
>
> This is very per-filesystem-type dependent.
So say we have commands like
"o+ foo"
"o- bar"
The generic option parser would just add or remove the option in the
current set of options, and commit would just call ->remount_fs() with
the new set of options. It would probably not work for the NFS case,
but that's okay, NFS can implement its own option parsing.
>> This should be a good place to allow querying the options as well, as Karel
>> suggested.
>
> I'm not sure it's worth the code unless we allow opening extant mounts and
> querying using this mechanism.
I'm saying we should allow opening an existent superblock and allow
query and change of options.
>> Then when the configuration is finished the changes are committed to the
>> superblock.
>
> You're going a lot beyond remount here. Remount can, in one go, change some
> options which are superblock-only, some options which are mountpoint-only and
> at least one which crosses both domains.
We'll
Re: GPU-DRM-STI: Fine-tuning for some function implementations
2017-05-06 19:00 GMT+02:00 SF Markus Elfring : >>> 1. I suggest to combine a few functions into fewer ones. >>>* Do you spot any programming mistakes in these concrete cases? >> >> Not in the patches I skimmed. > > Thanks for such feedback. > > >> However, your history of breaking code tells me that there have been mistakes >> missed in the past. > > I admit that I had my own share of software development hiccups. I would also > like to reduce them. But a probability remains that I will stumble on > various glitches as usual. > > >> As such, I'm not willing to take untested code from you that does not change >> functionality at the risk of breaking something that is currently working. > > I imagine that the shown software refactoring will improve the affected > sequence outputs in useful ways, won't it? > > >> This is non-negotiable. > > It seems that we have got different views around the ways to get to acceptable > final system test results. > > >> As I said before, if you test it, I'll consider it. As sti driver maintainer I will test those patches. If their are ok and get some other reviewed/ack I will use them for myself training on how push patches in drm-misc. Benjamin > > I got a few doubts for this information. If you find my software development > reputation so questionable, I assume that you would not trust any tests > that I would try out on my own. > > >> If you are unwilling to test your changes, I'm unwilling to apply them. > > I guess that the desired willingness will depend on a test environment > which will be trusted by all involved parties. Other incentives might > also matter. > > >> I'm not interested in double checking all of your work, and fixing your bugs >> for no functional benefit. > > Do you care for improvements in the implementation of logging functions? > > >> I find less value in these patches if they're from someone seemingly >> trying to rack up patch count. > > I am picking special source code search patterns up. > The evolving development tools can point then hundreds of source files > out which contain similar update candidates. > I found also a few spelling weaknesses while I was looking around > in affected source code. These tools can also increase the awareness > for such change possibilities, can't they? > > Regards, > Markus
Re: [PATCH 0/4] S390: Fine-tuning for six function implementations
On 05/07/17 19:12, SF Markus Elfring wrote: From: Markus Elfring Date: Sun, 7 May 2017 19:00:09 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Combine two function calls into one in show_cacheinfo() Use seq_putc() in show_cpu_summary() Replace six seq_printf() calls by seq_puts() Combine two function calls into one at four places arch/s390/kernel/cache.c | 4 ++-- arch/s390/kernel/processor.c | 2 +- arch/s390/kernel/sysinfo.c | 25 +++-- 3 files changed, 14 insertions(+), 17 deletions(-) I'm sorry, I wouldn't normally respond to this, but I was put on the Cc after all so I'll give my feedback. I think these patches are a waste of time and a resources. It would be different if your patches fixed actual bugs. This is just mindless code transformations that MAY in the best case save a few bytes of code here and there (I don't know; you didn't say). But the potential gains from these incredibly numerous and tiny patches that don't fix anything are so small, it's a waste of time, bandwidth, and mental capacity for you and for everybody involved. I just searched my inbox for patches from you and you sent literally _hundreds_ over the past few days, all doing this crazy printf/puts/putc transformation. Another bit of searching and I see that I'm not the first one giving you this response: https://lkml.org/lkml/2017/1/23/383 - Jens Axboe https://lkml.org/lkml/2017/1/23/262 - Johannes Thumshirn https://lkml.org/lkml/2017/1/12/513 - Cyrille Pitchen https://lkml.org/lkml/2016/10/24/491 - Theodore Ts'o https://lkml.org/lkml/2016/10/7/148 - Dan Carpenter https://lkml.org/lkml/2016/9/14/58 - Christian Borntraeger ...and I'm sure there are many more. Vegard
Re: [PATCH] key: Convert big_key payload.data to struct
Kees Cook wrote: > This doesn't protect you against changes in struct path size, > though... the existing code (and this proposal) will break if that > ever happens... True - in which case you should kmalloc() it as Eric suggests. > What's the problem with defining the types at the top level? That > seems like a nice place to see them all at once. It means adding a bunch of dependencies to linux/key.h and union key_payload. Have you considered why we don't just put all the definitions for all the filesystems in linux/fs.h? By this logic it would seem like a nice place to see them all at once. David
[PATCH v2 0/2] extends PWM framework to support PWM dead-times
Hi all,
Please give feedback on these patches which extends PWM framework
in order to support PWM dead-times.
Since I didn't receive any inputs on RFC series I'm resending it as
normal patch series.
For a PWM controller with more than one output signals per PWM channel
dead-times are the delays introduced between the edges of the output
signals and the original signal introduced in dead-time generator
engine.
E.g. consider a PWM controller with a dead-time engine as in the following
diagram:
-
| |---> PWMH
PWM signal --->| Dead-time engine|
| |---> PWML
-
With no dead-time configured, the PWMH and PWML signals will be
complementary signals (rising and falling edges of PWMH and PWML
have opposite leves, same duration and same starting time) as
follows:
0DP
PWM signal __||||||||||___
PWMH __||||||||||___
__ ___
PWML ||||||||||
Where - 0 is the starting point of the signal
- D is the starting point of the duty-cycle
- P is the signal period
Based on the above diagram:
- rising edge dead-time - is the delay introduced in one of the
dead-time engine output signals; the delay is introduced after
rising edge of the original PWM signal
- falling edge dead-time - is the delay introduced in one of the
dead-time engine output signals; the delay is introduced after
the end of falling edge of the original PWM signal
The following diagram explain how PWM dead-times falls on some signals:
0DP
PWM signal __||||||||||___
__________
PWMH | |re| |__| |__| |__| |___
____________
PWML |__| |fe| |__| |__| |__|
In the upper diagram:
- re = rising edge = the delay between D point of the original PWM signal
(rising edge) and the starting point of the next edge of one of the PWM
dead-time engine output
- fe = falling edge = the delay between P point of the original PWM signal
(falling edge) and the starting point of the next edge of one of the PWM
dead-time engine output
To configure the PWM dead-times new inputs were added to sysfs,
in PWM subsystem, one for rising edge dead-time, one for falling
edge deadtime.
root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2#
ls -l
-r--r--r--1 root root 4096 Feb 10 10:00 capture
-rw-r--r--1 root root 4096 Feb 10 10:01 deadtime_fe
-rw-r--r--1 root root 4096 Feb 10 10:02 deadtime_re
-rw-r--r--1 root root 4096 Feb 10 10:00 duty_cycle
-rw-r--r--1 root root 4096 Feb 10 10:00 enable
-rw-r--r--1 root root 4096 Feb 10 10:00 period
-rw-r--r--1 root root 4096 Feb 10 10:00 polarity
drwxr-xr-x2 root root 0 Feb 10 10:00 power
-rw-r--r--1 root root 4096 Feb 10 10:00 uevent
The PWM dead-times are used in half bridge converters applications.
Thank you,
Claudiu Beznea
Changes since v1:
- fixed compilation warning
Changes since RFC patches:
- corrected the Documentation/pwm.txt
- in atmel-pwm.c check atmel_pwm->regs->dt before computing
dead-times or setting specific registers since the driver is
used by controllers witch supports dead-time configuration and
controller which does not.
Claudiu Beznea (2):
drivers: pwm: core: implement pwm dead-times
drivers: pwm: pwm-atmel: implement pwm dead-times
Documentation/pwm.txt | 55
drivers/pwm/core.c | 10 ++-
drivers/pwm/pwm-atmel.c | 62 ++---
drivers/pwm/sysfs.c | 74 +
include/linux/pwm.h | 36
5 files changed, 232 insertions(+), 5 deletions(-)
--
2.7.4
[PATCH] ARM: dts: bcm283x: Reserve first page for firmware
The Raspberry Pi startup stub files for multi-core BCM283X processors make the secondary CPUs spin until the corresponding mailbox is written. These stubs are loaded at physical address 0x0xxx (as seen by the ARMs), but this page will be reused by the kernel unless it is explicitly reserved, causing the waiting cores to execute random code. Use the /memreserve/ Device Tree directive to mark the first page as off-limits to the kernel. See: https://github.com/raspberrypi/linux/issues/1989 Signed-off-by: Phil Elwell --- arch/arm/boot/dts/bcm2710-rpi-3-b.dts | 4 arch/arm/boot/dts/bcm283x.dtsi| 2 ++ 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/bcm2710-rpi-3-b.dts b/arch/arm/boot/dts/bcm2710-rpi-3-b.dts index b21d286..cbec919 100644 --- a/arch/arm/boot/dts/bcm2710-rpi-3-b.dts +++ b/arch/arm/boot/dts/bcm2710-rpi-3-b.dts @@ -1,9 +1,5 @@ /dts-v1/; -#ifdef RPI364 -/memreserve/ 0x 0x1000; -#endif - #include "bcm2710.dtsi" #include "bcm283x-rpi-smsc9514.dtsi" diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi index 7d58cd7..0bc1932 100644 --- a/arch/arm/boot/dts/bcm283x.dtsi +++ b/arch/arm/boot/dts/bcm283x.dtsi @@ -3,6 +3,8 @@ #include #include +/memreserve/ 0x 0x1000; + /* This include file covers the common peripherals and configuration between * bcm2835 and bcm2836 implementations, leaving the CPU configuration to * bcm2835.dtsi and bcm2836.dtsi. -- 1.9.1
[PATCH] genirq: Tell that early_irq_init() is printing the nr of preallocated irqs
The early_irq_init() function was not telling what all the displayed information is. - Add some missing whitespace & commas for easier reading - Tell that the third number is the number of preallocated irqs returned by arch_probe_nr_irqs() Signed-off-by: Vincent Legoll --- kernel/irq/irqdesc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c index 00bb0ae..cd22d85 100644 --- a/kernel/irq/irqdesc.c +++ b/kernel/irq/irqdesc.c @@ -480,7 +480,8 @@ int __init early_irq_init(void) /* Let arch update nr_irqs and return the nr of preallocated irqs */ initcnt = arch_probe_nr_irqs(); - printk(KERN_INFO "NR_IRQS:%d nr_irqs:%d %d\n", NR_IRQS, nr_irqs, initcnt); + printk(KERN_INFO "NR_IRQS: %d, nr_irqs: %d, nr of preallocated irqs: %d\n", + NR_IRQS, nr_irqs, initcnt); if (WARN_ON(nr_irqs > IRQ_BITMAP_BITS)) nr_irqs = IRQ_BITMAP_BITS; -- 2.7.4
Re: [PATCH v1] ACPI: Switch to use generic UUID API
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 7b86508ac8cf..93b4f0de9418 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -210,13 +210,12 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
#ifdef CONFIG_ACPI
static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev)
{
- static const u8 intel_dsm_uuid[] = {
- 0xb7, 0x0c, 0x34, 0xac, 0x01, 0xe9, 0xbf, 0x45,
- 0xb7, 0xe6, 0x2b, 0x34, 0xec, 0x93, 0x1e, 0x23,
- };
+ static const uuid_le intel_dsm_uuid =
+ UUID_LE(0xac340cb7, 0xe901, 0x45bf,
+ 0xb7, 0xe6, 0x2b, 0x34, 0xec, 0x93, 0x1e, 0x23);
union acpi_object *obj;
- obj = acpi_evaluate_dsm(ACPI_HANDLE(&dev->dev), intel_dsm_uuid, 3, 1,
+ obj = acpi_evaluate_dsm(ACPI_HANDLE(&dev->dev), &intel_dsm_uuid, 3, 1,
NULL);
ACPI_FREE(obj);
}
For the xhci part above:
Acked-by: Mathias Nyman
Re: [PATCH v6 2/7] perf/x86/intel: Record branch type
On Mon, Apr 24, 2017 at 08:47:14AM +0800, Jin, Yao wrote:
>
>
> On 4/23/2017 9:55 PM, Jiri Olsa wrote:
> > On Thu, Apr 20, 2017 at 08:07:50PM +0800, Jin Yao wrote:
> >
> > SNIP
> >
> > > +#define X86_BR_TYPE_MAP_MAX 16
> > > +
> > > +static int
> > > +common_branch_type(int type)
> > > +{
> > > + int i, mask;
> > > + const int branch_map[X86_BR_TYPE_MAP_MAX] = {
> > > + PERF_BR_CALL, /* X86_BR_CALL */
> > > + PERF_BR_RET,/* X86_BR_RET */
> > > + PERF_BR_SYSCALL,/* X86_BR_SYSCALL */
> > > + PERF_BR_SYSRET, /* X86_BR_SYSRET */
> > > + PERF_BR_INT,/* X86_BR_INT */
> > > + PERF_BR_IRET, /* X86_BR_IRET */
> > > + PERF_BR_JCC,/* X86_BR_JCC */
> > > + PERF_BR_JMP,/* X86_BR_JMP */
> > > + PERF_BR_IRQ,/* X86_BR_IRQ */
> > > + PERF_BR_IND_CALL, /* X86_BR_IND_CALL */
> > > + PERF_BR_NONE, /* X86_BR_ABORT */
> > > + PERF_BR_NONE, /* X86_BR_IN_TX */
> > > + PERF_BR_NONE, /* X86_BR_NO_TX */
> > > + PERF_BR_CALL, /* X86_BR_ZERO_CALL */
> > > + PERF_BR_NONE, /* X86_BR_CALL_STACK */
> > > + PERF_BR_IND_JMP,/* X86_BR_IND_JMP */
> > > + };
> > > +
> > > + type >>= 2; /* skip X86_BR_USER and X86_BR_KERNEL */
> > > + mask = ~(~0 << 1);
> > is that a fancy way to get 1 into the mask? what do I miss?
you did not comment on this one
> >
> > > +
> > > + for (i = 0; i < X86_BR_TYPE_MAP_MAX; i++) {
> > > + if (type & mask)
> > > + return branch_map[i];
> > I wonder some bit search would be faster in here, but maybe not big deal
> >
> > jirka
>
> I just think the branch_map[] doesn't contain many entries (16 entries
> here), so maybe checking 1 bit one time should be acceptable. I just want to
> keep the code simple.
>
> But if the number of entries is more (e.g. 64), maybe it'd better check 2 or
> 4 bits one time.
ook
jirka
WARREN BUFFETT DONATION GESTURE
$1,500,000 was donated to you For more details email warre...@163.com
Re: [PATCH v9 3/3] printk: fix double printing with earlycon
Hi Aleksey, 2017-04-05, 23:20:00 +0300, Aleksey Makarov wrote: > If a console was specified by ACPI SPCR table _and_ command line > parameters like "console=ttyAMA0" _and_ "earlycon" were specified, > then log messages appear twice. > > The root cause is that the code traverses the list of specified > consoles (the `console_cmdline` array) and stops at the first match. > But it may happen that the same console is referred by the elements > of this array twice: > > pl011,mmio,0x87e02400,115200 -- from SPCR > ttyAMA0 -- from command line > > but in this case `preferred_console` points to the second entry and > the flag CON_CONSDEV is not set, so bootconsole is not deregistered. > > To fix that, introduce an invariant "The last non-braille console > is always the preferred one" on the entries of the console_cmdline > array. Then traverse it in reverse order to be sure that if > the console is preferred then it will be the first matching entry. > Introduce variable console_cmdline_cnt that keeps the number > of elements of the console_cmdline array (Petr Mladek). It helps > to get rid of the loop that searches for the end of this array. That's caused a change of behavior in my qemu setup, with this cmdline root=/dev/sda1 console=ttyS1 console=ttyS0 Before, the kernel logs appeared on ttyS1, and I logged in with ttyS0 (with my setup, ttyS1 is a file and ttyS0 is unix socket). Now, the kernel logs go to ttyS0. I need to swap the two console= parameters to restore behavior. There might be some other problem (in qemu?) though, because adding console=tty0 anywhere on that cmdline makes the logs appear on both tty0 and one ttyS* (but only one of them, and the ordering of the ttyS* matters). Thanks, -- Sabrina
[RFC][PATCHv3 1/5] printk: move printk_pending out of per-cpu
Do not keep `printk_pending' in per-CPU area. We set the following bits
of printk_pending:
a) PRINTK_PENDING_WAKEUP
when we need to wakeup klogd
b) PRINTK_PENDING_OUTPUT
when there is a pending output from deferred printk and we need
to call console_unlock().
So none of the bits control/represent a state of a particular CPU and,
basically, they should be global instead.
Besides we will use `printk_pending' to control printk kthread, so this
patch is also a preparation work.
Signed-off-by: Sergey Senozhatsky
Suggested-by: Petr Mladek
---
kernel/printk/printk.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index a1aecf44ab07..2cb7f4753b76 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -401,6 +401,14 @@ DEFINE_RAW_SPINLOCK(logbuf_lock);
printk_safe_exit_irqrestore(flags); \
} while (0)
+/*
+ * Delayed printk version, for scheduler-internal messages:
+ */
+#define PRINTK_PENDING_WAKEUP 0x01
+#define PRINTK_PENDING_OUTPUT 0x02
+
+static unsigned long printk_pending;
+
#ifdef CONFIG_PRINTK
DECLARE_WAIT_QUEUE_HEAD(log_wait);
/* the next printk record to read by syslog(READ) or /proc/kmsg */
@@ -2709,25 +2717,15 @@ static int __init printk_late_init(void)
late_initcall(printk_late_init);
#if defined CONFIG_PRINTK
-/*
- * Delayed printk version, for scheduler-internal messages:
- */
-#define PRINTK_PENDING_WAKEUP 0x01
-#define PRINTK_PENDING_OUTPUT 0x02
-
-static DEFINE_PER_CPU(int, printk_pending);
-
static void wake_up_klogd_work_func(struct irq_work *irq_work)
{
- int pending = __this_cpu_xchg(printk_pending, 0);
-
- if (pending & PRINTK_PENDING_OUTPUT) {
+ if (test_and_clear_bit(PRINTK_PENDING_OUTPUT, &printk_pending)) {
/* If trylock fails, someone else is doing the printing */
if (console_trylock())
console_unlock();
}
- if (pending & PRINTK_PENDING_WAKEUP)
+ if (test_and_clear_bit(PRINTK_PENDING_WAKEUP, &printk_pending))
wake_up_interruptible(&log_wait);
}
@@ -2740,7 +2738,7 @@ void wake_up_klogd(void)
{
preempt_disable();
if (waitqueue_active(&log_wait)) {
- this_cpu_or(printk_pending, PRINTK_PENDING_WAKEUP);
+ set_bit(PRINTK_PENDING_WAKEUP, &printk_pending);
irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
}
preempt_enable();
@@ -2756,7 +2754,7 @@ int printk_deferred(const char *fmt, ...)
r = vprintk_emit(0, LOGLEVEL_SCHED, NULL, 0, fmt, args);
va_end(args);
- __this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
+ set_bit(PRINTK_PENDING_OUTPUT, &printk_pending);
irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
preempt_enable();
--
2.12.2
[PATCH v2 2/2] drivers: pwm: pwm-atmel: implement pwm dead-times
Implement PWM dead-times for atmel PWM controllers.
Since this driver is used by PWM controllers which
supports dead-times and PWM controllers which doesn't,
add specific input for dead-time register in atmel
register private data structure.
Signed-off-by: Claudiu Beznea
---
drivers/pwm/pwm-atmel.c | 61 +
1 file changed, 57 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 530d7dc..dababa6 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -33,8 +33,9 @@
#define PWM_CMR0x0
/* Bit field in CMR */
-#define PWM_CMR_CPOL (1 << 9)
-#define PWM_CMR_UPD_CDTY (1 << 10)
+#define PWM_CMR_CPOL BIT(9)
+#define PWM_CMR_UPD_CDTY BIT(10)
+#define PWM_CMR_DTEBIT(16)
#define PWM_CMR_CPRE_MSK 0xF
/* The following registers for PWM v1 */
@@ -47,6 +48,7 @@
#define PWMV2_CDTYUPD 0x08
#define PWMV2_CPRD 0x0C
#define PWMV2_CPRDUPD 0x10
+#define PWMV2_DT 0x18
/*
* Max value for duty and period
@@ -63,6 +65,7 @@ struct atmel_pwm_registers {
u8 period_upd;
u8 duty;
u8 duty_upd;
+ u8 dt;
};
struct atmel_pwm_chip {
@@ -161,6 +164,31 @@ static void atmel_pwm_update_cdty(struct pwm_chip *chip,
struct pwm_device *pwm,
atmel_pwm->regs->duty_upd, cdty);
}
+static int atmel_pwm_calculate_deadtime(struct pwm_chip *chip,
+ struct pwm_state *state,
+ unsigned long cprd, unsigned long *dt)
+{
+ unsigned long long cycles;
+
+ if (state->deadtime_fe > state->duty_cycle ||
+ state->deadtime_re > state->period - state->duty_cycle)
+ return -EINVAL;
+
+ if (state->deadtime_fe) {
+ cycles = (unsigned long long)state->deadtime_fe * cprd;
+ do_div(cycles, state->period);
+ *dt = (cycles << 16);
+ }
+
+ if (state->deadtime_re) {
+ cycles = (unsigned long long)state->deadtime_re * cprd;
+ do_div(cycles, state->period);
+ *dt |= cycles;
+ }
+
+ return 0;
+}
+
static void atmel_pwm_set_cprd_cdty(struct pwm_chip *chip,
struct pwm_device *pwm,
unsigned long cprd, unsigned long cdty)
@@ -214,7 +242,7 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
{
struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
struct pwm_state cstate;
- unsigned long cprd, cdty;
+ unsigned long cprd, cdty, dt = 0;
u32 pres, val;
int ret;
@@ -223,7 +251,9 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
if (state->enabled) {
if (cstate.enabled &&
cstate.polarity == state->polarity &&
- cstate.period == state->period) {
+ cstate.period == state->period &&
+ cstate.deadtime_re == state->deadtime_re &&
+ cstate.deadtime_fe == state->deadtime_fe) {
cprd = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm,
atmel_pwm->regs->period);
atmel_pwm_calculate_cdty(state, cprd, &cdty);
@@ -239,6 +269,16 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
return ret;
}
+ if (atmel_pwm->regs->dt) {
+ ret = atmel_pwm_calculate_deadtime(chip, state, cprd,
+ &dt);
+ if (ret) {
+ dev_err(chip->dev,
+ "failed to calculate dead-time\n");
+ return ret;
+ }
+ }
+
atmel_pwm_calculate_cdty(state, cprd, &cdty);
if (cstate.enabled) {
@@ -258,8 +298,19 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
val &= ~PWM_CMR_CPOL;
else
val |= PWM_CMR_CPOL;
+
+ if (atmel_pwm->regs->dt) {
+ if (dt)
+ val |= PWM_CMR_DTE;
+ else
+ val &= ~PWM_CMR_DTE;
+ }
+
atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWM_CMR, val);
atmel_pwm_set_cprd_cdty(chip, pwm, cprd, cdty);
+ if (atmel_pwm->regs->dt)
+ atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm,
+ atmel_pwm->regs->dt, dt);
mutex_lock(&atmel_pwm->isr_lock);
atmel_pwm
[RFC][PATCHv3 3/5] printk: add enforce_emergency parameter
This param permits user-space to forcibly on/off printk emergency mode via /sys/module/printk/parameters/enforce_emergency node. Signed-off-by: Sergey Senozhatsky --- kernel/printk/printk.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index a113f684066c..ba640fbcee7c 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -455,9 +455,15 @@ static struct task_struct *printk_kthread __read_mostly; static atomic_t printk_emergency __read_mostly; /* * Disable printk_kthread permanently. Unlike `oops_in_progress' - * it doesn't go back to 0. + * it doesn't go back to 0 (unless set by user-space). */ static bool printk_enforce_emergency __read_mostly; + +module_param_named(enforce_emergency, printk_enforce_emergency, + bool, 0644); +MODULE_PARM_DESC(printk_enforce_emergency, +"don't offload message printing to printk kthread"); + /* * The number of lines a task can print before offloading printing * job to printk_kthread. 0 indicates 'no limit'. -- 2.12.2
[RFC][PATCHv3 4/5] printk: enable printk offloading
Initialize kernel printing thread and make printk offloading
possible. By default `atomic_print_limit' is set to 0, so no
offloading will take place, unless requested by user.
Signed-off-by: Sergey Senozhatsky
---
kernel/printk/printk.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index ba640fbcee7c..81ea575728b9 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2927,6 +2928,43 @@ static DEFINE_PER_CPU(struct irq_work,
wake_up_klogd_work) = {
.flags = IRQ_WORK_LAZY,
};
+static int printk_kthread_func(void *data)
+{
+ while (1) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ if (!test_bit(PRINTK_PENDING_OUTPUT, &printk_pending))
+ schedule();
+
+ __set_current_state(TASK_RUNNING);
+
+ console_lock();
+ console_unlock();
+ }
+
+ return 0;
+}
+
+/*
+ * Init printk kthread at late_initcall stage, after core/arch/device/etc.
+ * initialization.
+ */
+static int __init init_printk_kthread(void)
+{
+ struct task_struct *thread;
+ struct sched_param param = { .sched_priority = MAX_USER_RT_PRIO / 2 };
+
+ thread = kthread_run(printk_kthread_func, NULL, "printk");
+ if (IS_ERR(thread)) {
+ pr_err("printk: unable to create printing thread\n");
+ return PTR_ERR(thread);
+ }
+
+ sched_setscheduler(thread, SCHED_FIFO, ¶m);
+ printk_kthread = thread;
+ return 0;
+}
+late_initcall(init_printk_kthread);
+
void wake_up_klogd(void)
{
preempt_disable();
--
2.12.2
[RFC][PATCHv3 5/5] printk: register PM notifier
It's not always possible/safe to wake_up() printk kernel
thread. For example, late suspend/early resume may printk()
while timekeeping is not initialized yet, so calling into the
scheduler may result in recursive warnings.
Another thing to notice is the fact PM at some point
freezes user space and kernel threads: freeze_processes()
and freeze_kernel_threads(), correspondingly. Thus we need
printk() to operate in emergency mode there and attempt to
immediately flush pending kernel message to the console.
This patch registers PM notifier, so PM can switch printk
to emergency mode from PM_FOO_PREPARE notifiers and return
back to printk threaded mode from PM_POST_FOO notifiers.
Signed-off-by: Sergey Senozhatsky
Suggested-by: Andreas Mohr
---
kernel/printk/printk.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 81ea575728b9..6aae36a29aca 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2928,6 +2929,30 @@ static DEFINE_PER_CPU(struct irq_work,
wake_up_klogd_work) = {
.flags = IRQ_WORK_LAZY,
};
+static int printk_pm_notify(struct notifier_block *notify_block,
+ unsigned long mode, void *unused)
+{
+ switch (mode) {
+ case PM_HIBERNATION_PREPARE:
+ case PM_SUSPEND_PREPARE:
+ case PM_RESTORE_PREPARE:
+ printk_emergency_begin();
+ break;
+
+ case PM_POST_SUSPEND:
+ case PM_POST_HIBERNATION:
+ case PM_POST_RESTORE:
+ printk_emergency_end();
+ break;
+ }
+
+ return 0;
+}
+
+static struct notifier_block printk_pm_nb = {
+ .notifier_call = printk_pm_notify,
+};
+
static int printk_kthread_func(void *data)
{
while (1) {
@@ -2961,6 +2986,8 @@ static int __init init_printk_kthread(void)
sched_setscheduler(thread, SCHED_FIFO, ¶m);
printk_kthread = thread;
+
+ WARN_ON(register_pm_notifier(&printk_pm_nb) != 0);
return 0;
}
late_initcall(init_printk_kthread);
--
2.12.2
[PATCH v2 1/2] drivers: pwm: core: implement pwm dead-times
Extends PWM framework to support PWM dead-times. The notions introduced are rising edge dead-time and falling edge dead-time. These are useful for PWM controllers with channels that have more than one outputs. The implementation add sysfs interface for configuration. It extends the pwm_state structure with two new members which keeps the values for dead-times. There were no additions in device tree for PWM channels initialized by device tree. Signed-off-by: Claudiu Beznea --- Documentation/pwm.txt | 55 ++ drivers/pwm/core.c| 10 ++- drivers/pwm/sysfs.c | 74 +++ include/linux/pwm.h | 36 + 4 files changed, 174 insertions(+), 1 deletion(-) diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt index 789b27c..61de0f9 100644 --- a/Documentation/pwm.txt +++ b/Documentation/pwm.txt @@ -100,6 +100,61 @@ enable - Enable/disable the PWM signal (read/write). 0 - disabled 1 - enabled +deadtime_re -The rising edge dead-time +deadtime_fe - the falling edge dead-time + For a PWM controller with more than one output signals per PWM channel + dead-times are the delays introduced between the edges of the output + signals and the original signal introduced in dead-time generator + engine. + E.g. consider a PWM controller with a dead-time engine as in the following + diagram: + +- + | |---> PWMH +PWM signal --->| Dead-time engine| + | |---> PWML +- + + With no dead-time configured, the PWMH and PWML signals will be + complementary signals (rising and falling edges of PWMH and PWML + have opposite leves, same duration and same starting time) as + follows: + + 0DP +PWM signal __||||||||||___ + + PWMH __||||||||||___ + __ ___ + PWML |||||||||| + + Where - 0 is the starting point of the signal + - D is the starting point of the duty-cycle + - P is the signal period + + Based on the above diagram: + - rising edge dead-time - is the delay introduced in one of the + dead-time engine output signals; the delay is introduced after + rising edge of the original PWM signal + - falling edge dead-time - is the delay introduced in one of the + dead-time engine output signals; the delay is introduced after + the end of falling edge of the original PWM signal + See the following diagram: + + 0DP +PWM signal __||||||||||___ +__________ + PWMH | |re| |__| |__| |__| |___ + ____________ + PWML |__| |fe| |__| |__| |__| + + In the upper diagram: + - re = rising edge = the delay between D point of the original PWM signal + (rising edge) and the starting point of the next edge of one of the PWM + dead-time engine output + - fe = falling edge = the delay between P point of the original PWM signal + (falling edge) and the starting point of the next edge of one of the PWM + dead-time engine output + Implementing a PWM driver - diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c index a0860b3..c1a9828 100644 --- a/drivers/pwm/core.c +++ b/drivers/pwm/core.c @@ -469,7 +469,8 @@ int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state) int err; if (!pwm || !state || !state->period || - state->duty_cycle > state->period) + state->duty_cycle > state->period || + state->deadtime_re + state->deadtime_fe > state->period) return -EINVAL; if (!memcmp(state, &pwm->state, sizeof(*state))) @@ -579,6 +580,9 @@ int pwm_adjust_config(struct pwm_device *pwm) pwm_get_args(pwm, &pargs); pwm_get_state(pwm, &state); + state.deadtime_re = 0; + state.deadtime_fe = 0; + /* * If the current period is zero it means that either the PWM driver * does not support initial state retrieval or the PWM has not yet @@ -997,6 +1001,10 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s) seq_printf(s, " duty: %u ns", state.duty_cycle); seq_printf(s, " polarity: %s",
[RFC][PATCHv3 0/5] printk: introduce printing kernel thread
Hello, RFC This patch set adds a printk() kernel thread which lets us to print kernel messages to the console from a non-atomic/schedule-able context, avoiding different sort of lockups, stalls, etc. A completely reworked version, for more details please see 0003 commit message and code comments/documentation. v2->v3 (Petr, Pavel, Andreas): -- rework offloading -- use PM notifiers -- dropped some patches, etc. etc. v1->v2: -- introduce printk_emergency mode and API to switch it on/off -- move printk_pending out of per-CPU memory -- add printk emergency_mode sysfs node -- switch sysrq handlers (some of them) to printk_emergency -- cleanus/etc. Sergey Senozhatsky (5): printk: move printk_pending out of per-cpu printk: introduce printing kernel thread printk: add enforce_emergency parameter printk: enable printk offloading printk: register PM notifier include/linux/console.h | 3 + kernel/printk/printk.c | 296 2 files changed, 279 insertions(+), 20 deletions(-) -- 2.12.2
[RFC][PATCHv3 2/5] printk: introduce printing kernel thread
printk() is quite complex internally and, basically, it does two slightly independent things: a) adds a new message to a kernel log buffer (log_store()) b) prints kernel log messages to serial consoles (console_unlock()) while (a) is guaranteed to be executed by printk(), (b) is not, for a variety of reasons, and, unlike log_store(), it comes at a price: 1) console_unlock() attempts to flush all pending kernel log messages to the console and it can loop indefinitely. 2) while console_unlock() is executed on one particular CPU, printing pending kernel log messages, other CPUs can simultaneously append new messages to the kernel log buffer. 3) the time it takes console_unlock() to print kernel messages also depends on the speed of the console -- which may not be fast at all. 4) console_unlock() is executed in the same context as printk(), so it may be non-preemptible/atomic, which makes 1)-3) dangerous. As a result, nobody knows how long a printk() call will take, so it's not really safe to call printk() in a number of situations, including atomic context, RCU critical sections, interrupt context, etc. This patch introduces a '/sys/module/printk/parameters/atomic_print_limit' sysfs param, which sets the limit on number of lines a process can print from console_unlock(). Value 0 corresponds to the current behavior (no limitation). The printing offloading is happening from console_unlock() function and, briefly, looks as follows: as soon as process prints more than `atomic_print_limit' lines it attempts to offload printing to another process. Since nothing guarantees that there will another process sleeping on the console_sem or calling printk() on another CPU simultaneously, the patch also introduces an auxiliary kernel thread - printk_kthread, the main purpose of which is to take over printing duty. The workflow is, thus, turns into: as soon as process prints more than `atomic_print_limit' lines it wakes up printk_kthread and unlocks the console_sem. So in the best case at this point there will be at least 1 processes trying to lock the console_sem: printk_kthread. (There can also be a process that was sleeping on the console_sem and that was woken up by console semaphore up(); and concurrent printk() invocations from other CPUs). But in the worst case there won't be any processes ready to take over the printing duty: it may take printk_kthread some time to become running; or printk_kthread may even never become running (a misbehaving scheduler, or other critical condition). That's why after we wake_up() printk_kthread we can't immediately leave the printing loop, we must ensure that the console_sem has a new owner before we do so. Therefore, `atomic_print_limit' is a soft limit, not the hard one: we let task to overrun `atomic_print_limit'. But, at the same time, the console_unlock() printing loop behaves differently for tasks that have exceeded `atomic_print_limit': after every printed logbuf entry (call_console_drivers()) such a process wakes up printk_kthread, unlocks the console_sem and attempts to console_trylock() a bit later (if there any are pending messages in the logbuf, of course). In the best case scenario either printk_kthread or some other tasks will lock the console_sem, so current printing task will see failed console_trylock(), which will indicate a successful printing offloading. In the worst case, however, current will successfully console_trylock(), which will indicate that offloading did not take place and we can't return from console_unlock(), so the printing task will print one more line from the logbuf and attempt to offload printing once again; and it will continue doing so until another process locks the console_sem or until there are pending messages in the logbuf. So if everything goes wrong - we can't wakeup printk_kthread and there are no other processes sleeping on the console_sem or trying to down() it - then we will have the existing console_unlock() behavior: print all pending messages in one shot. We track the number of unsuccessful offloading attempts and after some point we declare a `printk_emergency' condition and give up trying to offload. `printk_emergency' is a new name for printk mode in which printk does not attempt to offload printing, but instead flushes all the pending logbuf messages (basically, the existing behaviour). There also other cases when we can't (or should avoid) offloading. For example, we can't call into the scheduler from panic(), because this may cause deadlock. Therefore printk() has some additional places where it switches to printk_emergency mode: for instance, once a EMERG log level message appears in the log buffer. We also provide two new functions that can be used when a path needs to declare a temporal `printk_emergency' mode: -- printk_emergency_begin() Disables printk offloading. All printk() calls will attempt to lock the console_sem and, if successful, flush kernel log messages. -- printk_emergency_end(
Re: [PATCH v4] staging: lustre: llite: Fix variable length array warning
This patch introduces tons of memory leaks so we can't apply it.
Just ignore the warning. The size is small enough that it won't
overflow the stack. The other reason to avoid these types of
declarations is that in olden times (5 years ago at least) there was a
GCC for an arch where if you declared the variable inside a loop it
would not free the memory until after the end of the loop.
while ((foo = frob())) {
int whatver[x + y];
}
The memory would keep increasing until we broke from the loop or it
overflowed the stack and crashed.
On Mon, May 08, 2017 at 11:57:16PM -0700, Guru Das Srinagesh wrote:
> Fix sparse warning "warning: Variable length array is used." by using
> kmalloc_array to allocate the required amount of memory instead and
> kfree to deallocate memory after use.
>
> Signed-off-by: Guru Das Srinagesh
> ---
> v4:
>- Changed kmalloc_array flags from GFP_KERNEL to GFP_ATOMIC
>
> v3:
>- Fixed checkpatch warning: Comparison to NULL could be written "!fullname"
>
> v2:
>- Added missing check for NULL return value of kmalloc_array()
>
> drivers/staging/lustre/lustre/llite/xattr.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/llite/xattr.c
> b/drivers/staging/lustre/lustre/llite/xattr.c
> index 6187bff..ae2efd5 100644
> --- a/drivers/staging/lustre/lustre/llite/xattr.c
> +++ b/drivers/staging/lustre/lustre/llite/xattr.c
> @@ -86,13 +86,17 @@ ll_xattr_set_common(const struct xattr_handler *handler,
> const char *name, const void *value, size_t size,
> int flags)
> {
> - char fullname[strlen(handler->prefix) + strlen(name) + 1];
> + int fullname_len = strlen(handler->prefix) + strlen(name) + 1;
> + char *fullname = kmalloc_array(fullname_len, sizeof(char), GFP_ATOMIC);
Using kmalloc_array() is pointless. Everyone knows that sizeof(char) is
1 and also that 1 * x == x. It just makes the code more confusing and
complicated for no reason. Don't hide the allocation this declaration
block. It should be next to the check for NULL. But anyway, don't
bother resending, just ignore the warning.
regards,
dan carpenter
[PATCH] genirq: Tell that early_irq_init() is printing the nr of preallocated irqs
The early_irq_init() function was not telling what all the displayed information is. - Add some missing whitespace & commas for easier reading - Tell that the third number is the number of preallocated irqs returned by arch_probe_nr_irqs() - Also cover !CONFIG_SPARSE_IRQ case Signed-off-by: Vincent Legoll --- kernel/irq/irqdesc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c index 00bb0ae..fb53da0 100644 --- a/kernel/irq/irqdesc.c +++ b/kernel/irq/irqdesc.c @@ -480,7 +480,8 @@ int __init early_irq_init(void) /* Let arch update nr_irqs and return the nr of preallocated irqs */ initcnt = arch_probe_nr_irqs(); - printk(KERN_INFO "NR_IRQS:%d nr_irqs:%d %d\n", NR_IRQS, nr_irqs, initcnt); + printk(KERN_INFO "NR_IRQS: %d, nr_irqs: %d, nr of preallocated irqs: %d\n", + NR_IRQS, nr_irqs, initcnt); if (WARN_ON(nr_irqs > IRQ_BITMAP_BITS)) nr_irqs = IRQ_BITMAP_BITS; @@ -516,7 +517,7 @@ int __init early_irq_init(void) init_irq_default_affinity(); - printk(KERN_INFO "NR_IRQS:%d\n", NR_IRQS); + printk(KERN_INFO "NR_IRQS: %d\n", NR_IRQS); desc = irq_desc; count = ARRAY_SIZE(irq_desc); -- 2.7.4
[PATCH] crypto: rng - move __crypto_rng_cast to the rng header
This patch move __crypto_rng_cast() to the right header like other
__algo_cast functions.
Signed-off-by: Corentin Labbe
---
crypto/rng.c | 5 -
include/crypto/rng.h | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/crypto/rng.c b/crypto/rng.c
index f46dac5..5e84692 100644
--- a/crypto/rng.c
+++ b/crypto/rng.c
@@ -33,11 +33,6 @@ struct crypto_rng *crypto_default_rng;
EXPORT_SYMBOL_GPL(crypto_default_rng);
static int crypto_default_rng_refcnt;
-static inline struct crypto_rng *__crypto_rng_cast(struct crypto_tfm *tfm)
-{
- return container_of(tfm, struct crypto_rng, base);
-}
-
int crypto_rng_reset(struct crypto_rng *tfm, const u8 *seed, unsigned int slen)
{
u8 *buf = NULL;
diff --git a/include/crypto/rng.h b/include/crypto/rng.h
index b95ede3..4281193 100644
--- a/include/crypto/rng.h
+++ b/include/crypto/rng.h
@@ -197,4 +197,9 @@ static inline int crypto_rng_seedsize(struct crypto_rng
*tfm)
return crypto_rng_alg(tfm)->seedsize;
}
+static inline struct crypto_rng *__crypto_rng_cast(struct crypto_tfm *tfm)
+{
+ return container_of(tfm, struct crypto_rng, base);
+}
+
#endif
--
2.10.2
[PATCH] i2c: pca954x: Add option to skip disabling PCA954x Mux device
From: Priyanka Jain
On some Layerscape boards like LS2085ARDB/LS2080ARDB,
input pull-up resistors on PCA954x Mux device are
missing on board. So, if mux are disabled after powered-on,
input lines will float leading to incorrect functionality.
Hence, PCA954x Mux device should never be turned-off after
power-on.
Add option to skip disabling PCA954x Mux device
if device tree contians "i2c-mux-never-disable" property
for pca954x device node.
Signed-off-by: Zhang Ying-22455
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
b/drivers/i2c/muxes/i2c-mux-pca954x.c
index f1751c2..4d18fc0 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -85,6 +85,7 @@ struct pca954x {
struct irq_domain *irq;
unsigned int irq_mask;
raw_spinlock_t lock;
+ u8 disable_mux; /* do not disable mux if val not 0 */
};
/* Provide specs for the PCA954x types we know about */
@@ -221,6 +222,13 @@ static int pca954x_deselect_mux(struct i2c_mux_core *muxc,
u32 chan)
if (!(data->deselect & (1 << chan)))
return 0;
+#ifdef CONFIG_ARCH_LAYERSCAPE
+ if (data->disable_mux != 0)
+ data->last_chan = data->chip->nchans;
+ else
+ data->last_chan = 0;
+ return pca954x_reg_write(muxc->parent, client, data->disable_mux);
+#endif
/* Deselect active channel */
data->last_chan = 0;
return pca954x_reg_write(muxc->parent, client, data->last_chan);
@@ -361,6 +369,22 @@ static int pca954x_probe(struct i2c_client *client,
return -ENOMEM;
data = i2c_mux_priv(muxc);
+#ifdef CONFIG_ARCH_LAYERSCAPE
+ /* The point here is that you must not disable a mux if there
+* are no pullups on the input or you mess up the I2C. This
+* needs to be put into the DTS really as the kernel cannot
+* know this otherwise.
+*/
+ data->disable_mux = of_node &&
+ of_property_read_bool(of_node, "i2c-mux-never-disable") &&
+ data->chip->muxtype == pca954x_ismux ?
+ data->chip->enable : 0;
+ /* force the first selection */
+ if (data->disable_mux != 0)
+ data->last_chan = data->chip->nchans;
+ else
+ data->last_chan = 0;
+#endif
i2c_set_clientdata(client, muxc);
data->client = client;
@@ -373,7 +397,11 @@ static int pca954x_probe(struct i2c_client *client,
* that the mux is in fact present. This also
* initializes the mux to disconnected state.
*/
+#ifdef CONFIG_ARCH_LAYERSCAPE
+ if (i2c_smbus_write_byte(client, data->disable_mux) < 0) {
+#else
if (i2c_smbus_write_byte(client, 0) < 0) {
+#endif
dev_warn(&client->dev, "probe failed\n");
return -ENODEV;
}
@@ -384,7 +412,9 @@ static int pca954x_probe(struct i2c_client *client,
else
data->chip = &chips[id->driver_data];
+#ifndef CONFIG_ARCH_LAYERSCAPE
data->last_chan = 0; /* force the first selection */
+#endif
idle_disconnect_dt = of_node &&
of_property_read_bool(of_node, "i2c-mux-idle-disconnect");
@@ -454,6 +484,13 @@ static int pca954x_resume(struct device *dev)
struct i2c_mux_core *muxc = i2c_get_clientdata(client);
struct pca954x *data = i2c_mux_priv(muxc);
+#ifdef CONFIG_ARCH_LAYERSCAPE
+ if (data->disable_mux != 0)
+ data->last_chan = data->chip->nchans;
+ else
+ data->last_chan = 0;
+ return i2c_smbus_write_byte(client, data->disable_mux);
+#endif
data->last_chan = 0;
return i2c_smbus_write_byte(client, 0);
}
--
2.1.0.27.g96db324
Re: [PATCH v3] ARM: dts: at91: sama5d2: add m_can nodes
On 2017/4/24 9:12, Wenyou Yang wrote:
Add nodes to support the Controller Area Network(M_CAN) on SAMA5D2.
The version of M_CAN IP core is 3.1.0 (CREL = 0x31040730).
As said in SAMA5D2 datasheet, the CAN clock is recommended to use
frequencies of 20, 40 or 80 MHz. To achieve these frequencies,
PMC GCLK3 must select the UPLLCK(480 MHz) as source clock and
divide by 24, 12, or 6. So, the "assigned-clock-rates" property
has three options: 2000, 4000, and 8000.
The "assigned-clock-parents" property should be referred to utmi
fixedly.
The MSBs [bits 31:16] of the CAN Message RAM for CAN0 and CAN1 are
default configured in 0x0020. To avoid conflict with SRAM map
for PM, change them to 0x0021 in the AT91Bootstrap via setting
the CAN Memories Address-based Register(SFR_CAN) of SFR.
Signed-off-by: Wenyou Yang
Tested-by: Quentin Schulz
Do you have any comments?
---
The patch is tested on SAMA5D2 Xplained and based on the patch set,
1. [PATCH v4 1/7] can: m_can: Disabled Interrupt Line 1
http://marc.info/?l=linux-can&m=149165343604033&w=2
Changes in v3:
- Add Tested-by tag.
- Change the number of Rx Rx Buffers, Tx Buffers and Tx Event FIFO
to maximum.
Changes in v2:
- Configures 10 TX Event FIFO elements and 10 TX Buffers/FIFO slots,
because the TXE FIFO is needed to be configured.
- Configure the offset of Message RAM for CAN1 followed from CAN0's.
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 24 +
arch/arm/boot/dts/sama5d2.dtsi | 56 +
2 files changed, 80 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 9f7f8a7d8ff9..2f19b08dc226 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -257,6 +257,12 @@
status = "okay";
};
+ can0: can@f8054000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can0_default>;
+ status = "okay";
+ };
+
uart3: serial@fc008000 {
atmel,use-dma-rx;
atmel,use-dma-tx;
@@ -321,6 +327,18 @@
bias-disable;
};
+pinctrl_can0_default: can0_default {
+ pinmux = ,
+;
+ bias-disable;
+ };
+
+ pinctrl_can1_default: can1_default {
+ pinmux = ,
+;
+ bias-disable;
+ };
+
pinctrl_charger_chglev: charger_chglev {
pinmux = ;
bias-disable;
@@ -468,6 +486,12 @@
};
};
+
+ can1: can@fc05 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1_default>;
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 22332be72140..7e00fa21373e 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -762,6 +762,18 @@
atmel,clk-output-range = <0
8300>;
};
+ can0_clk: can0_clk {
+ #clock-cells = <0>;
+ reg = <56>;
+ atmel,clk-output-range = <0
8300>;
+ };
+
+ can1_clk: can1_clk {
+ #clock-cells = <0>;
+ reg = <57>;
+ atmel,clk-output-range = <0
8300>;
+ };
+
classd_clk: classd_clk {
#clock-cells = <0>;
reg = <59>;
@@ -890,6 +902,18 @@
#clock-cells = <0>;
reg = <55>;
};
+
+ can0_gclk: can0_gclk {
+ #clock-cells = <0>;
+ reg = <5
Re: S390: Fine-tuning for six function implementations
> It would be different if your patches fixed actual bugs. I dare to point change possibilities out which correspond to a special error category. There can be different opinions about their relevance for further software improvements. > This is just mindless code transformations that MAY in the best case save a > few bytes > of code here and there (I don't know; you didn't say). Do you know the run time characteristics for the discussed functions good enough? http://elixir.free-electrons.com/linux/v4.11/source/fs/seq_file.c#L405 > But the potential gains from these incredibly numerous and tiny patches > that don't fix anything are so small, it's a waste of time, bandwidth, > and mental capacity for you and for everybody involved. I suggest a bit of code reduction at various places once more. > I just searched my inbox for patches from you and you sent literally > _hundreds_ over the past few days, I sent update suggestions in this scale since the year 2014. > all doing this crazy printf/puts/putc transformation. I agree that the corresponding number could be remarkable. But there are also other source code search patterns involved besides information around these logging functions. > Another bit of searching and I see that I'm not the first one giving you > this response: You are right that some agreements and disagreements were expressed already (depending on the software area). Regards, Markus
Re: [PATCH] rpmsg: Make rpmsg_create_ept() propagate error
Hi Bjorn,
[auto build test WARNING on next-20170505]
[also build test WARNING on v4.11]
[cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Bjorn-Andersson/rpmsg-Make-rpmsg_create_ept-propagate-error/20170509-135640
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
drivers/rpmsg/virtio_rpmsg_bus.c:227:31: sparse: incorrect type in return
expression (different base types)
drivers/rpmsg/virtio_rpmsg_bus.c:227:31:expected struct rpmsg_endpoint *
drivers/rpmsg/virtio_rpmsg_bus.c:227:31:got long
drivers/rpmsg/virtio_rpmsg_bus.c: In function '__rpmsg_create_ept':
>> drivers/rpmsg/virtio_rpmsg_bus.c:227:18: warning: passing argument 1 of
>> 'PTR_ERR' makes pointer from integer without a cast [-Wint-conversion]
return PTR_ERR(-ENOMEM);
^
In file included from include/linux/rwsem.h:17:0,
from include/linux/notifier.h:14,
from include/linux/memory_hotplug.h:6,
from include/linux/mmzone.h:757,
from include/linux/gfp.h:5,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/rpmsg/virtio_rpmsg_bus.c:23:
include/linux/err.h:28:33: note: expected 'const void *' but argument is of
type 'int'
static inline long __must_check PTR_ERR(__force const void *ptr)
^~~
>> drivers/rpmsg/virtio_rpmsg_bus.c:227:10: warning: return makes pointer from
>> integer without a cast [-Wint-conversion]
return PTR_ERR(-ENOMEM);
^~~~
vim +/PTR_ERR +227 drivers/rpmsg/virtio_rpmsg_bus.c
211 */
212 kfree(ept);
213 }
214
215 /* for more info, see below documentation of rpmsg_create_ept() */
216 static struct rpmsg_endpoint *__rpmsg_create_ept(struct virtproc_info
*vrp,
217 struct rpmsg_device
*rpdev,
218 rpmsg_rx_cb_t cb,
219 void *priv, u32 addr)
220 {
221 int id_min, id_max, id;
222 struct rpmsg_endpoint *ept;
223 struct device *dev = rpdev ? &rpdev->dev : &vrp->vdev->dev;
224
225 ept = kzalloc(sizeof(*ept), GFP_KERNEL);
226 if (!ept)
> 227 return PTR_ERR(-ENOMEM);
228
229 kref_init(&ept->refcount);
230 mutex_init(&ept->cb_lock);
231
232 ept->rpdev = rpdev;
233 ept->cb = cb;
234 ept->priv = priv;
235 ept->ops = &virtio_endpoint_ops;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH] staging: typec: Make undeclared symbol static
Fix sparse warning:
drivers/staging/typec/tcpci.c:428:26: warning: symbol 'tcpci_tcpc_config'
was not declared. Should it be static?
Signed-off-by: Guru Das Srinagesh
---
drivers/staging/typec/tcpci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 5e5be74..df72d8b 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -425,7 +425,7 @@ static const struct regmap_config tcpci_regmap_config = {
.max_register = 0x7F, /* 0x80 .. 0xFF are vendor defined */
};
-const struct tcpc_config tcpci_tcpc_config = {
+static const struct tcpc_config tcpci_tcpc_config = {
.type = TYPEC_PORT_DFP,
.default_role = TYPEC_SINK,
};
--
2.7.4
[PATCH] tracing: use %pF in trace_dump_stack()
When using trace_dump_stack() you currently just get a list of function names. It can be very useful to know exactly where a call came from, especially if there are multiple calls from one function to another. By switching trace_dump_stack() to use %pF we get the function name and the offset, which can also be further processed to give exact line number information, like this: <...>-10873 3270529us : => pty_write+0x45/0x50 => n_tty_write+0x358/0x470 => tty_write+0x189/0x2f0 => __vfs_write+0x23/0x120 => vfs_write+0xb3/0x1b0 => SyS_write+0x44/0xa0 => entry_SYSCALL_64_fastpath+0x18/0xad $ scripts/faddr2line vmlinux tty_write+0x189/0x2f0 tty_write+0x189/0x2f0: do_tty_write at drivers/tty/tty_io.c:1174 (inlined by) tty_write at drivers/tty/tty_io.c:1257 Signed-off-by: Vegard Nossum --- kernel/trace/trace_output.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c index 02a4aeb22c47..879909efed33 100644 --- a/kernel/trace/trace_output.c +++ b/kernel/trace/trace_output.c @@ -1073,9 +1073,7 @@ static enum print_line_t trace_stack_print(struct trace_iterator *iter, if (trace_seq_has_overflowed(s)) break; - trace_seq_puts(s, " => "); - seq_print_ip_sym(s, *p, flags); - trace_seq_putc(s, '\n'); + trace_seq_printf(s, " => %pF\n", (void *) *p); } return trace_handle_return(s); -- 2.12.0.rc0
[PATCH] asm-generic/io.h: remove unnecessary #include of
After commit 1f5307b1e094 ("mm, vmalloc: properly track vmalloc users")
the build for ARCH=nios2 fails with:
In file included from ./include/asm-generic/io.h:767:0,
from ./arch/nios2/include/asm/io.h:61,
from ./include/linux/io.h:25,
from ./arch/nios2/include/asm/pgtable.h:18,
from ./include/linux/mm.h:70,
from ./include/linux/pid_namespace.h:6,
from ./include/linux/ptrace.h:9,
from ./arch/nios2/include/uapi/asm/elf.h:23,
from ./arch/nios2/include/asm/elf.h:22,
from ./include/linux/elf.h:4,
from ./include/linux/module.h:15,
from init/main.c:16:
./include/linux/vmalloc.h: In function '__vmalloc_node_flags':
./include/linux/vmalloc.h:99:40: error: 'PAGE_KERNEL' undeclared (first use in
this function); did you mean 'GFP_KERNEL'?
which is due to the newly added #include , which on nios2
includes and thus and which
again includes .
It turns out the #include in isn't
necessary at all since none of it definitions are used there, so remove
it alltogether.
Build tested on
- nios2: 10m50_defconfig
- x86: allyesconfig, various randconfigs
- arm: tegra_defconfig, various randconfigs
Cc: Michal Hocko
Cc: Ley Foon Tan
Signed-off-by: Tobias Klauser
---
include/asm-generic/io.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 7ef015eb3403..fe5e01fbed54 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -764,7 +764,6 @@ static inline void iowrite64_rep(volatile void __iomem
*addr,
#ifdef __KERNEL__
-#include
#define __io_virt(x) ((void __force *)(x))
#ifndef CONFIG_GENERIC_IOMAP
--
2.12.2
Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
Jesper, Am 09.05.2017 um 09:46 schrieb Jesper Nilsson: > Hi Richard, > > I'm still worried about this failure case, do we really > believe that the flash could fail in such a way that the > fastmap is corrupted in an undetectable way? > > If we do detect corruption we should be no worse off > than earlier since we should ignore the fastmap, IIRC. In a perfect world, yes. > Could you please elaborate on the problem you were > thinking about? e.g. commit 74f2c6e9a47cf4e508198c8594626cc82906a13d Author: Richard Weinberger Date: Tue Jun 14 10:12:17 2016 +0200 ubi: Be more paranoid while seaching for the most recent Fastmap Since PEB erasure is asynchornous it can happen that there is more than one Fastmap on the MTD. This is fine because the attach logic will pick the Fastmap data structure with the highest sequence number. On a not so well configured MTD stack spurious ECC errors are common. Causes can be different, bad hardware, wrong operating modes, etc... If the most current Fastmap renders bad due to ECC errors UBI might pick an older Fastmap to attach from. While this can only happen on an anyway broken setup it will show completely different sympthoms and makes finding the root cause much more difficult. So, be debug friendly and fall back to scanning mode of we're facing an ECC error while scanning for Fastmap. Cc: Signed-off-by: Richard Weinberger > Right now I'm hesitant to use fastmap in any production code, > even if it works with my current hardware, since there is no > guarantee that the flash chips won't get replaced with a > second source option down the line... Fastmap is an aggressive optimization and makes finding issues much harder. Thanks, //richard
[PATCH] irq_bcm2836: Send event when onlining sleeping cores
In order to reduce power consumption and bus traffic, it is sensible for secondary cores to enter a low-power idle state when waiting to be started. The wfe instruction causes a core to wait until an event or interrupt arrives before continuing to the next instruction. The sev instruction sends a wakeup event to the other cores, so call it from bcm2836_smp_boot_secondary, the function that wakes up the waiting cores during booting. It is harmless to use this patch without the corresponding change adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated and this patch is not applied then the other cores will sleep forever. See: https://github.com/raspberrypi/linux/issues/1989 Signed-off-by: Phil Elwell --- drivers/irqchip/irq-bcm2836.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c index e10597c..6dccdf9 100644 --- a/drivers/irqchip/irq-bcm2836.c +++ b/drivers/irqchip/irq-bcm2836.c @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu, writel(secondary_startup_phys, intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu); + dsb(sy); /* Ensure write has completed before waking the other CPUs */ + sev(); + return 0; } -- 1.9.1
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option
On Mon, May 08, 2017 at 03:12:42PM -0700, prakash.sangappa wrote: > Regarding #3 as a general feature, do we want to > consider this and the complexity associated with the > implementation? We have to. Given that no one has exclusive access to hugetlbfs a mount option is fundamentally the wrong interface.
Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode
On Tue, May 09, 2017 at 08:45:22AM +0200, Ingo Molnar wrote: > We only have ~115 code blocks in the kernel that set/restore KERNEL_DS, it > would > be a pity to add a runtime check to every system call ... I think we should simply strive to remove all of them that aren't in core scheduler / arch code. Basically evetyytime we do the oldfs = get_fs(); set_fs(KERNEL_DS); .. set_fs(oldfs); trick we're doing something wrong, and there should always be better ways to archive it. E.g. using iov_iter with a ITER_KVEC type consistently would already remove most of them.
Re: [PATCH] asm-generic/io.h: remove unnecessary #include of
On Tue 09-05-17 10:50:45, Tobias Klauser wrote:
> After commit 1f5307b1e094 ("mm, vmalloc: properly track vmalloc users")
> the build for ARCH=nios2 fails with:
>
> In file included from ./include/asm-generic/io.h:767:0,
>from ./arch/nios2/include/asm/io.h:61,
>from ./include/linux/io.h:25,
>from ./arch/nios2/include/asm/pgtable.h:18,
>from ./include/linux/mm.h:70,
>from ./include/linux/pid_namespace.h:6,
>from ./include/linux/ptrace.h:9,
>from ./arch/nios2/include/uapi/asm/elf.h:23,
>from ./arch/nios2/include/asm/elf.h:22,
>from ./include/linux/elf.h:4,
>from ./include/linux/module.h:15,
>from init/main.c:16:
> ./include/linux/vmalloc.h: In function '__vmalloc_node_flags':
> ./include/linux/vmalloc.h:99:40: error: 'PAGE_KERNEL' undeclared (first use
> in this function); did you mean 'GFP_KERNEL'?
>
> which is due to the newly added #include , which on nios2
> includes and thus and which
> again includes .
>
> It turns out the #include in isn't
> necessary at all since none of it definitions are used there, so remove
> it alltogether.
Thanks for your fix but I have already posted a different one [1] which
doesn't include pgtable.h because this turned out to be a problem on
m68k already. I am just waiting for Andrew to drop the previous patch
and replace it with the one pointed out.
[1] http://lkml.kernel.org/r/20170503063750.gc1...@dhcp22.suse.cz
>
> Build tested on
> - nios2: 10m50_defconfig
> - x86: allyesconfig, various randconfigs
> - arm: tegra_defconfig, various randconfigs
>
> Cc: Michal Hocko
> Cc: Ley Foon Tan
> Signed-off-by: Tobias Klauser
> ---
> include/asm-generic/io.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 7ef015eb3403..fe5e01fbed54 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -764,7 +764,6 @@ static inline void iowrite64_rep(volatile void __iomem
> *addr,
>
> #ifdef __KERNEL__
>
> -#include
> #define __io_virt(x) ((void __force *)(x))
>
> #ifndef CONFIG_GENERIC_IOMAP
> --
> 2.12.2
>
--
Michal Hocko
SUSE Labs
Re: [linux-next][bock] WARNING: CPU: 22 PID: 0 at block/blk-core.c:2655 .blk_update_request+0x4f8/0x500
On Mon, May 08, 2017 at 08:00:41AM -0600, Jens Axboe wrote: > Christoph, Martin - any ideas? Trace from Abdul below. Btw, what page size does the system have? > > WARNING: CPU: 12 PID: 0 at block/blk-core.c:2651 > .blk_update_request+0x4cc/0x4e0 Any knowledge from tracing or printk on what command is complete? Both req_op type and SCSI command?
[PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware
The Raspberry Pi startup stub files for multi-core BCM27XX processors make the secondary CPUs spin until the corresponding mailbox is written. These stubs are loaded at physical address 0x0xxx (as seen by the ARMs), but this page will be reused by the kernel unless it is explicitly reserved, causing the waiting cores to execute random code. Use the /memreserve/ Device Tree directive to mark the first page as off-limits to the kernel. See: https://github.com/raspberrypi/linux/issues/1989 Signed-off-by: Phil Elwell --- Changes in V2: - Rebase against linux-next - Drop downstream-only patch arch/arm/boot/dts/bcm283x.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi index a3106aa..6d12c3e8 100644 --- a/arch/arm/boot/dts/bcm283x.dtsi +++ b/arch/arm/boot/dts/bcm283x.dtsi @@ -3,6 +3,8 @@ #include #include +/memreserve/ 0x 0x1000; + /* This include file covers the common peripherals and configuration between * bcm2835 and bcm2836 implementations, leaving the CPU configuration to * bcm2835.dtsi and bcm2836.dtsi. -- 1.9.1
Re: [PATCH] ARM: dts: bcm283x: Reserve first page for firmware
Hi Phil, Am 09.05.2017 um 10:20 schrieb Phil Elwell: > The Raspberry Pi startup stub files for multi-core BCM283X processors > make the secondary CPUs spin until the corresponding mailbox is > written. These stubs are loaded at physical address 0x0xxx (as seen > by the ARMs), but this page will be reused by the kernel unless it is > explicitly reserved, causing the waiting cores to execute random code. > > Use the /memreserve/ Device Tree directive to mark the first page as > off-limits to the kernel. > > See: https://github.com/raspberrypi/linux/issues/1989 > > Signed-off-by: Phil Elwell > --- > arch/arm/boot/dts/bcm2710-rpi-3-b.dts | 4 could you please rebase your patch on a upstream tree (e.g. linux-next)? There has never been such a file. > arch/arm/boot/dts/bcm283x.dtsi| 2 ++ > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/boot/dts/bcm2710-rpi-3-b.dts > b/arch/arm/boot/dts/bcm2710-rpi-3-b.dts > index b21d286..cbec919 100644 > --- a/arch/arm/boot/dts/bcm2710-rpi-3-b.dts > +++ b/arch/arm/boot/dts/bcm2710-rpi-3-b.dts > @@ -1,9 +1,5 @@ > /dts-v1/; > > -#ifdef RPI364 > -/memreserve/ 0x 0x1000; > -#endif > - > #include "bcm2710.dtsi" > #include "bcm283x-rpi-smsc9514.dtsi" > > diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi > index 7d58cd7..0bc1932 100644 > --- a/arch/arm/boot/dts/bcm283x.dtsi > +++ b/arch/arm/boot/dts/bcm283x.dtsi > @@ -3,6 +3,8 @@ > #include > #include > > +/memreserve/ 0x 0x1000; > + Would be nice to have a short comment within the dtsi file explaining what this reserve contains. Thanks Stefan > /* This include file covers the common peripherals and configuration between > * bcm2835 and bcm2836 implementations, leaving the CPU configuration to > * bcm2835.dtsi and bcm2836.dtsi.
Re: [PATCH] perf, tools: Support srccode output
On Mon, May 08, 2017 at 01:22:05PM -0700, Andi Kleen wrote:
SNIP
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index ebfa5d92358a..790ac730b162 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -17,6 +17,7 @@
> #include
> #include "srcline.h"
> #include "unwind.h"
> +#include "srccode.h"
>
> static void __maps__insert(struct maps *maps, struct map *map);
>
> @@ -414,6 +415,57 @@ int map__fprintf_srcline(struct map *map, u64 addr,
> const char *prefix,
> return ret;
> }
>
> +int map__fprintf_srccode(struct map *map, u64 addr,
> + const char *prefix, FILE *fp,
> + struct srccode_state *state)
> +{
what's the 'prefix' for? it's always passed as ""
jirka
Re: [PATCH] perf, tools: Support srccode output
On Mon, May 08, 2017 at 01:22:05PM -0700, Andi Kleen wrote: SNIP > diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c > index df051a52393c..542bfa7db53c 100644 > --- a/tools/perf/util/srcline.c > +++ b/tools/perf/util/srcline.c > @@ -479,6 +479,35 @@ char *__get_srcline(struct dso *dso, u64 addr, struct > symbol *sym, > return srcline; > } > > +/* Returns filename and fills in line number in line */ > +char *get_srcline_split(struct dso *dso, u64 addr, > + bool unwind_inlines, unsigned *line) no need to pass unwind_inlines as arg if it's always true jirka
Re: [PATCH v4] staging: lustre: llite: Fix variable length array warning
On Tue, May 09, 2017 at 11:31:36AM +0300, Dan Carpenter wrote: > Just ignore the warning. > Thank you for your comments on this patch.
