Re: [PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue
On Thu, 2015-07-09 at 11:05 +0530, Sudip Mukherjee wrote: > On Thu, Jul 09, 2015 at 08:20:57AM +0530, rcodin wrote: > > From: Ronit Halder > > You do not need a From: here. Please fix your gitconfig file and > git send-email will give your name correctly in the email header. > > regards > sudip thanks for pointing it sudip. Sorry for the stupid mistake, version 2 of the patch is coming. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN
* Andy Lutomirski wrote: > >> I look forward to it. > >> > >> However: I imagine that, if you do this, you may need to be quite careful > >> about an x86_32-ism. Currently, if you have a pt_regs pointer for the > >> current entry and user_mode(regs) returns true, then regs == > >> current_pt_regs(). If you let user mode run with EFLAGS.VM set with the > >> normal tss.sp0, then this will no longer be true, as the extra-long > >> entry-from-v8086 frame will shift pt_regs by a few bytes. I don't know > >> whether this matters, but I can imagine it causing do_signal to explode. > >> *shudder* > > > > I am aware that pt_regs is in a fixed location on the stack. What I plan > > to > > do is increase the padding at the top of the stack if VM86 is configured, > > to > > reserve space for the extra segment registers. Then it will move tss.sp0 > > up > > 16 bytes when entering vm86 mode so that the longer IRET frame is in the > > right > > place. > > > > Hmm, should work. > > I wonder if the right way to do this is to set a TIF_VM86 flag and do the > fixups > in enter_from_user_mode and prepare_return_to_usermode. See the patches I > just > sent (and tip/x88/asm, which they apply to). > > Without something like that, we'll be in the awkward position of having some > of > the selectors (DS, ES, FS, and GS) in both the normal pt_regs slot and in the > extended hardware frame during execution of normal vm86-unaware kernel code. > If, on the other hand, we copied the selectors across in enter_from_user_mode > and prepare_return_from_usermode, then pt_regs would work normally even for > tasks that are running in v8086 mode. > > regs->flags & X86_EFLAGS_VM will be true regardless, so all of the asm that > decides to invoke those helpers should work fine. Btw., has anyone considered an entirely different approach: using KVM's instruction emulator to emulate vm86 16-bit code execution? Basically the vm86 system call would be kept compatible, but fully emulated, the CPU never enters true 16-bit mode, just iterates pt_regs as if it had. This approach has four main advantages: - we could remove the fragile vm86 code from the entry code - it might even be faster for certain workloads than faulting in and out all the time and using ancient, fragile hardware mode of the CPU. (For example it could detect the VGA screen write patterns and accelerate them.) - it could be made to work on 64-bit as well, FWIIW - it would provide another angle of testing for the KVM emulator Hm? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm64: dts: mediatek: add mt6795 support
> > + chosen {
> > + bootargs = "console=ttyS0,921600n8 earlyprintk";
>
> PLease get rid of bootargs here; earlyprintk doesn't do anything on
> arm64 (it's earlycon these days), and you can specify the serial
> configuration in stdout-path, so please use that instead.
>
Got it. Will remove bootargs & use stdout-path only.
> > + stdout-path =
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> > new file mode 100644
> > index 000..832be20
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> > @@ -0,0 +1,164 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Mars.C
> > + *
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +
> > +/ {
> > + compatible = "mediatek,mt6795";
> > + interrupt-parent = <>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x000>;
> > + };
> > +
> > + cpu1: cpu@1 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x001>;
> > + };
>
> No enable-method? Does your FW patch that in?
This patch only provides single core to boot.The proper enable-method
for SMP boot is under discussion in our site. Will complete
enable-method when providing our solution to SMP boot in the other patch
set.
>
> > +
> > + cpu2: cpu@2 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x002>;
> > + };
> > +
> > + cpu3: cpu@3 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x003>;
> > + };
> > +
> > + cpu4: cpu@4 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x100>;
> > + };
>
> The unit-address should match the reg (e.g. this should be cpu@100).
Got it. Will fix this.
>
> > +
> > + cpu5: cpu@5 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x101>;
> > + };
> > +
> > + cpu6: cpu@6 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x102>;
> > + };
> > +
> > + cpu7: cpu@7 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x103>;
> > + };
> > + };
> > +
> > + clocks {
> > + system_clk: dummy13m {
> > + compatible = "fixed-clock";
> > + clock-frequency = <1300>;
> > + #clock-cells = <0>;
> > + };
> > +
> > + rtc_clk: dummy32k {
> > + compatible = "fixed-clock";
> > + clock-frequency = <32000>;
> > + #clock-cells = <0>;
> > + };
> > +
> > + uart_clk: dummy26m {
> > + compatible = "fixed-clock";
> > + clock-frequency = <2600>;
> > + #clock-cells = <0>;
> > + };
> > + };
>
> Get rid of the clocks node and place these directly under the root node.
Got it. Will fix it.
>
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupt-parent = <>;
> > + interrupts = > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > + };
>
> The mask is wrong.
They should be GIC_CPU_MASK_SIMPLE(8). Will fix these.
Thanks for your suggestions.
>
> Thanks,
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [RFT PATCH 1/2] i2c: tegra: update CONFIG_LOAD for new conifiguration
On Thursday 09 July 2015 02:06 AM, Stephen Warren wrote: On 06/30/2015 04:54 AM, Laxman Dewangan wrote: Signed-off-by: Laxman Dewangan Signed-off-by: Chaitanya Bandi I'm not sure why Chaitanya's S-o-b is there and listed last if he's not the patch author. If he wrote the patch, he should be the git author and his S-o-b should be first. If he didn't and you simply based this patch on work by Chaitanya, then his S-o-b probably shouldn't be present, and yours would be last since you're submitting the patch. The patch I created is based on Chaitanya's work, edited on his work to match with mainline. --- Stephen/Andrew, I need help on testing this on other platform. I tested this on T210. I'm puzzled how this was tested on T210, since it isn't supported upstream yet. We tested this as: - K318 kernel release + i2c subsystem from linux-next in downstream boards. - Chrome-OS team on smaug with their tree. The series, Tested-by: Stephen Warren Thanks for testing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue
On Thu, Jul 09, 2015 at 08:20:57AM +0530, rcodin wrote: > From: Ronit Halder You do not need a From: here. Please fix your gitconfig file and git send-email will give your name correctly in the email header. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] serial: 8250: Allow to skip autoconfig_irq() for a console
Hi Peter and Prarit, On 2015/07/08 23:00, Prarit Bhargava wrote: > > > On 07/08/2015 09:51 AM, Peter Hurley wrote: >> Hi Prarit, >> >> On 07/08/2015 08:53 AM, Prarit Bhargava wrote: >>> >>> >>> On 07/08/2015 07:55 AM, Peter Hurley wrote: Hi Taichi, On 06/05/2015 06:03 AM, Taichi Kageyama wrote: > This patch provides a new parameter as a workaround of the following > problem. It allows us to skip autoconfig_irq() and to use a well-known irq > number for a console even if CONFIG_SERIAL_8250_DETECT_IRQ is defined. > > There're cases where autoconfig_irq() fails during boot. > In these cases, the console doesn't work in interrupt mode, > the mode cannot be changed anymore, and "input overrun" > (which can make operation mistakes) happens easily. > This problem happens with high rate every boot once it occurs > because the boot sequence is always almost same. > > autoconfig_irq() assumes that a CPU can handle an interrupt from a serial > during the waiting time, but there're some cases where the CPU cannot > handle the interrupt for longer than the time. It completely depends on > how other functions work on the CPU. Ideally, autoconfig_irq() should be > fixed Thank you for your comments. It completely depends on how long some other driver has interrupts disabled, Agree. which is a problem that needs fixed _in that driver_. autoconfig_irq() does not need fixing. Peter, ideally, you're right. However, we cannot assume how long other drivers disable interrupts. That's why I introduced this workaround. In my opinion, a console is important and always should be available even if other drivers have a bad behavior. A typical cause of this behavior is printk spew from overly-instrumented debugging of some driver (trace_printk is better suited to heavy instrumentation). >>> >>> Peter, I understand what you're saying, however the problem is that this is >>> the >>> serial driver which is one of, if not _the_ main debug output mechanism in >>> the >>> kernel. I tried fixing the one of them, 8250 driver. "[PATCH 1/2] serial: 8250: Fix autoconfig_irq() to avoid race conditions". https://lkml.org/lkml/2015/6/5/218 The problem can happen when the drivers show just info level message during boot. It depends on the timing completely. >>> >>> I'm not sure I agree with doing this patch, but perhaps an easier approach >>> would >>> be to add a debug kernel parameter like "serial.force_irq=4" to force the >>> irq to >>> a previously known good value? That way the issue of the broken driver can >>> be >>> debugged. Prarit, I think it's good if the serial id can be also specified. I thought adding irq option to "console" kernel parameter before, but it was not good idea because the impact was not small and passing irq# was not required in most cases. - PnP serial device can get valid irq# - Most on-board serial for console use legacy fixed irq#, like irq3, irq4. So, I designed this patch like below. - It allows console serial to skip autoconfig_irq. Actually I assumes console serial uses a typical irq# in old_serial_port[], but it's the same case where CONFIG_SERIAL_8250_DETECT_IRQ is not defined. - It allows non-console serial to kick autoconfig_irq. setserial command can try it again later if it fails on boot time. >> >> For debugging purposes, can you use a kernel built with >> CONFIG_SERIAL_8250_DETECT_IRQ=n? I know "CONFIG_SERIAL_8250_DETECT_IRQ=n" is one of solutions because autoconfig_irq() is not used on boot time in this case. However, I know some Linux distributions actually use this config and I assume someone may require it. >> >> What is the platform and device type? >> > > Taichi? I saw the original problem on x86-64 platforms with RHEL6.6. The serial was SOL(serial over LAN), not registered as PnP device. Thanks, Taichi > > P. > >> Regards, >> Peter Hurley >> >> >>> P. >>> Regards, Peter Hurley > to control these cases but as long as auto_irq algorithm is used, > it's hard to know which CPU can handle an interrupt from a serial and > to assure the interrupt of the CPU is enabled during auto_irq. > Meanwhile for legacy consoles, they actually don't require auto_irq > because they basically use well-known irq number. > For non-console serials, this workaround is not required > because setserial command can kick autoconfig_irq() again for them. > > Signed-off-by: Taichi Kageyama > Cc: Naoya Horiguchi > --- >drivers/tty/serial/8250/8250_core.c | 17 + >1 files changed, 17 insertions(+), 0 deletions(-) > > diff --git a/drivers/tty/serial/8250/8250_core.c > b/drivers/tty/serial/8250/8250_core.c > index 6bf31f2..60fda28 100644 > --- a/drivers/tty/serial/8250/8250_core.c > +++ b/drivers/tty/serial/8250/8250_core.c
[PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue
Fixed a coding style issue. Signed-off-by: Ronit Halder --- drivers/staging/android/ion/ion.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 6f48112..e44f5e6 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -1106,6 +1106,7 @@ struct dma_buf *ion_share_dma_buf(struct ion_client *client, struct ion_buffer *buffer; struct dma_buf *dmabuf; bool valid_handle; + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); mutex_lock(>lock); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] pinctrl: UniPhier: add UniPhier pinctrl core support
Hi Paul, 2015-07-09 5:39 GMT+09:00 Paul Bolle : > Hi Masahiro, > > On wo, 2015-07-08 at 14:01 +0900, Masahiro Yamada wrote: >> Actually, most of pinctrl drivers are boolean, but most of them >> conventionally have MODULE_AUTHOR, THIS_MODULE, etc. >> >> I do not think it looks so weird. Thought? > > It's a rather common pattern, but I think it's an anti-pattern > nevertheless. See the discussion that Shobhit Kumar, Paul Gortmaker, and > I had starting in https://lkml.org/lkml/2015/6/20/63 . > > Please let me know if you're unconvinced by the arguments brought > forward by both Pauls in that discussion. > After I read your references and thought a bit more, I am now considering to change the bool into tristate. Pinctrl drivers usually contain quite big pin tables, so it sounds somewhat reasonable to make it loadable, given that minimal pin-settings could be done in the boot-loader. Actually, some of pinctrl drivers in the mainline are already tristate. I will send v2 later with some other fixes I have noticed. Is this OK with you? -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/2] cpufreq: mediatek: Add MT8173 cpufreq driver
On 09-07-15, 09:55, Pi-Cheng Chen wrote: > That's what I did in previous version. But the reason I use the device- > driver model is to handle the defer probing issue. Since there's no > arch/arm64/mach-mediatek/ directory to hold the device registration > code anymore, no device tree way to match cpufreq driver > (please correct me if there's any), and initcall seems not handle > defer probing either, therefore I put both device and driver > registration in this function. I know it's crappy. :( > Do you have any suggestion to do it right and handle defer probing > properly? Sounds reasonable. Just add proper comment in code to explain that. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] drivers: dma-coherent: Change order of allocation to PAGE_SIZE
dma_alloc_from_coherent uses get_order(size) which makes carve-out
allocations not aligned on order boundaries to fail even though
they are page aligned. So wanted to know why is it required to have
the size aligned on order boundary. Changing it to get_order(PAGE_SIZE)
makes the non aligned carve-out allocations to go through.
Signed-off-by: Sricharan R
---
drivers/base/dma-coherent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 55b8398..72bdc6f 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -156,7 +156,7 @@ int dma_alloc_from_coherent(struct device *dev, ssize_t
size,
dma_addr_t *dma_handle, void **ret)
{
struct dma_coherent_mem *mem;
- int order = get_order(size);
+ int order = get_order(PAGE_SIZE);
unsigned long flags;
int pageno;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: Allow accessing freq_table for offline CPUs
On 09-07-15, 02:40, Rafael J. Wysocki wrote:
> The above sentence is completely unclear to anyone unfamiliar with the
> code in question.
>
> The fix is to access the policy data structure for the given CPU directly
> (which also returns a valid policy for offline CPUs), but the policy
> itself has to be active (meaning that at least one CPU using it is online)
> for the frequency table to be returned.
>
> Right?
Yeah..
---8<
Message-Id:
<9c37b9a711b6dc6e419e256fd62fcc93a29db4e4.1436418686.git.viresh.ku...@linaro.org>
From: Viresh Kumar
Date: Wed, 8 Jul 2015 12:53:03 +0530
Subject: [PATCH V3] cpufreq: Allow accessing freq_table for offline CPUs
Users of freq table may want to access it for any CPU from
policy->related_cpus mask. One such user is cpu-cooling layer. It gets a
list of 'clip_cpus' (equivalent to policy->related_cpus) during
registration and tries to get freq_table for the first CPU of this mask.
If the CPU, for which it tries to fetch freq_table, is offline,
cpufreq_frequency_get_table() fails. This happens because it relies on
cpufreq_cpu_get_raw() for its functioning which returns policy only for
online CPUs.
The fix is to access the policy data structure for the given CPU
directly (which also returns a valid policy for offline CPUs), but the
policy itself has to be active (meaning that at least one CPU using it
is online) for the frequency table to be returned.
Because we will be using 'cpufreq_cpu_data' now, which is internal to
cpufreq-core, lets also move cpufreq_frequency_get_table() to cpufreq.c
file.
Reported-and-tested-by: Pi-Cheng Chen
Signed-off-by: Viresh Kumar
---
V3-> Changelog improvement suggested by Rafael.
drivers/cpufreq/cpufreq.c| 9 +
drivers/cpufreq/freq_table.c | 9 -
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 36e97a5a7e20..a7b6ac6e048e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -169,6 +169,15 @@ struct kobject *get_governor_parent_kobj(struct
cpufreq_policy *policy)
}
EXPORT_SYMBOL_GPL(get_governor_parent_kobj);
+struct cpufreq_frequency_table *cpufreq_frequency_get_table(unsigned int cpu)
+{
+ struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
+
+ return policy && !policy_is_inactive(policy) ?
+ policy->freq_table : NULL;
+}
+EXPORT_SYMBOL_GPL(cpufreq_frequency_get_table);
+
static inline u64 get_cpu_idle_time_jiffy(unsigned int cpu, u64 *wall)
{
u64 idle_time;
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index df14766a8e06..dfbbf981ed56 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -297,15 +297,6 @@ int cpufreq_table_validate_and_show(struct cpufreq_policy
*policy,
}
EXPORT_SYMBOL_GPL(cpufreq_table_validate_and_show);
-struct cpufreq_policy *cpufreq_cpu_get_raw(unsigned int cpu);
-
-struct cpufreq_frequency_table *cpufreq_frequency_get_table(unsigned int cpu)
-{
- struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
- return policy ? policy->freq_table : NULL;
-}
-EXPORT_SYMBOL_GPL(cpufreq_frequency_get_table);
-
MODULE_AUTHOR("Dominik Brodowski ");
MODULE_DESCRIPTION("CPUfreq frequency table helpers");
MODULE_LICENSE("GPL");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers
On Wed, Jul 8, 2015 at 9:44 PM, Dmitry Torokhov wrote: > On Wed, Jul 08, 2015 at 06:00:41PM -0700, Dan Williams wrote: >> On Wed, Jul 8, 2015 at 5:49 PM, Dmitry Torokhov >> wrote: >> > On Wed, Jul 08, 2015 at 05:36:04PM -0700, Dan Williams wrote: >> >> On Mon, Jul 6, 2015 at 4:40 PM, Dmitry Torokhov >> >> wrote: >> >> > On Tue, Jul 07, 2015 at 01:23:15AM +0200, Luis R. Rodriguez wrote: >> >> >> On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote: >> >> >> > On Fri, Jul 3, 2015 at 11:30 AM, Luis R. Rodriguez >> >> >> > wrote: >> >> >> > > On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote: >> >> >> > >> On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov >> >> >> > >> wrote: >> >> >> > >> > Some devices take a long time when initializing, and not all >> >> >> > >> > drivers are >> >> >> > >> > suited to initialize their devices when they are open. For >> >> >> > >> > example, >> >> >> > >> > input drivers need to interrogate their devices in order to >> >> >> > >> > publish >> >> >> > >> > device's capabilities before userspace will open them. When >> >> >> > >> > such drivers >> >> >> > >> > are compiled into kernel they may stall entire kernel >> >> >> > >> > initialization. >> >> >> > >> > >> >> >> > >> > This change allows drivers request for their probe functions to >> >> >> > >> > be >> >> >> > >> > called asynchronously during driver and device registration >> >> >> > >> > (manual >> >> >> > >> > binding is still synchronous). Because async_schedule is used >> >> >> > >> > to perform >> >> >> > >> > asynchronous calls module loading will still wait for the >> >> >> > >> > probing to >> >> >> > >> > complete. >> >> >> > >> > >> >> >> > >> > Note that the end goal is to make the probing asynchronous by >> >> >> > >> > default, >> >> >> > >> > so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a >> >> >> > >> > temporary >> >> >> > >> > measure that allows us to speed up boot process while we >> >> >> > >> > validating and >> >> >> > >> > fixing the rest of the drivers and preparing userspace. >> >> >> > >> > >> >> >> > >> > This change is based on earlier patch by "Luis R. Rodriguez" >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > Signed-off-by: Dmitry Torokhov >> >> >> > >> > --- >> >> >> > >> > drivers/base/base.h| 1 + >> >> >> > >> > drivers/base/bus.c | 31 +++--- >> >> >> > >> > drivers/base/dd.c | 149 >> >> >> > >> > ++--- >> >> >> > >> > include/linux/device.h | 28 ++ >> >> >> > >> > 4 files changed, 182 insertions(+), 27 deletions(-) >> >> >> > >> >> >> >> > >> Just noticed this patch. It caught my eye because I had a hard >> >> >> > >> time >> >> >> > >> getting an open coded implementation of asynchronous probing to >> >> >> > >> work >> >> >> > >> in the new libnvdimm subsystem. Especially the messy races of >> >> >> > >> tearing >> >> >> > >> things down while probing is still in flight. I ended up >> >> >> > >> implementing >> >> >> > >> asynchronous device registration which eliminated a lot of >> >> >> > >> complexity >> >> >> > >> and of course the bugs. In general I tend to think that async >> >> >> > >> registration is less risky than async probe since it keeps wider >> >> >> > >> portions of the traditional device model synchronous >> >> >> > > >> >> >> > > but its not see -DEFER_PROBE even before async probe. >> >> >> > >> >> >> > Except in that case you know probe has been seen by the driver at >> >> >> > least once. So I see that as less of a surprise, but point taken. >> >> >> > >> >> >> > >> and leverages the >> >> >> > >> fact that the device model is already well prepared for >> >> >> > >> asynchronous >> >> >> > >> arrival of devices due to hotplug. >> >> >> > > >> >> >> > > I think this sounds reasonable, do you have your code upstream or >> >> >> > > posted? >> >> >> > >> >> >> > Yes, see nd_device_register() in drivers/nvdimm/bus.c >> >> >> >> >> >> It should be I think rather easy for Dmitry to see if he can convert >> >> >> this input >> >> >> driver (not yet upstream) to this API and see if the same issues are >> >> >> fixed. >> >> > >> >> > No, I would rather not as it means we lose error handling on device >> >> > registration. >> >> > >> >> >> >> I think this is a red herring as I don't see how async probing is any >> >> better at handling device registration errors. The error is logged >> >> and "handled" by the fact that a device fails to appear, what other >> >> action would you take? In fact libnvdimm does detect registration >> >> failures and reports that in a parent device attribute (at least for a >> >> region device and their namespace child devices). >> > >> > What is libnvdimm behavior if you try to unload a module that tries to >> > register a device but it failed? Memory leak or crash, right? >> >> No, in the case of the "region" driver it is part of the core >> libnvdimm and it is pinned while any region device is
Re: [PATCH] cpufreq: Initialize the governor again while restoring policy
On 09-07-15, 02:33, Rafael J. Wysocki wrote:
> > We also missed marking policy->governor as NULL while restoring the
> > policy. Because of that, we call __cpufreq_governor(CPUFREQ_GOV_LIMITS)
>
> How exactly does that happen?
Should have mentioned that in detail, sorry for being lazy. Hopefully
this will look better:
---8<---
Message-Id:
<5f17361741c009a7f0d8488f7f94bab80d9317fd.1436418101.git.viresh.ku...@linaro.org>
From: Viresh Kumar
Date: Wed, 8 Jul 2015 10:45:53 +0530
Subject: [PATCH V2] cpufreq: Initialize the governor again while restoring
policy
When all CPUs of a policy are hot-unplugged, we EXIT the governor but
don't mark policy->governor as NULL. This was done in order to keep last
used governor's information intact in sysfs, while the CPUs are offline.
But we also marking policy->governor as NULL while restoring the policy.
Because policy->governor still points to the last governor while policy
is restored, following sequence of event happens:
- cpufreq_init_policy() called while restoring policy
- find_governor() matches last_governor string for present governors and
returns last used governor's pointer, say ondemand. policy->governor
already has the same address, unless the governor was removed in
between.
- cpufreq_set_policy() is called with both old/new policies governor set
as ondemand.
- Because governors matched, we skip governor initialization and return
after calling __cpufreq_governor(CPUFREQ_GOV_LIMITS). Because the
governor wasn't initialized for this policy, it returned -EBUSY.
- cpufreq_init_policy() exits the policy on this error, but doesn't
destroy it properly (should be fixed separately).
- And so we enter a scenario where the policy isn't completely
initialized but used.
Fix this by setting policy->governor to NULL while restoring the policy.
Reported-and-tested-by: Pi-Cheng Chen
Reported-and-tested-by: "Jon Medhurst (Tixy)"
Tested-by: Steven Rostedt
Fixes: 18bf3a124ef8 ("cpufreq: Mark policy->governor = NULL for inactive
policies")
Signed-off-by: Viresh Kumar
---
V2: Detailed changelog
drivers/cpufreq/cpufreq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b612411655f9..2c22e3902e72 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1132,6 +1132,7 @@ static struct cpufreq_policy
*cpufreq_policy_restore(unsigned int cpu)
down_write(>rwsem);
policy->cpu = cpu;
+ policy->governor = NULL;
up_write(>rwsem);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] um: umid: Use strdup to simplify code
Replace a malloc+strcpy by an equivalent strdup in order to improve
readability.
Signed-off-by: Christophe JAILLET
---
arch/um/os-Linux/umid.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/um/os-Linux/umid.c b/arch/um/os-Linux/umid.c
index b514ead..cc9ac2e 100644
--- a/arch/um/os-Linux/umid.c
+++ b/arch/um/os-Linux/umid.c
@@ -48,12 +48,11 @@ static int __init make_uml_dir(void)
strlcat(dir, "/", sizeof(dir));
err = -ENOMEM;
- uml_dir = malloc(strlen(dir) + 1);
+ uml_dir = strdup(dir);
if (uml_dir == NULL) {
- printf("make_uml_dir : malloc failed, errno = %d\n", errno);
+ printf("make_uml_dir : strdup failed, errno = %d\n", errno);
goto err;
}
- strcpy(uml_dir, dir);
if ((mkdir(uml_dir, 0777) < 0) && (errno != EEXIST)) {
printf("Failed to mkdir '%s': %s\n", uml_dir, strerror(errno));
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] um: umid: Use tab instead of spaces
Turn some spaces into a tab to be consistent with the rest of the code.
Signed-off-by: Christophe JAILLET
---
arch/um/os-Linux/umid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/um/os-Linux/umid.c b/arch/um/os-Linux/umid.c
index c1dc892..b514ead 100644
--- a/arch/um/os-Linux/umid.c
+++ b/arch/um/os-Linux/umid.c
@@ -56,7 +56,7 @@ static int __init make_uml_dir(void)
strcpy(uml_dir, dir);
if ((mkdir(uml_dir, 0777) < 0) && (errno != EEXIST)) {
- printf("Failed to mkdir '%s': %s\n", uml_dir, strerror(errno));
+ printf("Failed to mkdir '%s': %s\n", uml_dir, strerror(errno));
err = -errno;
goto err_free;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/3] Add arm pl353 smc nand driver for xilinx zynq soc
On 07/08/2015 09:40 PM, Josh Cartwright wrote: > On Mon, Jun 08, 2015 at 11:38:35PM +0530, Punnaiah Choudary Kalluri wrote: >> The following patches add arm pl353 static memory controller driver for >> xilinx zynq soc. The arm pl353 smc supports two interfaces i.e nand and >> nor/sram memory interfaces. The current implementation supports only a >> single SMC instance and nand specific configuration. > > What's the integration plan for this guy? Looks like we missed 4.2. > It'd be swell to get have NAND support land for Zynq in 4.3. > > Assuming there is nothing else holding it back: > > Brian- I'm assuming you'll want to take this through your tree. > > It looks like most of the stuff in drivers/memory have historically gone > through arm-soc/drivers, Michal- does it make sense for you to pick up > http://lkml.kernel.org/r/1433786857-32575-1-git-send-email-punn...@xilinx.com? I am happy to take this via zynq tree and arm-soc tree if this is the right way. Josh: Also none can stop you to give us you ACK or Tested-by line. Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: systemport: Use eth_hw_addr_random
Le 07/07/15 22:19, Vaishali Thakkar a écrit :
> Use eth_hw_addr_random() instead of calling random_ether_addr().
> Here, this change is setting addr_assign_type to NET_ADDR_RANDOM.
>
> The Coccinelle semantic patch that performs this transformation
> is as follows:
>
> @@
> identifier a,b;
> @@
>
> -random_ether_addr(a->b);
> +eth_hw_addr_random(a);
>
> Signed-off-by: Vaishali Thakkar
> ---
> Note that this patch is compile tested only and I have used file
> drivers/net/ethernet/hisilicon/hix5hd2_gmac.c as a reference.
> Also, original call didn't make assignment to NET_ADDR_RANDOM. So,
> it would be good if someone can test this change.
Thanks, I will give this a try and report.
> ---
> drivers/net/ethernet/broadcom/bcmsysport.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
> b/drivers/net/ethernet/broadcom/bcmsysport.c
> index 909ad7a..4566cdf 100644
> --- a/drivers/net/ethernet/broadcom/bcmsysport.c
> +++ b/drivers/net/ethernet/broadcom/bcmsysport.c
> @@ -1793,7 +1793,7 @@ static int bcm_sysport_probe(struct platform_device
> *pdev)
> macaddr = of_get_mac_address(dn);
> if (!macaddr || !is_valid_ether_addr(macaddr)) {
> dev_warn(>dev, "using random Ethernet MAC\n");
> - random_ether_addr(dev->dev_addr);
> + eth_hw_addr_random(dev);
> } else {
> ether_addr_copy(dev->dev_addr, macaddr);
> }
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail
On Wed, Jul 8, 2015 at 8:30 PM, Wei Yang wrote:
> Hi, Yinghai
>
> This patch may introduce some problem.
>
> On my P8 machine, after applying this patch, I see following error:
>
> [0.589948] pnv_ioda_setup_pe_seg: trigger IO SEG 0
> [0.589992] pnv_ioda_setup_pe_seg: res[io 0x1000-0x3fff] 100
>
> The last 0x100 is the res->flags, which indicates the UNSET and DISABLED bit
> is not set.
Maybe we should introduce resource_disabled() for that.
Please check if attached patch would fix the problem.
Thanks
Yinghai
Subject: [PATCH] PCI: Introduce resource_disabled()
so we can cover !flags and IORESOURCE_DISABLED both.
Signed-off-by: Yinghai Lu
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 82f738e..91a7153 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -282,7 +282,7 @@ pcibios_claim_one_bus(struct pci_bus *b)
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
struct resource *r = >resource[i];
- if (r->parent || !r->start || !r->flags)
+ if (r->parent || !r->start || resource_disabled(r))
continue;
if (pci_has_flag(PCI_PROBE_ONLY) ||
(r->flags & IORESOURCE_PCI_FIXED)) {
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 7cc3be9..cc293ea 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -501,7 +501,7 @@ void pcibios_fixup_device_resources(struct pci_dev *dev)
for (idx = 0; idx < PCI_BRIDGE_RESOURCES; idx++) {
struct resource *r = >resource[idx];
- if (!r->flags || r->parent || !r->start)
+ if (resource_disabled(r) || r->parent || !r->start)
continue;
pci_claim_resource(dev, idx);
@@ -519,7 +519,7 @@ static void pcibios_fixup_bridge_resources(struct pci_dev *dev)
for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
struct resource *r = >resource[idx];
- if (!r->flags || r->parent || !r->start)
+ if (resource_disabled(r) || r->parent || !r->start)
continue;
pci_claim_bridge_resource(dev, idx);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index ae838ed..67848f8 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -705,7 +705,7 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
}
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
struct resource *res = dev->resource + i;
- if (!res->flags)
+ if (resource_disabled(res))
continue;
if (res->start == 0) {
pr_debug("PCI:%s Resource %d %016llx-%016llx [%x]",
@@ -806,7 +806,7 @@ static void pcibios_fixup_bridge(struct pci_bus *bus)
pci_bus_for_each_resource(bus, res, i) {
if (!res)
continue;
- if (!res->flags)
+ if (resource_disabled(res))
continue;
if (i >= 3 && bus->self->transparent)
continue;
@@ -993,7 +993,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
pci_domain_nr(bus), bus->number);
pci_bus_for_each_resource(bus, res, i) {
- if (!res || !res->flags
+ if (!res || resource_disabled(res)
|| res->start > res->end || res->parent)
continue;
if (bus->parent == NULL)
@@ -1095,7 +1095,8 @@ static void __init pcibios_allocate_resources(int pass)
r = >resource[idx];
if (r->parent) /* Already allocated */
continue;
- if (!r->flags || (r->flags & IORESOURCE_UNSET))
+ if (resource_disabled(r) ||
+ (r->flags & IORESOURCE_UNSET))
continue; /* Not assigned at all */
/* We only allocate ROMs on pass 1 just in case they
* have been screwed up by firmware
@@ -1226,7 +1227,7 @@ void pcibios_claim_one_bus(struct pci_bus *bus)
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
struct resource *r = >resource[i];
- if (r->parent || !r->start || !r->flags)
+ if (r->parent || !r->start || resource_disabled(r))
continue;
pr_debug("PCI: Claiming %s: ", pci_name(dev));
@@ -1286,7 +1287,7 @@ static void pcibios_setup_phb_resources(struct pci_controller *hose,
res->start = (res->start + io_offset) & 0xu;
res->end = (res->end + io_offset) & 0xu;
- if (!res->flags) {
+ if (resource_disabled(res)) {
pr_warn("PCI: I/O resource not set for host ");
pr_cont("bridge %s (domain %d)\n",
hose->dn->full_name, hose->global_number);
@@ -1306,7 +1307,7 @@ static void pcibios_setup_phb_resources(struct pci_controller *hose,
/* Hookup PHB Memory resources */
for (i = 0; i < 3; ++i) {
res = >mem_resources[i];
- if (!res->flags) {
+ if (resource_disabled(res)) {
if (i > 0)
continue;
pr_err("PCI: Memory resource 0 not set for ");
diff --git a/arch/mn10300/unit-asb2305/pci-asb2305.c b/arch/mn10300/unit-asb2305/pci-asb2305.c
index b5b036f..a249821 100644
--- a/arch/mn10300/unit-asb2305/pci-asb2305.c
+++ b/arch/mn10300/unit-asb2305/pci-asb2305.c
@@ -103,7 +103,7 @@ static void __init pcibios_allocate_bus_resources(struct list_head *bus_list)
idx < PCI_NUM_RESOURCES;
idx++) {
r = >resource[idx];
-if (!r->flags)
+if (resource_disabled(r))
continue;
if (!r->start
Re: Linux 4.2-rc1
On Thu, Jul 9, 2015 at 11:17 AM, Linus Torvalds wrote: > On Wed, Jul 8, 2015 at 5:58 PM, Ming Lei wrote: >> On Thu, Jul 9, 2015 at 1:29 AM, Linus Torvalds >> wrote: >>> Also, it looks like you need to hold the "fw_lock" to even look at >>> that pointer, since the buffer can get reallocated etc. >> >> Yes, the above code with holding 'fw_lock' is right fix for the issue since >> sysfs read can happen anytime, and there is one race between firmware >> request abort and reading uevent of sysfs. > > So if fw_priv->buf is NULL, what should we do? > > Should we skip the TIMEOUT= and ASYNC= fields too? When the request is aborted, the firmware device will be removed, so it is OK to skip the two fields. > > Something like the attached, perhaps? Looks it is fine. > > Shuah, how reproducible is this? Does this (completely untested) patch > make any difference? > > Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] cpufreq: Add ->get_rate() driver callback
On 09-07-15, 01:41, Rafael J. Wysocki wrote: > On Wednesday, July 08, 2015 04:07:32 PM Viresh Kumar wrote: > > CPUFreq drivers today support a ->get(cpu) callback, which returns > > current rate of a CPU. The problem with ->get() is that it takes a cpu > > number as parameter and this unnecessarily makes things complex. > > > > Firstly the core gets the cpu number by doing operation 'policy->cpu' on > > the policy and then many drivers need to get the policy back and so do > > cpufreq_cpu_get(cpu) on the passed cpu. > > > > As cpufreq core works on policies, it would be better if we pass them > > 'policy' directly and drivers can use policy->cpu if that's all they > > need. > > > > Hence, this patch adds in another callback, ->get_rate() which does > > exactly the same work as ->get(), just that we pass 'policy' as > > parameter instead of 'cpu'. > > > > The plan is to migrate all drivers to this new callback and remove > > ->get() after that. > > > > Signed-off-by: Viresh Kumar > > --- > > Hi Rafael, > > > > I hope you are fine with this stuff :), once you approve I will get > > other patches to migrate existing drivers to this interface. > > I'm generally fine with it, but please target it at 4.4 at the earliest. Sure, but I was a bit curious on why 4.4 and not 4.3 ? as we are still at 4.2-rc1 today, and these patches can be done fairly quickly. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Kernel splat when taking CPUs offline
On 09-07-15, 00:25, Steven Rostedt wrote: > On Thu, 9 Jul 2015 09:34:45 +0530 > Viresh Kumar wrote: > > > > I think it might be related to what I chased down yesterday: > > > > http://marc.info/?l=linux-kernel=143633485824975=2 > > > > @Steven: Can you please give this a try ? > > > > Yes that seems to fix my issue as well. > > Tested-by: Steven Rostedt Awesome, so the problem was that cpufreq_set_policy() was failing because of the latest bug I planted :), and that caused ->exit() but didn't free the policy completely. (I have fixed that as well in a separate patch). And so you are hitting a policy which has already exited. Sorry about that :) -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: let __sched_period() use rq cfs's nr_running
On Wed, Jul 08, 2015 at 09:19:14AM +0900, Byungchul Park wrote: > On Tue, Jul 07, 2015 at 01:28:18PM -0700, Cong Wang wrote: > > On Mon, Jul 6, 2015 at 9:40 PM, wrote: > > > From: Byungchul Park > > > > > > __sched_period() returns a period which a rq can have. the period has to > > > be > > > stretched by the number of task *the rq has*, when nr_running > > > > nr_latency. > > > otherwise, task slice can be very smaller than > > > sysctl_sched_min_granularity > > > depending on the position of tg hierarchy when CONFIG_FAIR_GROUP_SCHED. > > > > > > Hmm, rq_of(cfs_rq)->cfs should point to the root cfs_rq whose > > ->nr_running is number of running entities at root level? This > > doesn't look right. > > hello, cong wang, > > __sched_period() returns a root level period now. stretching the period with > a local task group's nr_running is meaningless for getting this period. > is there something i missed? :) i am very sorry for my wrong patch, with which i cannot achieve what i intend. what i intended is to use rq_of(cfs_rq)'s nr_number, not rq_of(cfs_rq)->cfs's, so that __sched_period() returns a period which a rq can have. i need resend patch :( but i wonder what do you think about my basic concern? thank you, byungchul > > thank you, > byungchul > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.1 00/56] 4.1.2-stable review
On Wed, Jul 08, 2015 at 12:34:49AM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.1.2 release. > There are 56 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 Fri Jul 10 07:31:19 UTC 2015. > Anything received after that time might be too late. Compiled and booted on x86_32. No errors in dmesg. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] neterion: s2io: Use module_pci_driver
Use module_pci_driver for drivers whose init and exit functions
only register and unregister, respectively.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@a@
identifier f, x;
@@
-static f(...) { return pci_register_driver(); }
@b depends on a@
identifier e, a.x;
statement S;
@@
-static e(...) {
-pci_unregister_driver();
-DBG_PRINT(INIT_DBG,"S");
- }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_pci_driver;
@@
-module_exit(e);
+module_pci_driver(x);
Signed-off-by: Vaishali Thakkar
---
drivers/net/ethernet/neterion/s2io.c | 26 +-
drivers/net/ethernet/neterion/s2io.h | 2 --
2 files changed, 1 insertion(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/neterion/s2io.c
b/drivers/net/ethernet/neterion/s2io.c
index c281117..2d1b942 100644
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -8226,31 +8226,7 @@ static void s2io_rem_nic(struct pci_dev *pdev)
pci_disable_device(pdev);
}
-/**
- * s2io_starter - Entry point for the driver
- * Description: This function is the entry point for the driver. It verifies
- * the module loadable parameters and initializes PCI configuration space.
- */
-
-static int __init s2io_starter(void)
-{
- return pci_register_driver(_driver);
-}
-
-/**
- * s2io_closer - Cleanup routine for the driver
- * Description: This function is the cleanup routine for the driver. It
- * unregisters the driver.
- */
-
-static __exit void s2io_closer(void)
-{
- pci_unregister_driver(_driver);
- DBG_PRINT(INIT_DBG, "cleanup done\n");
-}
-
-module_init(s2io_starter);
-module_exit(s2io_closer);
+module_pci_driver(s2io_driver);
static int check_L2_lro_capable(u8 *buffer, struct iphdr **ip,
struct tcphdr **tcp, struct RxD_t *rxdp,
diff --git a/drivers/net/ethernet/neterion/s2io.h
b/drivers/net/ethernet/neterion/s2io.h
index d89b6ed..6c5997d 100644
--- a/drivers/net/ethernet/neterion/s2io.h
+++ b/drivers/net/ethernet/neterion/s2io.h
@@ -1085,8 +1085,6 @@ static void s2io_txpic_intr_handle(struct s2io_nic *sp);
static void tx_intr_handler(struct fifo_info *fifo_data);
static void s2io_handle_errors(void * dev_id);
-static int s2io_starter(void);
-static void s2io_closer(void);
static void s2io_tx_watchdog(struct net_device *dev);
static void s2io_set_multicast(struct net_device *dev);
static int rx_osm_handler(struct ring_info *ring_data, struct RxD_t * rxdp);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] dt-bindings: pwm: add MediaTek display PWM bindings
On Thu, Jul 9, 2015 at 10:45 AM, YH Huang wrote:
>
> On Wed, 2015-07-08 at 20:11 +0800, Daniel Kurtz wrote:
> > On Mon, Jul 6, 2015 at 9:29 PM, YH Huang wrote:
> > > Document the device-tree binding of MediatTek display PWM.
> > > The PWM has one channel to control the backlight brightness for display.
> > > It supports MT8173 and MT6595.
> > >
> > > Signed-off-by: YH Huang
> > > ---
> > > .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 24
> > > ++
> > > 1 file changed, 24 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > new file mode 100644
> > > index 000..757b974
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > @@ -0,0 +1,24 @@
> > > +MediaTek display PWM controller
> > > +
> > > +Required properties:
> > > + - compatible: should be "mediatek,-disp-pwm"
> > > + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> > > + - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> > > + - reg: physical base address and length of the controller's registers
> > > + - #pwm-cells: must be 2. See pwm.txt in this directory for a
> > > description of
> > > + the cell format
> > > + - clocks: phandle and clock specifier of the PWM reference clock
> > > + - clock-names: must contain the following
> > > + - "main": clock used to generate PWM signals
> > > + - "mm": sync signals from the modules of mmsys
> > > +
> > > +Example:
> > > + pwm0: pwm@1401e000 {
> > > + compatible = "mediatek,mt8173-disp-pwm",
> > > +"mediatek,mt6595-disp-pwm";
> > > + reg = <0 0x1401e000 0 0x1000>;
> > > + #pwm-cells = <2>;
> > > + clocks = < CLK_MM_DISP_PWM026M>,
> > > +< CLK_MM_DISP_PWM0MM>;
> > > + clock-names = "main", "mm";
> >
> > Should we include the pinctrl settings here to enable the PWM output?
> >
>
> Since we use pwm-backlight driver to control backlight, we should enable
> PWM output in the backlight node.
>
> Ref:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>
The pwm-backlight binding specifies which pwm the backlight driver
should use, and how to use it.
I believe actually configuring the output pin for the pwm via pinctl
belongs to the pwm binding.
Regards,
0Dan
>
> Regards,
> YH Huang
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers
On Wed, Jul 08, 2015 at 06:00:41PM -0700, Dan Williams wrote: > On Wed, Jul 8, 2015 at 5:49 PM, Dmitry Torokhov > wrote: > > On Wed, Jul 08, 2015 at 05:36:04PM -0700, Dan Williams wrote: > >> On Mon, Jul 6, 2015 at 4:40 PM, Dmitry Torokhov > >> wrote: > >> > On Tue, Jul 07, 2015 at 01:23:15AM +0200, Luis R. Rodriguez wrote: > >> >> On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote: > >> >> > On Fri, Jul 3, 2015 at 11:30 AM, Luis R. Rodriguez > >> >> > wrote: > >> >> > > On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote: > >> >> > >> On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov > >> >> > >> wrote: > >> >> > >> > Some devices take a long time when initializing, and not all > >> >> > >> > drivers are > >> >> > >> > suited to initialize their devices when they are open. For > >> >> > >> > example, > >> >> > >> > input drivers need to interrogate their devices in order to > >> >> > >> > publish > >> >> > >> > device's capabilities before userspace will open them. When such > >> >> > >> > drivers > >> >> > >> > are compiled into kernel they may stall entire kernel > >> >> > >> > initialization. > >> >> > >> > > >> >> > >> > This change allows drivers request for their probe functions to > >> >> > >> > be > >> >> > >> > called asynchronously during driver and device registration > >> >> > >> > (manual > >> >> > >> > binding is still synchronous). Because async_schedule is used to > >> >> > >> > perform > >> >> > >> > asynchronous calls module loading will still wait for the > >> >> > >> > probing to > >> >> > >> > complete. > >> >> > >> > > >> >> > >> > Note that the end goal is to make the probing asynchronous by > >> >> > >> > default, > >> >> > >> > so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a > >> >> > >> > temporary > >> >> > >> > measure that allows us to speed up boot process while we > >> >> > >> > validating and > >> >> > >> > fixing the rest of the drivers and preparing userspace. > >> >> > >> > > >> >> > >> > This change is based on earlier patch by "Luis R. Rodriguez" > >> >> > >> > > >> >> > >> > > >> >> > >> > Signed-off-by: Dmitry Torokhov > >> >> > >> > --- > >> >> > >> > drivers/base/base.h| 1 + > >> >> > >> > drivers/base/bus.c | 31 +++--- > >> >> > >> > drivers/base/dd.c | 149 > >> >> > >> > ++--- > >> >> > >> > include/linux/device.h | 28 ++ > >> >> > >> > 4 files changed, 182 insertions(+), 27 deletions(-) > >> >> > >> > >> >> > >> Just noticed this patch. It caught my eye because I had a hard > >> >> > >> time > >> >> > >> getting an open coded implementation of asynchronous probing to > >> >> > >> work > >> >> > >> in the new libnvdimm subsystem. Especially the messy races of > >> >> > >> tearing > >> >> > >> things down while probing is still in flight. I ended up > >> >> > >> implementing > >> >> > >> asynchronous device registration which eliminated a lot of > >> >> > >> complexity > >> >> > >> and of course the bugs. In general I tend to think that async > >> >> > >> registration is less risky than async probe since it keeps wider > >> >> > >> portions of the traditional device model synchronous > >> >> > > > >> >> > > but its not see -DEFER_PROBE even before async probe. > >> >> > > >> >> > Except in that case you know probe has been seen by the driver at > >> >> > least once. So I see that as less of a surprise, but point taken. > >> >> > > >> >> > >> and leverages the > >> >> > >> fact that the device model is already well prepared for > >> >> > >> asynchronous > >> >> > >> arrival of devices due to hotplug. > >> >> > > > >> >> > > I think this sounds reasonable, do you have your code upstream or > >> >> > > posted? > >> >> > > >> >> > Yes, see nd_device_register() in drivers/nvdimm/bus.c > >> >> > >> >> It should be I think rather easy for Dmitry to see if he can convert > >> >> this input > >> >> driver (not yet upstream) to this API and see if the same issues are > >> >> fixed. > >> > > >> > No, I would rather not as it means we lose error handling on device > >> > registration. > >> > > >> > >> I think this is a red herring as I don't see how async probing is any > >> better at handling device registration errors. The error is logged > >> and "handled" by the fact that a device fails to appear, what other > >> action would you take? In fact libnvdimm does detect registration > >> failures and reports that in a parent device attribute (at least for a > >> region device and their namespace child devices). > > > > What is libnvdimm behavior if you try to unload a module that tries to > > register a device but it failed? Memory leak or crash, right? > > No, in the case of the "region" driver it is part of the core > libnvdimm and it is pinned while any region device is active. No, not quite. Let's take a look for example at nd_btt_probe(). It calls __nd_btt_create() which in turn calls __nd_device_register() which returns void and
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
> I recommend creating an alias or script that does: > > $ git log --pretty=fixes -n 1 $commit | xclip > FWIW, having finally got around to doing this, I found I first needed the following snippet in ~/.gitconfig from https://www.kernel.org/doc/Documentation/SubmittingPatches [core] abbrev = 12 [pretty] fixes = Fixes: %h (\"%s\") Otherwise git doesn't know what the pretty format is. -- Regards, Daniel signature.asc Description: This is a digitally signed message part
Re: New suspicious RCU usage in 4.2.0-rc1 plus patch
On Thu, Jul 09, 2015 at 02:50:25AM +0200, Rafael J. Wysocki wrote:
> Hi Paul,
>
> Something seems to have changed in RCU in 4.2-rc1, as it is now complaining
> about a tracepoint in tick_freeze() like this:
>
> [ 66.340508] ===
> [ 66.340509] [ INFO: suspicious RCU usage. ]
> [ 66.340512] 4.2.0-rc1+ #1691 Not tainted
> [ 66.340513] ---
> [ 66.340515] /scratch/rafael/work/linux-pm/include/trace/events/power.h:193
> suspicious rcu_dereference_check() usage!
> [ 66.340517]
> other info that might help us debug this:
>
> [ 66.340519]
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> [ 66.340520] RCU used illegally from extended quiescent state!
> [ 66.340522] 1 lock held by swapper/0/0:
> [ 66.340538] #0: (tick_freeze_lock){..}, at: []
> tick_freeze+0x19/0x230
> [ 66.340539]
> stack backtrace:
> [ 66.340543] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc1+ #1691
> [ 66.340544] Hardware name: TOSHIBA PORTEGE R500/Portable PC, BIOS Version
> 1.60 03/04/2008
> [ 66.340550] 0001 81c03e48 817ab99d
> 0004
> [ 66.340555] 81c10500 81c03e78 810a2dd7
> 0003
> [ 66.340560] 81a6b2c7 a00b3090
> 81c03ea8
> [ 66.340561] Call Trace:
> [ 66.340567] [] dump_stack+0x4f/0x7b
> [ 66.340573] [] lockdep_rcu_suspicious+0xe7/0x120
> [ 66.340577] [] tick_freeze+0x188/0x230
> [ 66.340582] [] cpuidle_enter_freeze+0x30/0x80
> [ 66.340586] [] cpu_startup_entry+0x455/0x490
> [ 66.340591] [] rest_init+0x132/0x140
> [ 66.340595] [] ? csum_partial_copy_generic+0x170/0x170
> [ 66.340601] [] start_kernel+0x484/0x491
> [ 66.340604] [] ? set_init_arg+0x58/0x58
> [ 66.340608] [] x86_64_start_reservations+0x2a/0x2c
> [ 66.340611] [] x86_64_start_kernel+0xe7/0xeb
>
> It didn't complained about it before, AFAICS, but in any case the simplest
> way to deal with it seems to be to put tick_freeze() under RCU_NONIDLE()
> like in the patch below.
The above warning won't show up unless you have lockdep enabled, so
maybe that is what changed? (Recent RCU changes could expose additional
uses of RCU from offline CPUs, but shouldn't be any change from idle
CPUs. Famous last words!)
> I wonder what you think about it?
Reviewed-by: Paul E. McKenney
> Thanks,
> Rafael
>
>
> ---
> From: Rafael J. Wysocki
> Subject: cpuidle / s2i: Prevent RCU from complaining about tick_freeze()
>
> Put tick_freeze() under RCU_NONIDLE() to prevent RCU from complaining
> about suspicious RCU usage in idle by trace_suspend_resume() called
> from there.
>
> While at it, fix a comment related to another usage of RCU_NONIDLE()
> in enter_freeze_proper().
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpuidle/cpuidle.c |9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> Index: linux-pm/drivers/cpuidle/cpuidle.c
> ===
> --- linux-pm.orig/drivers/cpuidle/cpuidle.c
> +++ linux-pm/drivers/cpuidle/cpuidle.c
> @@ -112,7 +112,12 @@ int cpuidle_find_deepest_state(struct cp
> static void enter_freeze_proper(struct cpuidle_driver *drv,
> struct cpuidle_device *dev, int index)
> {
> - tick_freeze();
> + /*
> + * trace_suspend_resume() called by tick_freeze() for the last CPU
> + * executing it contains RCU usage regarded as invalid in the idle
> + * context, so tell RCU about that.
> + */
> + RCU_NONIDLE(tick_freeze());
> /*
>* The state used here cannot be a "coupled" one, because the "coupled"
>* cpuidle mechanism enables interrupts and doing that with timekeeping
> @@ -122,7 +127,7 @@ static void enter_freeze_proper(struct c
> WARN_ON(!irqs_disabled());
> /*
>* timekeeping_resume() that will be called by tick_unfreeze() for the
> - * last CPU executing it calls functions containing RCU read-side
> + * first CPU executing it calls functions containing RCU read-side
>* critical sections, so tell RCU about that.
>*/
> RCU_NONIDLE(tick_unfreeze());
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Kernel splat when taking CPUs offline
On Thu, 9 Jul 2015 09:34:45 +0530 Viresh Kumar wrote: > I think it might be related to what I chased down yesterday: > > http://marc.info/?l=linux-kernel=143633485824975=2 > > @Steven: Can you please give this a try ? > Yes that seems to fix my issue as well. Tested-by: Steven Rostedt Thanks! -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0 00/55] 4.0.8-stable review
On Wed, Jul 08, 2015 at 12:34:35AM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.0.8 release. > There are 55 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 Fri Jul 10 07:31:26 UTC 2015. > Anything received after that time might be too late. Compiled and booted on x86_32. No errors in dmesg. But when tried sudo make kselftest, it gave: Makefile:29: *** missing separator. Stop. make: *** [kselftest] Error 2 gcc version is 4.8.2 regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 3/3] mm, oom: do not panic for oom kills triggered from sysrq
> Sysrq+f is used to kill a process either for debug or when the VM is
> otherwise unresponsive.
>
> It is not intended to trigger a panic when no process may be killed.
>
> Avoid panicking the system for sysrq+f when no processes are killed.
>
> Suggested-by: Michal Hocko
> Signed-off-by: David Rientjes
> ---
> v2: no change
> v3: fix title per Hillf
>
> Documentation/sysrq.txt | 3 ++-
> mm/oom_kill.c | 7 +--
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt
> --- a/Documentation/sysrq.txt
> +++ b/Documentation/sysrq.txt
> @@ -75,7 +75,8 @@ On all - write a character to /proc/sysrq-trigger. e.g.:
>
> 'e' - Send a SIGTERM to all processes, except for init.
>
> -'f' - Will call oom_kill to kill a memory hog process.
> +'f' - Will call the oom killer to kill a memory hog process, but do not
> + panic if nothing can be killed.
>
> 'g' - Used by kgdb (kernel debugger)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -607,6 +607,9 @@ void check_panic_on_oom(struct oom_control *oc, enum
> oom_constraint constraint,
> if (constraint != CONSTRAINT_NONE)
> return;
> }
> + /* Do not panic for oom kills triggered by sysrq */
> + if (oc->order == -1)
> + return;
> dump_header(oc, NULL, memcg);
> panic("Out of memory: %s panic_on_oom is enabled\n",
> sysctl_panic_on_oom == 2 ? "compulsory" : "system-wide");
> @@ -686,11 +689,11 @@ bool out_of_memory(struct oom_control *oc)
>
> p = select_bad_process(oc, , totalpages);
> /* Found nothing?!?! Either we hang forever, or we panic. */
> - if (!p) {
> + if (!p && oc->order != -1) {
> dump_header(oc, NULL, NULL);
> panic("Out of memory and no killable processes...\n");
> }
Given sysctl_panic_on_oom checked, AFAICU there seems
no chance for panic, no matter -1 or not.
> - if (p != (void *)-1UL) {
> + if (p && p != (void *)-1UL) {
> oom_kill_process(oc, p, points, totalpages, NULL,
>"Out of memory");
> killed = 1;
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 9
Hi all, Changes since 20150708: The drm-intel tree gained conflicts against Linus' and the drm-intel-fixes trees. The tip tree lost its build failure. Non-merge commits (relative to Linus' tree): 1275 1128 files changed, 68969 insertions(+), 20637 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 223 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (45820c294fe1 Fix broken audit tests for exec arg len) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (11b8b25ce4f8 ARM: fix lockdep unannotated irqs-off warning) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (9958084a5275 powerpc: Update MAINTAINERS to point at shared tree) Merging powerpc-merge-mpe/fixes (a8956a7b7232 powerpc/powernv: Fix opal-elog interrupt handler) Merging powerpc-merge-benh/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (142b942a75cb rhashtable: fix for resize events during table walk) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (e828b23734bf ALSA: hda - add codec ID for Broxton display audio codec) Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during alignment reordering) Merging wireless-drivers/master (38fe44e61a89 Merge tag 'iwlwifi-for-kalle-2015-05-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (d770e558e219 Linux 4.2-rc1) Merging tty.current/tty-linus (d770e558e219 Linux 4.2-rc1) Merging usb.current/usb-linus (d4669bb1427c Merge tag 'fixes-for-v4.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (b2e2c94b878b usb: gadget: f_midi: fix error recovery path) Merging usb-serial-fixes/usb-linus (f98a7aa81eee USB: cp210x: add ID for Aruba Networks controllers) Merging staging.current/staging-linus (cbe4f4434ded staging:lustre: remove irq.h from socklnd.h) Merging char-misc.current/char-misc-linus (d770e558e219 Linux 4.2-rc1) Merging input-current/for-linus (539c4b88146c Input: elan_i2c - change the hover event from MT to ST) Merging crypto-current/master (030f4e968741 crypto: nx - Fix reentrancy bugs) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (758556bdc1c8 module: Fix load_module() error path) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging drm-intel-fixes/for-linux-next-fixes (dec4f799d0a4 drm/i915: Use crtc_state->active in primary check_
Re: [PATCH] Revert: audit: Fix check of return value of strnlen_user()
On Wed, 8 Jul 2015 12:29:43 -0400 Steven Rostedt wrote: > I tested the following patch. Feel free to author it yourself and just > add my reported/tested-by tags, or give it to me. Either way, I don't > care. I just want it fixed so that it doesn't make my own tests fail. > OK, you posted your version of the patch, and you just had to include the quote from me that happened to have a grammar mistake: As reported by Steven Rostedt: "Yes, strnlen_user() returns 0 on fault, but if you look at what len is set to, than you would notice that on fault len would be -1" Ug, my "than" stupidity is forever carved in the git stone logs. At least you didn't stick a "(sic)" in there. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Kernel splat when taking CPUs offline
On 09-07-15, 02:13, Rafael J. Wysocki wrote: > So the cpufreq driver's ->get() callback returns 0 for the given CPU and > that's what triggers the WARN_ON(). And it most likely returns 0, because > its internal data structure for that CPU is not present. > > I *guess* that before the above commit policy was NULL in > cpufreq_update_policy() > and we didn't get to the point where ->get() was called. I am not sure if that behavior should have changed at all.. Earlier we were clearing per-cpu cpufreq_cpu_data for offline CPUs and so policy would have been NULL for offline CPUs. Now that per-cpu variable isn't cleared, but cpufreq_cpu_get() does check if the CPU is part of policy->cpus or not, i.e. if it is offline. And so policy should still be NULL for offline CPUs. I think it might be related to what I chased down yesterday: http://marc.info/?l=linux-kernel=143633485824975=2 @Steven: Can you please give this a try ? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] soc: qcom: Add device tree binding for SMEM
On Wed, Jul 08, 2015 at 04:56:34PM -0700, Stephen Boyd wrote:
> On 06/26/2015 02:50 PM, bj...@kryo.se wrote:
> > += EXAMPLE
> > +The following example shows the SMEM setup for MSM8974, with a main SMEM
> > region
> > +at 0xfa0 and an auxiliary region at 0xfc428000:
> > +
> > + reserved-memory {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + smem_region: smem@fa0 {
> > + reg = <0xfa0 0x20>;
> > + no-map;
> > + };
> > + };
> > +
> > + smem@fa0 {
>
> This should be smem@fc428000 matching the first reg property. It's weird
> though, because if smem is using a secondary region it will be under the
> SoC node and have a reg property. Otherwise it would be directly under
> the root node and only have a memory-region. It would be nice if we
> could somehow move the rpm message ram (0xfc428000) into the
> reserved-memory node so that we could use memory-region for both regions.
The memory-region is just used to describe 'real' memory. The RPM message is IO
memory and part of the SOC. Thats my take at least.
>
> > + compatible = "qcom,smem";
> > +
> > + memory-region = <_region>;
> > + reg = <0xfc428000 0x4000>;
> > +
> > + hwlocks = <_mutex 3>;
> > + };
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANN] Linux Security Summit 2015 - Schedule Published
The schedule for the 2015 Linux Security Summit in Seattle is now published. The refereed talks are: * CC3: An Identity Attested Linux Security Supervisor Architecture - Greg Wettstein, IDfusion * SELinux in Android Lollipop and Android M - Stephen Smalley, NSA * Linux Incident Response - Mike Scutt and Tim Stiller, Rapid7 * Assembling Secure OS Images - Elena Reshetova, Intel * Linux and Mobile Device Encryption - Paul Lawrence and Mike Halcrow, Google * Security Framework for Constraining Application Privileges - Lukasz Wojciechowski, Samsung * IMA/EVM: Real Applications for Embedded Networking Systems - Petko Manolov, Konsulko Group, and Mark Baushke, Juniper Networks * Ioctl Command Whitelisting in SELinux - Jeffrey Vander Stoep, Google * IMA/EVM on Android Device - Dmitry Kasatkin, Huawei Technologies There will be several discussion sessions: * Core Infrastructure Initiative - Emily Ratliff, Linux Foundation * Linux Security Module Stacking Next Steps - Casey Schaufler, Intel * Discussion: Rethinking Audit - Paul Moore, Red Hat Also featured are brief updates on kernel security subsystems, including SELinux, Smack, AppArmor, Integrity, Capabilities, and Seccomp. The keynote speaker will be Konstantin Ryabitsev, sysadmin for kernel.org. Check out his Reddit AMA! [1] See the schedule for full details, and any updates: http://kernsec.org/wiki/index.php/Linux_Security_Summit_2015#Schedule This year’s summit will take place on the 20th and 21st of August, in Seattle, USA, as a LinuxCon co-located event. As such, all Linux Security Summit attendees must be registered for LinuxCon. Attendees are welcome to attend the Weds 19th August reception. Hope to see you there! - James (on behalf of the program committee). [1] http://www.reddit.com/r/linux/comments/2xqn12/im_part_of_the_sysadmin_team_behind_kernelorg_and/ -- James Morris
Re: [BUG] Kernel splat when taking CPUs offline
On Thu, 09 Jul 2015 02:13:45 +0200 "Rafael J. Wysocki" wrote: > > Initializing CPU#1 > > [ cut here ] > > WARNING: CPU: 0 PID: 1609 at > > /home/rostedt/work/git/linux-trace.git/drivers/cpufreq/cpufreq.c:2350 > > cpufreq_update_policy+0xc8/0x139() > > So the cpufreq driver's ->get() callback returns 0 for the given CPU and > that's what triggers the WARN_ON(). And it most likely returns 0, because > its internal data structure for that CPU is not present. > > I *guess* that before the above commit policy was NULL in > cpufreq_update_policy() > and we didn't get to the point where ->get() was called. Just some more info. That ->get() is get_cur_freq_on_cpu() (I added a printk to find out what that was). Also, adding more printks() (patch of printk's added below) I got this: # trace-cmd start -p mmiotrace # offlines all but one CPU # trace-cmd start -p nop# onlines the CPUs # trace-cmd start -p mmiotrace # again offlines all but one CPU # trace-cmd start -p nop# again onlines the CPUs produces: in mmio_trace_init mmiotrace: Disabling non-boot CPUs... smpboot: CPU 1 is now offline exit free f252c180 (1) mmiotrace: CPU1 is down. Broke affinity for irq 28 smpboot: CPU 2 is now offline exit free f252c260 (2) mmiotrace: CPU2 is down. Broke affinity for irq 4 Broke affinity for irq 25 Broke affinity for irq 26 Broke affinity for irq 27 Broke affinity for irq 28 smpboot: CPU 3 is now offline exit free f252c280 (3) mmiotrace: CPU3 is down. mmiotrace: enabled. in mmio_trace_start in mmio_trace_reset mmiotrace: Re-enabling CPUs... x86: Booting SMP configuration: smpboot: Booting Node 0 Processor 1 APIC 0x2 Initializing CPU#1 INIT data = f05a6b40 (1) data=f05a6b40 data-acpi_data=f3539634 data-freq_table_data=f2073b00 exit free f05a6b40 (1) mmiotrace: enabled CPU1. smpboot: Booting Node 0 Processor 2 APIC 0x1 Initializing CPU#2 INIT data = efe567a0 (2) data=efe567a0 data-acpi_data=f368b634 data-freq_table_data=ef849100 exit free efe567a0 (2) mmiotrace: enabled CPU2. smpboot: Booting Node 0 Processor 3 APIC 0x3 Initializing CPU#3 INIT data = efe56760 (3) data=efe56760 data-acpi_data=f37dd634 data-freq_table_data=ef840600 exit free efe56760 (3) mmiotrace: enabled CPU3. mmiotrace: disabled. in mmio_trace_init mmiotrace: Disabling non-boot CPUs... cpufreq: __cpufreq_remove_dev_prepare: Failed to stop governor smpboot: CPU 1 is now offline mmiotrace: CPU1 is down. cpufreq: __cpufreq_remove_dev_prepare: Failed to stop governor Broke affinity for irq 28 smpboot: CPU 2 is now offline mmiotrace: CPU2 is down. cpufreq: __cpufreq_remove_dev_prepare: Failed to stop governor Broke affinity for irq 28 smpboot: CPU 3 is now offline mmiotrace: CPU3 is down. mmiotrace: enabled. in mmio_trace_start in mmio_trace_reset mmiotrace: Re-enabling CPUs... x86: Booting SMP configuration: smpboot: Booting Node 0 Processor 1 APIC 0x2 Initializing CPU#1 get=get_cur_freq_on_cpu+0x0/0xe9 data= (null) [ cut here ] WARNING: CPU: 0 PID: 1994 at /home/rostedt/work/git/linux-trace.git/drivers/cpufreq/cpufreq.c:2351 cpufreq_update_policy+0xe8/0x159() Modules linked in: ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 microcode r8169 ppdev parport_pc parport CPU: 0 PID: 1994 Comm: trace-cmd Not tainted 4.2.0-rc1-test+ #30 Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014 efa11b54 c0cd0386 c10d4414 efa11b84 c0440fbe c101046c 07ca c10d4414 092f c0a6db4a c0a6db4a f146cc00 efa11d60 efa11b94 c0440ff7 0009 efa11d6c c0a6db4a c10d4e15 Call Trace: [] dump_stack+0x41/0x52 [] warn_slowpath_common+0x9d/0xb4 [] ? cpufreq_update_policy+0xe8/0x159 [] ? cpufreq_update_policy+0xe8/0x159 [] warn_slowpath_null+0x22/0x24 [] cpufreq_update_policy+0xe8/0x159 [] ? extract_freq+0xa1/0xa1 [] ? cpufreq_update_policy+0x159/0x159 [] ? cpufreq_update_policy+0x3b/0x159 [] ? cpufreq_freq_transition_begin+0x97/0xd9 [] ? __wake_up+0x1a/0x47 [] acpi_processor_ppc_has_changed+0x54/0x5d [] acpi_cpu_soft_notify+0xb0/0xf1 [] ? compute_batch_value+0xd/0x22 [] ? percpu_counter_hotcpu_callback+0x11/0x80 [] notifier_call_chain+0x68/0x91 [] __raw_notifier_call_chain+0x1e/0x23 [] __cpu_notify+0x24/0x39 [] _cpu_up+0xef/0x105 [] cpu_up+0x4e/0x5f [] ? find_next_bit+0x1a/0x20 [] disable_mmiotrace+0xd4/0x13e [] mmio_trace_reset+0x36/0x5e [] tracing_set_tracer+0xb1/0x155 [] ? _copy_from_user+0x42/0x57 [] tracing_set_trace_write+0x6a/0x80 [] ? handle_mm_fault+0x75b/0xc42 [] ? file_start_write+0x27/0x29 [] ? tracing_set_tracer+0x155/0x155 [] __vfs_write+0x24/0x9b [] ? file_start_write+0x27/0x29 [] ? rw_verify_area+0xce/0xef [] ? __do_page_fault+0x2be/0x3be [] vfs_write+0x7a/0xc4 [] SyS_write+0x54/0x7f [] sysenter_do_call+0x12/0x12 ---[ end trace 47cc28ca9538eb2d ]--- mmiotrace: enabled CPU1. smpboot: Booting Node 0 Processor 2 APIC 0x1 Initializing CPU#2
[PATCH v2] arm64: dts: mt8173: Add afe device node
This adds afe (audio front end) device node to the MT8173 dtsi file.
Signed-off-by: Koro Chen
---
This patch is based on Matthias's tree:
https://github.com/mbgg/linux-mediatek
branch: v4.2-next/arm64
Changes since v1:
- change node name to afe: audio-controller@1122
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 0696f8f..ce9255a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include "mt8173-pinfunc.h"
@@ -393,6 +394,37 @@
#size-cells = <0>;
status = "disabled";
};
+
+ afe: audio-controller@1122 {
+ compatible = "mediatek,mt8173-afe-pcm";
+ reg = <0 0x1122 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8173_POWER_DOMAIN_AUDIO>;
+ clocks = < CLK_INFRA_AUDIO>,
+< CLK_TOP_AUDIO_SEL>,
+< CLK_TOP_AUD_INTBUS_SEL>,
+< CLK_TOP_APLL1_DIV0>,
+< CLK_TOP_APLL2_DIV0>,
+< CLK_TOP_I2S0_M_SEL>,
+< CLK_TOP_I2S1_M_SEL>,
+< CLK_TOP_I2S2_M_SEL>,
+< CLK_TOP_I2S3_M_SEL>,
+< CLK_TOP_I2S3_B_SEL>;
+ clock-names = "infra_sys_audio_clk",
+ "top_pdn_audio",
+ "top_pdn_aud_intbus",
+ "bck0",
+ "bck1",
+ "i2s0_m",
+ "i2s1_m",
+ "i2s2_m",
+ "i2s3_m",
+ "i2s3_b";
+ assigned-clocks = < CLK_TOP_AUD_1_SEL>,
+ < CLK_TOP_AUD_2_SEL>;
+ assigned-clock-parents = < CLK_TOP_APLL1>,
+< CLK_TOP_APLL2>;
+ };
};
};
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail
Hi, Yinghai
This patch may introduce some problem.
On my P8 machine, after applying this patch, I see following error:
[0.589948] pnv_ioda_setup_pe_seg: trigger IO SEG 0
[0.589992] pnv_ioda_setup_pe_seg: res[io 0x1000-0x3fff] 100
The last 0x100 is the res->flags, which indicates the UNSET and DISABLED bit
is not set.
On P8, we don't have IO window, which means the IO BAR will not be assigned.
And those io_segmap is not allocated. The following trace is printed since the
io_segmap is accessed, while it is NULL.
[0.590050] Unable to handle kernel paging request for data at address
0x
[0.590115] Faulting instruction address: 0xc00759b8
[0.590172] Oops: Kernel access of bad area, sig: 11 [#1]
[0.590216] SMP NR_CPUS=1024 NUMA PowerNV
[0.590262] Modules linked in:
[0.590309] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc1eeh_refactor+
#244
[0.590375] task: c02ff438 ti: c02ff6084000 task.ti:
c02ff6084000
[0.590440] NIP: c00759b8 LR: c0075960 CTR: 3004a1bc
[0.590506] REGS: c02ff6087620 TRAP: 0300 Not tainted
(4.2.0-rc1eeh_refactor+)
[0.590572] MSR: 90009032 CR: 2228 XER:
2000
[0.590727] CFAR: c0008468 DAR: DSISR: 4200
SOFTE: 1
GPR00: c0075960 c02ff60878a0 c1534f00 0031
GPR04: 0001 0003
GPR08: 0006 03f2
GPR12: 2222 cfda c0b82c88
GPR16: 3fff 1000 c0b82cc8
GPR20: c0b82c50 c0b82c70 c1452148 c02fffb2d900
GPR24: c0923c40 c02fffb4c810 c02fffb4c300 00102000
GPR28: c02fffb40720 c01ff42aa500 c02fffb4c580
[0.591603] NIP [c00759b8] .pnv_pci_ioda_fixup+0xaa8/0xb20
[0.591658] LR [c0075960] .pnv_pci_ioda_fixup+0xa50/0xb20
[0.591713] Call Trace:
[0.591736] [c02ff60878a0] [c0075960]
.pnv_pci_ioda_fixup+0xa50/0xb20 (unreliable)
[0.591824] [c02ff6087a40] [c0caf0a8]
.pcibios_resource_survey+0x3a8/0x404
[0.591901] [c02ff6087b60] [c0cae7f0] .pcibios_init+0xa0/0xd4
[0.591968] [c02ff6087bf0] [c000ad30]
.do_one_initcall+0x110/0x280
[0.592045] [c02ff6087ce0] [c0ca45c4]
.kernel_init_freeable+0x274/0x35c
[0.592122] [c02ff6087db0] [c000b5e4] .kernel_init+0x24/0x140
[0.592188] [c02ff6087e30] [c00094e8]
.ret_from_kernel_thread+0x58/0x70
[0.592265] Instruction dump:
[0.592298] 7d3107b4 7f084840 7e525214 7fb09040 4099f7b8 419cf7b4 e93e0180
811c0024
[0.592408] 7a2a1764 38a3 7a270420 38c0 <7d09512e> a09c0026 e87e0018
4bff1c59
[0.592524] ---[ end trace 856c9d223a60380c ]---
[0.593584]
[2.593742] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[2.593742]
[2.605223] Rebooting in 10 seconds..
On Mon, Jul 06, 2015 at 04:39:26PM -0700, Yinghai Lu wrote:
>make flags take IORESOURCE_UNSET | IORESOURCE_DISABLED instead.
>
>Signed-off-by: Yinghai Lu
>---
> drivers/pci/setup-bus.c | 52 +
> drivers/pci/setup-res.c | 11 +++
> 2 files changed, 38 insertions(+), 25 deletions(-)
>
>diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>index 9b27e15..e82655b 100644
>--- a/drivers/pci/setup-bus.c
>+++ b/drivers/pci/setup-bus.c
>@@ -255,7 +255,8 @@ static void pdev_check_resources(struct pci_dev *dev,
> if (r->flags & IORESOURCE_PCI_FIXED)
> continue;
>
>- if (!(r->flags) || r->parent)
>+ if (!r->flags || r->parent ||
>+ (r->flags & IORESOURCE_DISABLED))
> continue;
>
> r_align = __pci_resource_alignment(dev, r, realloc_head);
>@@ -296,13 +297,6 @@ static void __dev_check_resources(struct pci_dev *dev,
> pdev_check_resources(dev, realloc_head, head);
> }
>
>-static inline void reset_resource(struct resource *res)
>-{
>- res->start = 0;
>- res->end = 0;
>- res->flags = 0;
>-}
>-
> static void __sort_resources(struct list_head *head)
> {
> struct pci_dev_resource *res1, *tmp_res, *res2;
>@@ -387,7 +381,7 @@ static void reassign_resources_sorted(struct list_head
>*realloc_head,
> list_for_each_entry_safe(add_res, tmp, realloc_head, list) {
> res = add_res->res;
> /* skip resource that has been reset */
>- if (!res->flags)
>+ if (res->flags & IORESOURCE_DISABLED)
> goto out;
>
> /* skip this resource if not found in head list */
>@@ -405,7 +399,7 @@ static void reassign_resources_sorted(struct list_head
>*realloc_head,
>
[PATCH V4 3/7] i2c: qup: Add V2 tags support
QUP from version 2.1.1 onwards, supports a new format of
i2c command tags. Tag codes instructs the controller to
perform a operation like read/write. This new tagging version
supports bam dma and transfers of more than 256 bytes without 'stop'
in between. Adding the support for the same.
For each block a data_write/read tag and data_len tag is added to
the output fifo. For the final block of data write_stop/read_stop
tag is used.
Signed-off-by: Andy Gross
Signed-off-by: Sricharan R
---
drivers/i2c/busses/i2c-qup.c | 330 ++-
1 file changed, 323 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 131dc28..a4e20d9 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -43,6 +43,8 @@
#define QUP_I2C_CLK_CTL0x400
#define QUP_I2C_STATUS 0x404
+#define QUP_I2C_MASTER_GEN 0x408
+
/* QUP States and reset values */
#define QUP_RESET_STATE0
#define QUP_RUN_STATE 1
@@ -69,6 +71,8 @@
#define QUP_CLOCK_AUTO_GATEBIT(13)
#define I2C_MINI_CORE (2 << 8)
#define I2C_N_VAL 15
+#define I2C_N_VAL_V2 7
+
/* Most significant word offset in FIFO port */
#define QUP_MSW_SHIFT (I2C_N_VAL + 1)
@@ -79,6 +83,7 @@
#define QUP_PACK_ENBIT(15)
#define QUP_REPACK_EN (QUP_UNPACK_EN | QUP_PACK_EN)
+#define QUP_V2_TAGS_EN 1
#define QUP_OUTPUT_BLOCK_SIZE(x)(((x) >> 0) & 0x03)
#define QUP_OUTPUT_FIFO_SIZE(x)(((x) >> 2) & 0x07)
@@ -91,6 +96,13 @@
#define QUP_TAG_STOP (3 << 8)
#define QUP_TAG_REC(4 << 8)
+/* QUP v2 tags */
+#define QUP_TAG_V2_START 0x81
+#define QUP_TAG_V2_DATAWR 0x82
+#define QUP_TAG_V2_DATAWR_STOP 0x83
+#define QUP_TAG_V2_DATARD 0x85
+#define QUP_TAG_V2_DATARD_STOP 0x87
+
/* Status, Error flags */
#define I2C_STATUS_WR_BUFFER_FULL BIT(0)
#define I2C_STATUS_BUS_ACTIVE BIT(8)
@@ -102,6 +114,15 @@
#define RESET_BIT 0x0
#define ONE_BYTE 0x1
+struct qup_i2c_block {
+ int count;
+ int pos;
+ int tx_tag_len;
+ int rx_tag_len;
+ int data_len;
+ u8 tags[6];
+};
+
struct qup_i2c_dev {
struct device *dev;
void __iomem*base;
@@ -117,6 +138,7 @@ struct qup_i2c_dev {
int in_blk_sz;
unsigned long one_byte_t;
+ struct qup_i2c_blockblk;
struct i2c_msg *msg;
/* Current posion in user message buffer */
@@ -126,6 +148,14 @@ struct qup_i2c_dev {
/* QUP core errors */
u32 qup_err;
+ int use_v2_tags;
+
+ int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
+struct i2c_msg *msg);
+
+ int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
+ struct i2c_msg *msg);
+
struct completion xfer;
};
@@ -266,7 +296,7 @@ static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int
op, bool val,
static void qup_i2c_set_write_mode(struct qup_i2c_dev *qup, struct i2c_msg
*msg)
{
/* Number of entries to shift out, including the start */
- int total = msg->len + 1;
+ int total = msg->len + qup->blk.tx_tag_len;
if (total < qup->out_fifo_sz) {
/* FIFO mode */
@@ -324,6 +354,134 @@ static int qup_i2c_issue_write(struct qup_i2c_dev *qup,
struct i2c_msg *msg)
return ret;
}
+static void qup_i2c_get_blk_data(struct qup_i2c_dev *qup,
+struct i2c_msg *msg)
+{
+ memset(>blk, 0, sizeof(qup->blk));
+
+ if (!qup->use_v2_tags) {
+ if (!(msg->flags & I2C_M_RD))
+ qup->blk.tx_tag_len = 1;
+ return;
+ }
+
+ qup->blk.data_len = msg->len;
+ qup->blk.count = (msg->len + QUP_READ_LIMIT - 1) / QUP_READ_LIMIT;
+
+ /* 4 bytes for first block and 2 writes for rest */
+ qup->blk.tx_tag_len = 4 + (qup->blk.count - 1) * 2;
+
+ /* There are 2 tag bytes that are read in to fifo for every block */
+ if (msg->flags & I2C_M_RD)
+ qup->blk.rx_tag_len = qup->blk.count * 2;
+}
+
+static int qup_i2c_send_data(struct qup_i2c_dev *qup, int tlen, u8 *tbuf,
+int dlen, u8 *dbuf)
+{
+ u32 val = 0, idx = 0, pos = 0, i = 0, t;
+ int len = tlen + dlen;
+ u8 *buf = tbuf;
+ int ret = 0;
+
+ while (len > 0) {
+ ret = qup_i2c_wait_ready(qup, QUP_OUT_FULL,
+RESET_BIT, 4 * ONE_BYTE);
+ if (ret) {
+ dev_err(qup->dev, "timeout for fifo out full");
+ return ret;
+ }
+
+ t
[PATCH V4 5/7] i2c: qup: Add bam dma capabilities
QUP cores can be attached to a BAM module, which acts as a dma engine for the
QUP core. When DMA with BAM is enabled, the BAM consumer pipe transmitted data
is written to the output FIFO and the BAM producer pipe received data is read
from the input FIFO.
With BAM capabilities, qup-i2c core can transfer more than 256 bytes, without a
'stop' which is not possible otherwise.
Signed-off-by: Sricharan R
---
drivers/i2c/busses/i2c-qup.c | 431 +--
1 file changed, 415 insertions(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index c0757d9..810b021 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -24,6 +24,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
/* QUP Registers */
#define QUP_CONFIG 0x000
@@ -33,6 +38,7 @@
#define QUP_OPERATIONAL0x018
#define QUP_ERROR_FLAGS0x01c
#define QUP_ERROR_FLAGS_EN 0x020
+#define QUP_OPERATIONAL_MASK 0x028
#define QUP_HW_VERSION 0x030
#define QUP_MX_OUTPUT_CNT 0x100
#define QUP_OUT_FIFO_BASE 0x110
@@ -53,6 +59,7 @@
#define QUP_STATE_VALIDBIT(2)
#define QUP_I2C_MAST_GEN BIT(4)
+#define QUP_I2C_FLUSH BIT(6)
#define QUP_OPERATIONAL_RESET 0x000ff0
#define QUP_I2C_STATUS_RESET 0xfc
@@ -78,7 +85,10 @@
/* Packing/Unpacking words in FIFOs, and IO modes */
#define QUP_OUTPUT_BLK_MODE(1 << 10)
+#define QUP_OUTPUT_BAM_MODE(3 << 10)
#define QUP_INPUT_BLK_MODE (1 << 12)
+#define QUP_INPUT_BAM_MODE (3 << 12)
+#define QUP_BAM_MODE (QUP_OUTPUT_BAM_MODE | QUP_INPUT_BAM_MODE)
#define QUP_UNPACK_EN BIT(14)
#define QUP_PACK_ENBIT(15)
@@ -95,6 +105,8 @@
#define QUP_TAG_DATA (2 << 8)
#define QUP_TAG_STOP (3 << 8)
#define QUP_TAG_REC(4 << 8)
+#define QUP_BAM_INPUT_EOT 0x93
+#define QUP_BAM_FLUSH_STOP 0x96
/* QUP v2 tags */
#define QUP_TAG_V2_START 0x81
@@ -115,6 +127,12 @@
#define ONE_BYTE 0x1
#define QUP_I2C_MX_CONFIG_DURING_RUN BIT(31)
+#define MX_TX_RX_LEN SZ_64K
+#define MX_BLOCKS (MX_TX_RX_LEN / QUP_READ_LIMIT)
+
+/* Max timeout in ms for 32k bytes */
+#define TOUT_MAX 300
+
struct qup_i2c_block {
int count;
int pos;
@@ -125,6 +143,23 @@ struct qup_i2c_block {
int config_run;
};
+struct qup_i2c_tag {
+ u8 *start;
+ dma_addr_t addr;
+};
+
+struct qup_i2c_bam_rx {
+ struct qup_i2c_tag scratch_tag;
+ struct dma_chan *dma_rx;
+ struct scatterlist *sg_rx;
+};
+
+struct qup_i2c_bam_tx {
+ struct qup_i2c_tag footer_tag;
+ struct dma_chan *dma_tx;
+ struct scatterlist *sg_tx;
+};
+
struct qup_i2c_dev {
struct device *dev;
void __iomem*base;
@@ -154,14 +189,20 @@ struct qup_i2c_dev {
int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
struct i2c_msg *msg);
+ int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
+ struct i2c_msg *msg);
+
/* Current i2c_msg in i2c_msgs */
int cmsg;
/* total num of i2c_msgs */
int num;
- int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
- struct i2c_msg *msg);
-
+ /* dma parameters */
+ boolis_dma;
+ struct dma_pool *dpool;
+ struct qup_i2c_tag start_tag;
+ struct qup_i2c_bam_rx brx;
+ struct qup_i2c_bam_tx btx;
struct completion xfer;
};
@@ -238,6 +279,14 @@ static int qup_i2c_poll_state(struct qup_i2c_dev *qup, u32
req_state)
return qup_i2c_poll_state_mask(qup, req_state, QUP_STATE_MASK);
}
+static void qup_i2c_flush(struct qup_i2c_dev *qup)
+{
+ u32 val = readl(qup->base + QUP_STATE);
+
+ val |= QUP_I2C_FLUSH;
+ writel(val, qup->base + QUP_STATE);
+}
+
static int qup_i2c_poll_state_valid(struct qup_i2c_dev *qup)
{
return qup_i2c_poll_state_mask(qup, 0, 0);
@@ -437,12 +486,15 @@ static int qup_i2c_get_data_len(struct qup_i2c_dev *qup)
}
static int qup_i2c_get_tags(u8 *tags, struct qup_i2c_dev *qup,
- struct i2c_msg *msg)
+ struct i2c_msg *msg, int is_dma)
{
u16 addr = (msg->addr << 1) | ((msg->flags & I2C_M_RD) == I2C_M_RD);
int len = 0;
int data_len;
+ int last = (qup->blk.pos == (qup->blk.count - 1)) &&
+ (qup->cmsg == (qup->num - 1));
+
if (qup->blk.pos == 0) {
tags[len++] = QUP_TAG_V2_START;
tags[len++] = addr & 0xff;
@@ -452,8 +504,7
Re: [PATCH v2] power_supply: rt9455_charger: Properly notify userspace about charging events
Hi, On Tue, Jul 07, 2015 at 03:25:53PM +0300, Anda-Maria Nicolae wrote: > Charging events this patch refers to are: > - charger is connected to/disconnected from the power source > - battery is reconnected to the charger, after it was absent. > > When the charger is connected to/disconnected from the power source, CHRVPI > interrupt occurs and PWR_RDY bit is either set or cleared. PWR_RDY bit is > updated after 1-2 seconds CHRVPI interrupt has occurred. > power_supply_changed() should be called after PWR_RDY bit is updated. > /sys/class/power_supply/rt9455-charger/online file displays the value of > PWR_RDY bit. > This way, if the userspace is notified that a charging event has occurred > and the userspace reads /sys/class/power_supply/rt9455-charger/online file, > this file is properly updated when the userspace reads it. > This is the reason why power_supply_changed() is called in > rt9455_pwr_rdy_work_callback(), instead of being called in interrupt > handler. > > Since no interrupt is triggered when the battery is reconnected to the > charger, the userspace is never notified that the battery is reconnected. > This is why power_supply_changed() is called in > rt9455_max_charging_time_work_callback(), so that the userspace is notified > that the battery is reconnected. > > Signed-off-by: Anda-Maria Nicolae Thanks, queued with Kzrysztof's Reviewed-By. -- Sebastian signature.asc Description: Digital signature
[PATCH V4 7/7] dts: msm8974: Add dma channels for blsp2_i2c1 node
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index f138202..17dcda3 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -284,6 +284,8 @@
clock-names = "core", "iface";
#address-cells = <1>;
#size-cells = <0>;
+ dmas = <_dma 20>, <_dma 21>;
+ dma-names = "tx", "rx";
};
spmi_bus: spmi@fc4cf000 {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 4/7] i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit
The definition of i2c_msg says that
"If this is the last message in a group, it is followed by a STOP.
Otherwise it is followed by the next @i2c_msg transaction segment,
beginning with a (repeated) START"
So the expectation is that there is no 'STOP' bit inbetween individual
i2c_msg segments with repeated 'START'. The QUP i2c hardware has no way
to inform that there should not be a 'STOP' at the end of transaction.
The only way to implement this is to coalesce all the i2c_msg in i2c_msgs
in to one transaction and transfer them. Adding the support for the same.
This is required for some clients like touchscreen which keeps
incrementing counts across individual transfers and 'STOP' bit inbetween
resets the counter, which is not required.
This patch adds the support in non-dma mode.
Signed-off-by: Sricharan R
---
drivers/i2c/busses/i2c-qup.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index a4e20d9..c0757d9 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -113,6 +113,7 @@
#define SET_BIT0x1
#define RESET_BIT 0x0
#define ONE_BYTE 0x1
+#define QUP_I2C_MX_CONFIG_DURING_RUN BIT(31)
struct qup_i2c_block {
int count;
@@ -121,6 +122,7 @@ struct qup_i2c_block {
int rx_tag_len;
int data_len;
u8 tags[6];
+ int config_run;
};
struct qup_i2c_dev {
@@ -152,6 +154,10 @@ struct qup_i2c_dev {
int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
struct i2c_msg *msg);
+ /* Current i2c_msg in i2c_msgs */
+ int cmsg;
+ /* total num of i2c_msgs */
+ int num;
int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
struct i2c_msg *msg);
@@ -278,7 +284,8 @@ static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int
op, bool val,
status = readl(qup->base + QUP_I2C_STATUS);
if (((opflags & op) >> shift) == val) {
- if (op == QUP_OUT_NOT_EMPTY) {
+ if ((op == QUP_OUT_NOT_EMPTY) &&
+ (qup->cmsg == (qup->num - 1))) {
if (!(status & I2C_STATUS_BUS_ACTIVE))
return 0;
} else {
@@ -301,12 +308,14 @@ static void qup_i2c_set_write_mode(struct qup_i2c_dev
*qup, struct i2c_msg *msg)
if (total < qup->out_fifo_sz) {
/* FIFO mode */
writel(QUP_REPACK_EN, qup->base + QUP_IO_MODE);
- writel(total, qup->base + QUP_MX_WRITE_CNT);
+ writel(total | qup->blk.config_run,
+ qup->base + QUP_MX_WRITE_CNT);
} else {
/* BLOCK mode (transfer data on chunks) */
writel(QUP_OUTPUT_BLK_MODE | QUP_REPACK_EN,
qup->base + QUP_IO_MODE);
- writel(total, qup->base + QUP_MX_OUTPUT_CNT);
+ writel(total | qup->blk.config_run,
+ qup->base + QUP_MX_OUTPUT_CNT);
}
}
@@ -374,6 +383,9 @@ static void qup_i2c_get_blk_data(struct qup_i2c_dev *qup,
/* There are 2 tag bytes that are read in to fifo for every block */
if (msg->flags & I2C_M_RD)
qup->blk.rx_tag_len = qup->blk.count * 2;
+
+ if (qup->cmsg)
+ qup->blk.config_run = QUP_I2C_MX_CONFIG_DURING_RUN;
}
static int qup_i2c_send_data(struct qup_i2c_dev *qup, int tlen, u8 *tbuf,
@@ -440,7 +452,8 @@ static int qup_i2c_get_tags(u8 *tags, struct qup_i2c_dev
*qup,
}
/* Send _STOP commands for the last block */
- if (qup->blk.pos == (qup->blk.count - 1)) {
+ if (qup->blk.pos == (qup->blk.count - 1)
+ && (qup->cmsg == (qup->num - 1))) {
if (msg->flags & I2C_M_RD)
tags[len++] = QUP_TAG_V2_DATARD_STOP;
else
@@ -571,7 +584,6 @@ static int qup_i2c_write(struct qup_i2c_dev *qup, struct
i2c_msg *msg)
goto err;
ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, RESET_BIT, ONE_BYTE);
-
err:
disable_irq(qup->irq);
qup->msg = NULL;
@@ -584,18 +596,19 @@ static void qup_i2c_set_read_mode(struct qup_i2c_dev
*qup, int len)
int tx_len = qup->blk.tx_tag_len;
len += qup->blk.rx_tag_len;
+ tx_len |= qup->blk.config_run;
if (len < qup->in_fifo_sz) {
/* FIFO mode */
writel(QUP_REPACK_EN, qup->base + QUP_IO_MODE);
- writel(len, qup->base + QUP_MX_READ_CNT);
writel(tx_len, qup->base + QUP_MX_WRITE_CNT);
+ writel(len | qup->blk.config_run, qup->base + QUP_MX_READ_CNT);
} else {
/* BLOCK
[PATCH V4 1/7] i2c: qup: Change qup_wait_writeready function to use for all timeouts
qup_wait_writeready waits only on a output fifo empty event.
Change the same function to accept the event and data length
to wait as parameters. This way the same function can be used for
timeouts in otherplaces as well.
Signed-off-by: Sricharan R
---
drivers/i2c/busses/i2c-qup.c | 67 +++-
1 file changed, 48 insertions(+), 19 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index fdcbdab..81ed120 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -98,6 +98,9 @@
#define QUP_STATUS_ERROR_FLAGS 0x7c
#define QUP_READ_LIMIT 256
+#define SET_BIT0x1
+#define RESET_BIT 0x0
+#define ONE_BYTE 0x1
struct qup_i2c_dev {
struct device *dev;
@@ -221,26 +224,42 @@ static int qup_i2c_change_state(struct qup_i2c_dev *qup,
u32 state)
return 0;
}
-static int qup_i2c_wait_writeready(struct qup_i2c_dev *qup)
+/**
+ * qup_i2c_wait_ready - wait for a give number of bytes in tx/rx path
+ * @qup: The qup_i2c_dev device
+ * @op: The bit/event to wait on
+ * @val: value of the bit to wait on, 0 or 1
+ * @len: The length the bytes to be transferred
+ */
+static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int op, bool val,
+ int len)
{
unsigned long timeout;
u32 opflags;
u32 status;
+ u32 shift = __ffs(op);
- timeout = jiffies + HZ;
+ len *= qup->one_byte_t;
+ /* timeout after a wait of twice the max time */
+ timeout = jiffies + len * 4;
for (;;) {
opflags = readl(qup->base + QUP_OPERATIONAL);
status = readl(qup->base + QUP_I2C_STATUS);
- if (!(opflags & QUP_OUT_NOT_EMPTY) &&
- !(status & I2C_STATUS_BUS_ACTIVE))
- return 0;
+ if (((opflags & op) >> shift) == val) {
+ if (op == QUP_OUT_NOT_EMPTY) {
+ if (!(status & I2C_STATUS_BUS_ACTIVE))
+ return 0;
+ } else {
+ return 0;
+ }
+ }
if (time_after(jiffies, timeout))
return -ETIMEDOUT;
- usleep_range(qup->one_byte_t, qup->one_byte_t * 2);
+ usleep_range(len, len * 2);
}
}
@@ -261,13 +280,13 @@ static void qup_i2c_set_write_mode(struct qup_i2c_dev
*qup, struct i2c_msg *msg)
}
}
-static void qup_i2c_issue_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int qup_i2c_issue_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
{
u32 addr = msg->addr << 1;
u32 qup_tag;
- u32 opflags;
int idx;
u32 val;
+ int ret = 0;
if (qup->pos == 0) {
val = QUP_TAG_START | addr;
@@ -279,9 +298,10 @@ static void qup_i2c_issue_write(struct qup_i2c_dev *qup,
struct i2c_msg *msg)
while (qup->pos < msg->len) {
/* Check that there's space in the FIFO for our pair */
- opflags = readl(qup->base + QUP_OPERATIONAL);
- if (opflags & QUP_OUT_FULL)
- break;
+ ret = qup_i2c_wait_ready(qup, QUP_OUT_FULL, RESET_BIT,
+4 * ONE_BYTE);
+ if (ret)
+ return ret;
if (qup->pos == msg->len - 1)
qup_tag = QUP_TAG_STOP;
@@ -300,6 +320,8 @@ static void qup_i2c_issue_write(struct qup_i2c_dev *qup,
struct i2c_msg *msg)
qup->pos++;
idx++;
}
+
+ return ret;
}
static int qup_i2c_write_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
@@ -325,7 +347,9 @@ static int qup_i2c_write_one(struct qup_i2c_dev *qup,
struct i2c_msg *msg)
if (ret)
goto err;
- qup_i2c_issue_write(qup, msg);
+ ret = qup_i2c_issue_write(qup, msg);
+ if (ret)
+ goto err;
ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
if (ret)
@@ -347,7 +371,7 @@ static int qup_i2c_write_one(struct qup_i2c_dev *qup,
struct i2c_msg *msg)
} while (qup->pos < msg->len);
/* Wait for the outstanding data in the fifo to drain */
- ret = qup_i2c_wait_writeready(qup);
+ ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, RESET_BIT, ONE_BYTE);
err:
disable_irq(qup->irq);
@@ -384,18 +408,19 @@ static void qup_i2c_issue_read(struct qup_i2c_dev *qup,
struct i2c_msg *msg)
}
-static void qup_i2c_read_fifo(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int qup_i2c_read_fifo(struct qup_i2c_dev *qup, struct i2c_msg *msg)
{
- u32 opflags;
u32 val = 0;
[PATCH V4 6/7] dts: msm8974: Add blsp2_bam dma node
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 37b47b5..f138202 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1,6 +1,6 @@
/dts-v1/;
-#include
+#include
#include
#include "skeleton.dtsi"
@@ -301,5 +301,15 @@
interrupt-controller;
#interrupt-cells = <4>;
};
+
+ blsp2_dma: dma-controller@f9944000 {
+ compatible = "qcom,bam-v1.4.0";
+ reg = <0xf9944000 0x19000>;
+ interrupts = ;
+ clocks = < GCC_BLSP2_AHB_CLK>;
+ clock-names = "bam_clk";
+ #dma-cells = <1>;
+ qcom,ee = <0>;
+ };
};
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 2/7] qup: i2c: factor out common code for reuse
The qup_i2c_write/read_one functions can be split to have
the common initialization code and function to loop around
the data bytes separately. This way the initialization code
can be reused while adding v2 tags functionality.
Signed-off-by: Sricharan R
---
drivers/i2c/busses/i2c-qup.c | 147 +--
1 file changed, 87 insertions(+), 60 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 81ed120..131dc28 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -324,53 +324,72 @@ static int qup_i2c_issue_write(struct qup_i2c_dev *qup,
struct i2c_msg *msg)
return ret;
}
-static int qup_i2c_write_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int qup_i2c_wait_for_complete(struct qup_i2c_dev *qup,
+struct i2c_msg *msg)
{
unsigned long left;
- int ret;
-
- qup->msg = msg;
- qup->pos = 0;
+ int ret = 0;
- enable_irq(qup->irq);
+ left = wait_for_completion_timeout(>xfer, HZ);
+ if (!left) {
+ writel(1, qup->base + QUP_SW_RESET);
+ ret = -ETIMEDOUT;
+ }
- qup_i2c_set_write_mode(qup, msg);
+ if (qup->bus_err || qup->qup_err) {
+ if (qup->bus_err & QUP_I2C_NACK_FLAG) {
+ dev_err(qup->dev, "NACK from %x\n", msg->addr);
+ ret = -EIO;
+ }
+ }
- ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
- if (ret)
- goto err;
+ return ret;
+}
- writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL);
+static int qup_i2c_write_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+{
+ int ret = 0;
do {
ret = qup_i2c_change_state(qup, QUP_PAUSE_STATE);
if (ret)
- goto err;
+ return ret;
ret = qup_i2c_issue_write(qup, msg);
if (ret)
- goto err;
+ return ret;
ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
if (ret)
- goto err;
-
- left = wait_for_completion_timeout(>xfer, HZ);
- if (!left) {
- writel(1, qup->base + QUP_SW_RESET);
- ret = -ETIMEDOUT;
- goto err;
- }
+ return ret;
- if (qup->bus_err || qup->qup_err) {
- if (qup->bus_err & QUP_I2C_NACK_FLAG)
- dev_err(qup->dev, "NACK from %x\n", msg->addr);
- ret = -EIO;
- goto err;
- }
+ ret = qup_i2c_wait_for_complete(qup, msg);
+ if (ret)
+ return ret;
} while (qup->pos < msg->len);
- /* Wait for the outstanding data in the fifo to drain */
+ return ret;
+}
+
+static int qup_i2c_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+{
+ int ret;
+
+ qup->msg = msg;
+ qup->pos = 0;
+ enable_irq(qup->irq);
+ qup_i2c_set_write_mode(qup, msg);
+
+ ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
+ if (ret)
+ goto err;
+
+ writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL);
+
+ ret = qup_i2c_write_one(qup, msg);
+ if (ret)
+ goto err;
+
ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, RESET_BIT, ONE_BYTE);
err:
@@ -436,51 +455,59 @@ static int qup_i2c_read_fifo(struct qup_i2c_dev *qup,
struct i2c_msg *msg)
static int qup_i2c_read_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
{
- unsigned long left;
- int ret;
+ int ret = 0;
- qup->msg = msg;
- qup->pos = 0;
+ /*
+* The QUP block will issue a NACK and STOP on the bus when reaching
+* the end of the read, the length of the read is specified as one byte
+* which limits the possible read to 256 (QUP_READ_LIMIT) bytes.
+*/
+ if (msg->len > QUP_READ_LIMIT) {
+ dev_err(qup->dev, "HW not capable of reads over %d bytes\n",
+ QUP_READ_LIMIT);
+ return -EINVAL;
+ }
- enable_irq(qup->irq);
+ ret = qup_i2c_change_state(qup, QUP_PAUSE_STATE);
+ if (ret)
+ return ret;
- qup_i2c_set_read_mode(qup, msg->len);
+ qup_i2c_issue_read(qup, msg);
ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
if (ret)
- goto err;
+ return ret;
- writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL);
+ do {
+ ret = qup_i2c_wait_for_complete(qup, msg);
+ if (ret)
+ return ret;
+ ret = qup_i2c_read_fifo(qup, msg);
+ if (ret)
+ return ret;
[PATCH V4 0/7] i2c: qup: Add support for v2 tags and bam dma
QUP from version 2.1.1 onwards, supports a new format of i2c command tags. Tag codes instructs the controller to perform a operation like read/write. This new tagging version supports and is required for adding bam dma capabilities. V2 tags supports transfer of more than 256 bytes in a single i2c transaction. Also adding bam dma support facilitates transferring each i2c_msg in i2c_msgs without a 'stop' bit in between which is required for some of the clients. Tested this series on apq8074 dragon board eeprom client on i2c bus1 [V4] Added a patch to factor out some common code. Removed support for freq > 400KHZ as per comments. Addressed comments from Ivan T. Ivanov to keep the code for V2 support in a separate path. Changed the authorship of V2 tags support patch. [V3] Added support to coalesce each i2c_msg in i2c_msgs for fifo and block mode in Patch 2. Also addressed further code comments. http://comments.gmane.org/gmane.linux.drivers.i2c/22497 [V2] Addressed comments from Ivan T. Ivanov, Andy Gross [v1] Initial Version Sricharan R (7): i2c: qup: Change qup_wait_writeready function to use for all timeouts qup: i2c: factor out common code for reuse i2c: qup: Add V2 tags support i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit i2c: qup: Add bam dma capabilities dts: msm8974: Add blsp2_bam dma node dts: msm8974: Add dma channels for blsp2_i2c1 node arch/arm/boot/dts/qcom-msm8974.dtsi | 14 +- drivers/i2c/busses/i2c-qup.c| 943 +--- 2 files changed, 880 insertions(+), 77 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kthread: export park/unpark facility
On 07/08/2015 08:40 PM, Jean Tourrilhes wrote:
> Hi,
>
> The kthread park/unpark facility is not used in the kernel
kernel/smpboot.c ?
> , so one would assume that it's made for kernel modules. This patch should
> definitely help most modules.
> Patch untested, at your own risks...
> Regards,
>
> Jean
>
> Signed-off-by: Jean Tourrilhes
>
> diff -u -p linux-3.18.17/kernel/kthread.j2.c linux-3.18.17/kernel/kthread.c
> --- linux-3.18.17/kernel/kthread.j2.c 2015-07-08 17:01:39.010554169 -0700
> +++ linux-3.18.17/kernel/kthread.c2015-07-08 17:09:13.016096189 -0700
> @@ -97,6 +97,7 @@ bool kthread_should_park(void)
> {
> return test_bit(KTHREAD_SHOULD_PARK, _kthread(current)->flags);
> }
> +EXPORT_SYMBOL(kthread_should_park);
>
> /**
> * kthread_freezable_should_stop - should this freezable kthread return now?
> @@ -171,6 +172,7 @@ void kthread_parkme(void)
> {
> __kthread_parkme(to_kthread(current));
> }
> +EXPORT_SYMBOL(kthread_parkme);
>
> static int kthread(void *_create)
> {
> @@ -411,6 +413,7 @@ void kthread_unpark(struct task_struct *
> if (kthread)
> __kthread_unpark(k, kthread);
> }
> +EXPORT_SYMBOL(kthread_unpark);
>
> /**
> * kthread_park - park a thread created by kthread_create().
> @@ -441,6 +444,7 @@ int kthread_park(struct task_struct *k)
> }
> return ret;
> }
> +EXPORT_SYMBOL(kthread_park);
>
> /**
> * kthread_stop - stop a thread created by kthread_create().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 4.2-rc1
On Wed, Jul 8, 2015 at 5:58 PM, Ming Lei wrote:
> On Thu, Jul 9, 2015 at 1:29 AM, Linus Torvalds
> wrote:
>> Also, it looks like you need to hold the "fw_lock" to even look at
>> that pointer, since the buffer can get reallocated etc.
>
> Yes, the above code with holding 'fw_lock' is right fix for the issue since
> sysfs read can happen anytime, and there is one race between firmware
> request abort and reading uevent of sysfs.
So if fw_priv->buf is NULL, what should we do?
Should we skip the TIMEOUT= and ASYNC= fields too?
Something like the attached, perhaps?
Shuah, how reproducible is this? Does this (completely untested) patch
make any difference?
Linus
drivers/base/firmware_class.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 9c4288362a8e..894bda114224 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -563,10 +563,8 @@ static void fw_dev_release(struct device *dev)
kfree(fw_priv);
}
-static int firmware_uevent(struct device *dev, struct kobj_uevent_env *env)
+static int do_firmware_uevent(struct firmware_priv *fw_priv, struct
kobj_uevent_env *env)
{
- struct firmware_priv *fw_priv = to_firmware_priv(dev);
-
if (add_uevent_var(env, "FIRMWARE=%s", fw_priv->buf->fw_id))
return -ENOMEM;
if (add_uevent_var(env, "TIMEOUT=%i", loading_timeout))
@@ -577,6 +575,18 @@ static int firmware_uevent(struct device *dev, struct
kobj_uevent_env *env)
return 0;
}
+static int firmware_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ struct firmware_priv *fw_priv = to_firmware_priv(dev);
+ int err = 0;
+
+ mutex_lock(_lock);
+ if (fw_priv->buf)
+ err = do_firmware_uevent(fw_priv, env);
+ mutex_unlock(_lock);
+ return err;
+}
+
static struct class firmware_class = {
.name = "firmware",
.class_attrs= firmware_class_attrs,
[PATCH V3 1/1] usb:serial:f81534 add F81532/534 driver
This driver is for Fintek F81532/F81534 USB to Serial Ports IC. Features: 1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC 2. Support Baudrate from B50 to B150 (excluding B100). 3. The RTS signal can be transformed their behavior with configuration by default ioctl TIOCGRS485/TIOCSRS485 (for RS232/RS485/RS422 with transceiver) If the driver setting with SER_RS485_ENABLED, the RTS signal will high with not in TX and low with in TX. If the driver setting with SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND, the RTS signal will low with not in TX and high with in TX. 4. There are 4x3 output-only ic pins to control transceiver mode. It's can be controlled via gpiolib. We could found the gpio number from /sys/class/tty/ttyUSB[x]/device/gpiochap[yyy] where x is F81532/534 serial port and yyy is gpiochip number. After we found chip number, we can export 3 gpios(M2/M1/M0) per serial port by echo yyy > /sys/class/gpio/export echo yyy+1 > /sys/class/gpio/export echo yyy+2 > /sys/class/gpio/export then we can control it with echo [M0 value] > /sys/class/gpio/gpio[yyy]/value echo [M1 value] > /sys/class/gpio/gpio[yyy+1]/value echo [M2 value] > /sys/class/gpio/gpio[yyy+2]/value which M0/M1/M2 as your desired value, value is only 0 or 1. When configure complete, It's a must to free all gpio by echo yyy > /sys/class/gpio/unexport echo yyy+1 > /sys/class/gpio/unexport echo yyy+2 > /sys/class/gpio/unexport The driver will "save" gpio configure after we release all gpio of a serial port. For examples to change mode & gpio with F81532/534 Evalaution Board. F81532 EVB port0: F81437 (RS232 only) port1: F81439 (RS232/RS485/RS422 ... etc.) F81534 EVB port0/1: F81437 (RS232 only) port2/3: F81439 (RS232/RS485/RS422 ... etc.) 1. RS232 Mode (Default IC Mode) 1. Set struct serial_rs485 flags "without" SER_RS485_ENABLED (control F81532/534 RTS control) 2. Set M2/M1/M0 as 0/0/1 (control F81532/534 output pin to control transceiver mode) 2. RS485 Mode (RTS Low when TX Mode) 1. Set struct serial_rs485 flags with SER_RS485_ENABLED 2. Set M2/M1/M0 as 0/1/0 3. RS485 Mode (RTS High when TX Mode) 1. Set struct serial_rs485 flags with SER_RS485_ENABLED and SER_RS485_RTS_ON_SEND 2. Set M2/M1/M0 as 0/1/1 4. RS422 Mode 1. The RTS mode is dont care. 2. Set M2/M1/M0 as 0/0/0 Please reference https://bitbucket.org/hpeter/fintek-general/src/ with f81534/tools to get set_gpio.c & set_mode.c. Please use it carefully. Changelog v3 1. Migrate read, write and some routine from custom code to usbserial subsystem callback function. 2. Use more defines to replece magic numbers to make it meaningful 3. Make more comments as document in source code. v2 1. v1 version submit to staging tree, but Greg KH advised me to cleanup source code & re-submit it to correct subsystem 2. Remove all custom ioctl commands Signed-off-by: Peter Hung --- drivers/usb/serial/Kconfig | 10 + drivers/usb/serial/Makefile |1 + drivers/usb/serial/f81534.c | 3316 +++ 3 files changed, 3327 insertions(+) create mode 100644 drivers/usb/serial/f81534.c diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig index 56ecb8b..0642864 100644 --- a/drivers/usb/serial/Kconfig +++ b/drivers/usb/serial/Kconfig @@ -255,6 +255,16 @@ config USB_SERIAL_F81232 To compile this driver as a module, choose M here: the module will be called f81232. +config USB_SERIAL_F8153X + tristate "USB Fintek F81532/534 Multi-Ports Serial Driver" + help + Say Y here if you want to use the Fintek F81532/534 Multi-Ports + usb to serial adapter. + + To compile this driver as a module, choose M here: the + module will be called f81534. + + config USB_SERIAL_GARMIN tristate "USB Garmin GPS driver" help diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile index 349d9df..9e43b7b 100644 --- a/drivers/usb/serial/Makefile +++ b/drivers/usb/serial/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_USB_SERIAL_EDGEPORT) += io_edgeport.o obj-$(CONFIG_USB_SERIAL_EDGEPORT_TI) += io_ti.o obj-$(CONFIG_USB_SERIAL_EMPEG) += empeg.o obj-$(CONFIG_USB_SERIAL_F81232)+= f81232.o +obj-$(CONFIG_USB_SERIAL_F8153X)+= f81534.o obj-$(CONFIG_USB_SERIAL_FTDI_SIO) += ftdi_sio.o obj-$(CONFIG_USB_SERIAL_GARMIN)+= garmin_gps.o obj-$(CONFIG_USB_SERIAL_IPAQ) += ipaq.o diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c new file mode 100644 index 000..8aa0b51 --- /dev/null +++ b/drivers/usb/serial/f81534.c @@
[PATCH] m32r: Add ioreadXX/iowriteXX big-endian mmio accessors
commit c627f2ceb692 ("serial: 8250: Add support for big-endian MMIO accesses")
added support for 32-bit big-endian mmio to the 8250 driver. Support for
ioreadXXbe/iowriteXXbe io accessors was missing from m32r arch, which caused
build errors.
Add trivial macro mmio accessors.
Reported-by: Fengguang Wu
Cc: Kevin Cernekee
Signed-off-by: Peter Hurley
---
arch/m32r/include/asm/io.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 9cc00db..d7a034d 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -173,6 +173,11 @@ static inline void _writel(unsigned long l, unsigned long
addr)
#define iowrite16 writew
#define iowrite32 writel
+#define ioread16be(addr) be16_to_cpu(readw(addr))
+#define ioread32be(addr) be32_to_cpu(readl(addr))
+#define iowrite16be(v, addr) writew(cpu_to_be16(v), (addr))
+#define iowrite32be(v, addr) writel(cpu_to_be32(v), (addr))
+
#define mmiowb()
#define flush_write_buffers() do { } while (0) /* M32R_FIXME */
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: mediatek: Use platform_of_node for machine drivers
This replaces the platform_name in snd_soc_dai_link by device tree node.
Signed-off-by: Koro Chen
---
.../devicetree/bindings/sound/mt8173-max98090.txt | 2 ++
.../bindings/sound/mt8173-rt5650-rt5676.txt | 2 ++
sound/soc/mediatek/mt8173-max98090.c | 17 +
sound/soc/mediatek/mt8173-rt5650-rt5676.c | 19 +++
4 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
b/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
index 829bd26..519e97c 100644
--- a/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
+++ b/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
@@ -3,11 +3,13 @@ MT8173 with MAX98090 CODEC
Required properties:
- compatible : "mediatek,mt8173-max98090"
- mediatek,audio-codec: the phandle of the MAX98090 audio codec
+- mediatek,platform: the phandle of MT8173 ASoC platform
Example:
sound {
compatible = "mediatek,mt8173-max98090";
mediatek,audio-codec = <>;
+ mediatek,platform = <>;
};
diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt
b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt
index 61e98c9..f205ce9 100644
--- a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt
+++ b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt
@@ -3,11 +3,13 @@ MT8173 with RT5650 RT5676 CODECS
Required properties:
- compatible : "mediatek,mt8173-rt5650-rt5676"
- mediatek,audio-codec: the phandles of rt5650 and rt5676 codecs
+- mediatek,platform: the phandle of MT8173 ASoC platform
Example:
sound {
compatible = "mediatek,mt8173-rt5650-rt5676";
mediatek,audio-codec = < >;
+ mediatek,platform = <>;
};
diff --git a/sound/soc/mediatek/mt8173-max98090.c
b/sound/soc/mediatek/mt8173-max98090.c
index 4d44b58..2d2536a 100644
--- a/sound/soc/mediatek/mt8173-max98090.c
+++ b/sound/soc/mediatek/mt8173-max98090.c
@@ -103,7 +103,6 @@ static struct snd_soc_dai_link mt8173_max98090_dais[] = {
.name = "MAX98090 Playback",
.stream_name = "MAX98090 Playback",
.cpu_dai_name = "DL1",
- .platform_name = "1122.mt8173-afe-pcm",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
.trigger = {SND_SOC_DPCM_TRIGGER_POST,
SND_SOC_DPCM_TRIGGER_POST},
@@ -114,7 +113,6 @@ static struct snd_soc_dai_link mt8173_max98090_dais[] = {
.name = "MAX98090 Capture",
.stream_name = "MAX98090 Capture",
.cpu_dai_name = "VUL",
- .platform_name = "1122.mt8173-afe-pcm",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
.trigger = {SND_SOC_DPCM_TRIGGER_POST,
SND_SOC_DPCM_TRIGGER_POST},
@@ -125,7 +123,6 @@ static struct snd_soc_dai_link mt8173_max98090_dais[] = {
{
.name = "Codec",
.cpu_dai_name = "I2S",
- .platform_name = "1122.mt8173-afe-pcm",
.no_pcm = 1,
.codec_dai_name = "HiFi",
.init = mt8173_max98090_init,
@@ -152,9 +149,21 @@ static struct snd_soc_card mt8173_max98090_card = {
static int mt8173_max98090_dev_probe(struct platform_device *pdev)
{
struct snd_soc_card *card = _max98090_card;
- struct device_node *codec_node;
+ struct device_node *codec_node, *platform_node;
int ret, i;
+ platform_node = of_parse_phandle(pdev->dev.of_node,
+"mediatek,platform", 0);
+ if (!platform_node) {
+ dev_err(>dev, "Property 'platform' missing or invalid\n");
+ return -EINVAL;
+ }
+ for (i = 0; i < card->num_links; i++) {
+ if (mt8173_max98090_dais[i].platform_name)
+ continue;
+ mt8173_max98090_dais[i].platform_of_node = platform_node;
+ }
+
codec_node = of_parse_phandle(pdev->dev.of_node,
"mediatek,audio-codec", 0);
if (!codec_node) {
diff --git a/sound/soc/mediatek/mt8173-rt5650-rt5676.c
b/sound/soc/mediatek/mt8173-rt5650-rt5676.c
index 0940553..6f52eca 100644
--- a/sound/soc/mediatek/mt8173-rt5650-rt5676.c
+++ b/sound/soc/mediatek/mt8173-rt5650-rt5676.c
@@ -138,7 +138,6 @@ static struct snd_soc_dai_link mt8173_rt5650_rt5676_dais[]
= {
.name = "rt5650_rt5676 Playback",
.stream_name = "rt5650_rt5676 Playback",
.cpu_dai_name = "DL1",
- .platform_name = "1122.mt8173-afe-pcm",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
.trigger =
[PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue
From: Ronit Halder Fixed a coding style issue. Signed-off-by: Ronit Halder --- drivers/staging/android/ion/ion.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 6f48112..e44f5e6 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -1106,6 +1106,7 @@ struct dma_buf *ion_share_dma_buf(struct ion_client *client, struct ion_buffer *buffer; struct dma_buf *dmabuf; bool valid_handle; + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); mutex_lock(>lock); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Significant performance difference for postgres w/o sched_autogroup
On Wed, 2015-07-08 at 17:45 +0200, Andres Freund wrote: > Workload: > > postgresql (multi-process via shared memory SQL server) and benchmark > client (pgbench, multi threaded) running on the same server. Connected > using unix sockets. The statements are relatively simple (~1.5ms on > average), forcing frequent back/forth between server processes and > pgbench threads. > > I found that disabling sched_autogroup *significantly* reduces > throughput. Even when both server and client are started from the same > terminal and thus should be in the same group! > > There's a significant difference in how %sys with autogroups > enabled/disabled. ~8% v ~27%. That sounds too much. Seems reasonable to me. 1(tg)/2(tgs) > 1(task)/N(tasks), throughput is what the server can sustain on its given budget, larger budget means less client blockage, thus less %sys. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] dt-bindings: pwm: add MediaTek display PWM bindings
On Wed, 2015-07-08 at 20:11 +0800, Daniel Kurtz wrote:
> On Mon, Jul 6, 2015 at 9:29 PM, YH Huang wrote:
> > Document the device-tree binding of MediatTek display PWM.
> > The PWM has one channel to control the backlight brightness for display.
> > It supports MT8173 and MT6595.
> >
> > Signed-off-by: YH Huang
> > ---
> > .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 24
> > ++
> > 1 file changed, 24 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > new file mode 100644
> > index 000..757b974
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > @@ -0,0 +1,24 @@
> > +MediaTek display PWM controller
> > +
> > +Required properties:
> > + - compatible: should be "mediatek,-disp-pwm"
> > + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> > + - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> > + - reg: physical base address and length of the controller's registers
> > + - #pwm-cells: must be 2. See pwm.txt in this directory for a description
> > of
> > + the cell format
> > + - clocks: phandle and clock specifier of the PWM reference clock
> > + - clock-names: must contain the following
> > + - "main": clock used to generate PWM signals
> > + - "mm": sync signals from the modules of mmsys
> > +
> > +Example:
> > + pwm0: pwm@1401e000 {
> > + compatible = "mediatek,mt8173-disp-pwm",
> > +"mediatek,mt6595-disp-pwm";
> > + reg = <0 0x1401e000 0 0x1000>;
> > + #pwm-cells = <2>;
> > + clocks = < CLK_MM_DISP_PWM026M>,
> > +< CLK_MM_DISP_PWM0MM>;
> > + clock-names = "main", "mm";
>
> Should we include the pinctrl settings here to enable the PWM output?
>
Since we use pwm-backlight driver to control backlight, we should enable
PWM output in the backlight node.
Ref:
https://www.kernel.org/doc/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
Regards,
YH Huang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] KVM: SVM: use NPT page attributes
On 07/08/2015 07:19 PM, Paolo Bonzini wrote:
On 08/07/2015 07:59, Xiao Guangrong wrote:
On 07/07/2015 09:45 PM, Paolo Bonzini wrote:
Right now, NPT page attributes are not used, and the final page
attribute depends solely on gPAT (which however is not synced
correctly), the guest MTRRs and the guest page attributes.
However, we can do better by mimicking what is done for VMX.
In the absence of PCI passthrough, the guest PAT can be ignored
and the page attributes can be just WB. If passthrough is being
used, instead, keep respecting the guest PAT, and emulate the guest
MTRRs through the PAT field of the nested page tables.
The only snag is that WP memory cannot be emulated correctly,
because Linux's default PAT setting only includes the other types.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/svm.c | 47 ++-
1 file changed, 42 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 602b974a60a6..0f125c1860ec 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1085,6 +1085,47 @@ static u64 svm_compute_tsc_offset(struct
kvm_vcpu *vcpu, u64 target_tsc)
return target_tsc - tsc;
}
+static void svm_set_guest_pat(struct vcpu_svm *svm, u64 *g_pat)
+{
+struct kvm_vcpu *vcpu = >vcpu;
+
+/* Unlike Intel, AMD takes the guest's CR0.CD into account.
I noticed this code in svm_set_cr0():
if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_CD_NW_CLEARED))
cr0 &= ~(X86_CR0_CD | X86_CR0_NW);
gCR0.CD is hidden to CPU if KVM_QUIRK_CD_NW_CLEARED is not set and looks
like
it is the normal case after grepping Qemu code.
How about this one? I still do not know how SVM properly emulates CR0.CD? :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND 2][PATCH v4] hexdump: fix for non-aligned buffers
On Thu, 9 Jul 2015 03:36:02 +0200 "H. Mijail" wrote: > > > On 09 Jul 2015, at 02:03, Andrew Morton wrote: > > > > On Thu, 9 Jul 2015 01:44:18 +0200 Horacio Mijail Ant__n Quiles > > wrote: > > > >> An hexdump with a buf not aligned to the groupsize causes > >> non-naturally-aligned memory accesses. This was causing a kernel panic on > >> the processor BlackFin BF527, when such an unaligned buffer was fed by the > >> function ubifs_scanned_corruption in fs/ubifs/scan.c . > >> > >> To fix this, if the buffer is not aligned to groupsize in a platform which > >> does not define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, then change the > >> groupsize to 1, so alignment is no longer a problem. > >> This behavior is coherent with the way the function currently deals with > >> inappropriate parameter combinations, which is to fall back to safe > >> "defaults", even if that means changing the output format and the implicit > >> access patterns that could have been expected. > > > > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS seems inappropriate for this. > > Having this unset means "can do unaligned accesses, but they're > > inefficient". It doesn't mean "unaligned accesses go oops". > > > > But I can't the appropriate config knob. There's a > > CONFIG_CPU_HAS_NO_UNALIGNED, but that's an m68k-private thing. > > I'm only a newbie, but I will argue that the lesser evil is checking > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS - until a new configure variable > is defined. > > In Documentation/unaligned-memory-access.txt, an undefined > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is taken as if to mean 'the > hardware isn't able to access memory on arbitrary boundaries'. hm, yes, OK, CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is a poor name. > The other alternative in Documentation/unaligned-memory-access.txt is the > macro get_unaligned() from asm/unaligned.h. However, using get_unaligned() > would mean a much more intrusive patch, since each case of the groupsize > would be changed, and anyway we would still need to check > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to avoid penalising everyone. Actually, I think using get_unaligned() would be a better solution. For architectures which have CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y, get_unaligned() should be fast - just one instruction. This way we avoid having different-appearing output on different architectures. > >> Resent on 8 Jul because of no answers. > >> > >> Resent on 29 Jun because of no answers. > > > > During the merge window. So I have everything sitting there in my > > patches-to-process pile. The backlog is excessive this time (700+ > > emails) so I'm thinking I'll change things so I'll henceforth be > > processing patches-for-the-next-cycle during this-cycle, while keeping > > patches-for-next-cycle out of linux-next. > > No problem for me - if I should squelch the next version of this patch > for some time, please let me know. The merge window has ended ;) > > > > But as mentioned above, that's different from "architectures which do > > not support them efficently"! Maybe we need a new config variable. > > > > Or maybe blackfin should be handling the unaligned access trap and > > transparently handling it, like sparc? > > > > I'll wait for anyone else to weight in' Possibly blackfin *could* emulate unaligned accesses. But according to the documentation, hex_dump_to_buffer() needs to be altered anyway because we cannot rely on the architecture handling such accesses. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] tty: add missing rcu_read_lock for task_pgrp
On 06/29/2015 07:59 PM, Patrick Donnelly wrote: > task_pgrp requires an rcu or tasklist lock to be obtained if the returned pid > is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the > duration of use. Reviewed-by: Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push
On Wed, Jul 08, 2015 at 10:06:10PM +0800, juncheng bai wrote: > Hi, All > > As far as I know, the patch b3f03bac8132207a20286d5602eda64500c19724 > solves one case which big directory size. > > I am not very familiar with xfs, but I think why can't we use vmalloc > when kmalloc fails? Because vmalloc space is greatly limited on 32 bit machines and hence we can't just use vmalloc blindly in these situations. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cxl: Destroy cxl_adapter_idr on module_exit
Acked-by: Ian Munsie We are probably also missing an idr_destroy(>contexts_idr); in cxl_release_afu() as well if you wanted to send a patch for that. Cheers, -Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 5/8] PCI: Add pci_iomap_wc() variants
From: "Luis R. Rodriguez"
PCI BARs tell us whether prefetching is safe, but they don't say
anything about write combining (WC). WC changes ordering rules and
allows writes to be collapsed, so it's not safe in general to use it on
a prefetchable region.
Add pci_iomap_wc() and pci_iomap_wc_range() so drivers can take advantage
of write combining when they know it's safe.
On architectures that don't fully support WC, e.g., x86 without PAT,
drivers for legacy framebuffers may get some of the benefit by using
arch_phys_wc_add() in addition to pci_iomap_wc(). But arch_phys_wc_add()
is unreliable and should be avoided in general. On x86, it uses MTRRs,
which are limited in number and size, so the results will vary based on
driver loading order.
The goals of adding pci_iomap_wc() are to:
- Give drivers an architecture-independent way to use WC so they can stop
using interfaces like mtrr_add() (on x86, pci_iomap_wc() uses
PAT when available).
- Move toward using _PAGE_CACHE_MODE_UC, not _PAGE_CACHE_MODE_UC_MINUS,
on x86 on ioremap_nocache() (see de33c442ed2a ("x86 PAT: fix
performance drop for glx, use UC minus for ioremap(), ioremap_nocache()
and pci_mmap_page_range()").
Signed-off-by: Luis R. Rodriguez
Acked-by: Arnd Bergmann
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Dave Hansen
Cc: Davidlohr Bueso
Cc: david.vra...@citrix.com
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: jbeul...@suse.com
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: konrad.w...@oracle.com
Cc: linux-a...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mel Gorman
Cc: "Michael S. Tsirkin"
Cc: Roger Pau Monné
Cc: Rusty Russell
Cc: Stefan Bader
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: Tomi Valkeinen
Cc: Toshi Kani
Cc: venkatesh.pallip...@intel.com
Cc: Ville Syrjälä
Cc: Vlastimil Babka
Link:
http://lkml.kernel.org/r/1426893517-2511-6-git-send-email-mcg...@do-not-panic.com
Link:
http://lkml.kernel.org/r/1435195342-26879-6-git-send-email-mcg...@do-not-panic.com
[ Move IORESOURCE_IO check up, space out statements for better readability. ]
Signed-off-by: Borislav Petkov
---
include/asm-generic/pci_iomap.h | 14 +
lib/pci_iomap.c | 66 +
2 files changed, 80 insertions(+)
diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index 7389c87116a0..b1e17fcee2d0 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -15,9 +15,13 @@ struct pci_dev;
#ifdef CONFIG_PCI
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long
max);
+extern void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long
max);
extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen);
+extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen);
/* Create a virtual mapping cookie for a port on a given PCI device.
* Do not call this directly, it exists to make it easier for architectures
* to override */
@@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev,
int bar, unsigned lon
return NULL;
}
+static inline void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar,
unsigned long max)
+{
+ return NULL;
+}
static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen)
{
return NULL;
}
+static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen)
+{
+ return NULL;
+}
#endif
#endif /* __ASM_GENERIC_IO_H */
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index bcce5f149310..5f5d24d1d53f 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -52,6 +52,51 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
EXPORT_SYMBOL(pci_iomap_range);
/**
+ * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @offset: map memory at the given offset in BAR
+ * @maxlen: max length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the
Re: [PATCH v5 2/2] cpufreq: mediatek: Add MT8173 cpufreq driver
Hi Viresh,
On Wed, Jul 8, 2015 at 7:34 PM, Viresh Kumar wrote:
> On 01-07-15, 10:16, Pi-Cheng Chen wrote:
>> This patch implements MT8173 cpufreq driver.
>
> Now that you are going to resend this patchset, a few more comments.
>
> Please describe your SoC a bit here, so that reviewers know what are
> we going to implement.
Yes. I will add it.
>
>> +static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
>> +{
>> + struct device *cpu_dev;
>> + struct regulator *proc_reg = ERR_PTR(-ENODEV);
>> + struct regulator *sram_reg = ERR_PTR(-ENODEV);
>> + struct clk *cpu_clk = ERR_PTR(-ENODEV);
>> + struct clk *inter_clk = ERR_PTR(-ENODEV);
>> + struct dev_pm_opp *opp;
>> + unsigned long rate;
>> + int ret;
>> +
>> + cpu_dev = get_cpu_device(cpu);
>> + if (!cpu_dev) {
>> + pr_err("failed to get cpu%d device\n", cpu);
>> + return -ENODEV;
>> + }
>> +
>> + ret = of_init_opp_table(cpu_dev);
>> + if (ret) {
>> + pr_warn("no OPP table for cpu%d\n", cpu);
>> + return ret;
>> + }
>
> Initialize opp table only when you know other resources are available.
> i.e. we aren't going to abort due to EPROBE_DEFER.
Will do it.
>
>> + cpu_clk = clk_get(cpu_dev, "cpu");
>> + if (IS_ERR(cpu_clk)) {
>> + if (PTR_ERR(cpu_clk) == -EPROBE_DEFER)
>> + pr_warn("cpu clk for cpu%d not ready, retry.\n", cpu);
>> + else
>> + pr_err("failed to get cpu clk for cpu%d\n", cpu);
>> +
>> + ret = PTR_ERR(cpu_clk);
>> + goto out_free_opp_table;
>> + }
>> +}
>
>
>> +static int mt8173_cpufreq_probe(struct platform_device *pdev)
>> +{
>> + int ret;
>> +
>> + ret = cpufreq_register_driver(_cpufreq_driver);
>> + if (ret)
>> + pr_err("failed to register mtk cpufreq driver\n");
>> +
>> + return ret;
>> +}
>> +
>> +static struct platform_driver mt8173_cpufreq_platdrv = {
>> + .driver = {
>> + .name = "mt8173-cpufreq",
>> + },
>> + .probe = mt8173_cpufreq_probe,
>> +};
>> +
>> +static int mt8173_cpufreq_driver_init(void)
>> +{
>> + struct platform_device *pdev;
>> + int err;
>> +
>> + if (!of_machine_is_compatible("mediatek,mt8173"))
>> + return -ENODEV;
>
> Why do you need to check this ? Its going to be the right SoC, others
> can't even compile it.
Originally I was thinking this driver should be generic to other Mediatek
SoCs, so I add this check to filter out those SoCs that are not yet
confirmed with this driver supported. Since it's targeted to MT8173 only
now, I will remove this check.
>
>> + err = platform_driver_register(_cpufreq_platdrv);
>> + if (err)
>> + return err;
>> +
>> + pdev = platform_device_register_simple("mt8173-cpufreq", -1, NULL, 0);
>> + if (IS_ERR(pdev)) {
>> + pr_err("failed to register mtk-cpufreq platform device\n");
>> + return PTR_ERR(pdev);
>> + }
>
> This is simply crap. You register the driver and then its device from
> the same function. If you are so sure that this driver is required,
> then why to get into the shit of device-driver model ?
>
> Just call cpufreq_register_driver() from here :), no device/driver
> required.
That's what I did in previous version. But the reason I use the device-
driver model is to handle the defer probing issue. Since there's no
arch/arm64/mach-mediatek/ directory to hold the device registration
code anymore, no device tree way to match cpufreq driver
(please correct me if there's any), and initcall seems not handle
defer probing either, therefore I put both device and driver
registration in this function. I know it's crappy. :(
Do you have any suggestion to do it right and handle defer probing
properly?
Thanks.
Best Regards,
Pi-Cheng
>
> --
> viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 7/8] drivers/video/fbdev/s3fb: Use arch_phys_wc_add() and pci_iomap_wc()
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available.
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()").
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message about
when MTRR fails and doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Geert Uytterhoeven
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jean-Christophe Plagniol-Villard
Cc: Jingoo Han
Cc: Juergen Gross
Cc: "Lad, Prabhakar"
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Rickard Strandqvist
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-9-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/video/fbdev/s3fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index f0ae61a37f04..13b109073c63 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -28,13 +28,9 @@
#include
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
-
struct s3fb_info {
int chip, rev, mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -154,11 +150,7 @@ static const struct svga_timing_regs s3_timing_regs = {
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
-
static int fasttext = 1;
@@ -170,11 +162,8 @@ module_param(mode_option, charp, 0444);
MODULE_PARM_DESC(mode_option, "Default video mode ('640x480-8@60', etc)");
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, "Default video mode ('640x480-8@60', etc)
(deprecated)");
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable,
default=1)");
-#endif
module_param(fasttext, int, 0644);
MODULE_PARM_DESC(fasttext, "Enable S3 fast text mode (1=enable, 0=disable,
default=1)");
@@ -1168,7 +1157,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
info->fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info->screen_base = pci_iomap(dev, 0, 0);
+ info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -1365,12 +1354,9 @@ static int s3_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par->mtrr_reg = -1;
- par->mtrr_reg = mtrr_add(info->fix.smem_start,
info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+
Re: [PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller
On Wed, Jul 08, 2015 at 10:32:54AM -0400, Bill Pringlemeir wrote: > > On 8 Jul 2015, shawn...@kernel.org wrote: > > On Fri, Jun 19, 2015 at 12:58:37AM +0200, Stefan Agner wrote: > >> Enable the NAND Flash Controller driver which is part of the Vybrid > >> SoC by default. > >> > >> Signed-off-by: Stefan Agner > >> --- > >> arch/arm/mach-imx/Kconfig | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig > >> index 3a3d3e9..9358135 100644 > >> --- a/arch/arm/mach-imx/Kconfig > >> +++ b/arch/arm/mach-imx/Kconfig > -589,6 +589,7 @@ config SOC_VF610 > >>select PINCTRL_VF610 > >>select PL310_ERRATA_769419 if CACHE_L2X0 > >>select SMP_ON_UP if SMP > >> + select HAVE_NAND_VF610_NFC > > > I'm not sure about the benefit of having this option, except we have > > to have this additional architecture patch. > > For other SOC, like the PowerPC or ColdFire CPUs with this controller, > it was a way to mark the controller as populated. Otherwise, the > Kconfig entry to select the controller will pop up for everybody. IMHO, having the option pop up for everybody isn't really a problem. On the other hand, we can even compile test the driver on any architecture without the COMPILE_TEST dependency. But if MTD maintainer has a different opinion, we can still have a 'depends on SOC_VF610' to save this patch. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pinctrl: move CONFIG_PINCTRL to drivers/Makefile
Kbuild should descend into drivers/pinctrl/ only when CONFIG_PINCTRL is enabled because everything under that directory depends on CONFIG_PINCTRL. We can avoid the conditional, ifeq ($(CONFIG_OF),y) ... endif. Signed-off-by: Masahiro Yamada --- drivers/Makefile | 2 +- drivers/pinctrl/Makefile | 6 ++ 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/Makefile b/drivers/Makefile index b64b49f..e4b260e 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -11,7 +11,7 @@ obj-y += bus/ obj-$(CONFIG_GENERIC_PHY) += phy/ # GPIO must come after pinctrl as gpios may need to mux pins etc -obj-y += pinctrl/ +obj-$(CONFIG_PINCTRL) += pinctrl/ obj-y += gpio/ obj-y += pwm/ obj-$(CONFIG_PCI) += pci/ diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile index f6710a8..76ba976 100644 --- a/drivers/pinctrl/Makefile +++ b/drivers/pinctrl/Makefile @@ -2,12 +2,10 @@ subdir-ccflags-$(CONFIG_DEBUG_PINCTRL) += -DDEBUG -obj-$(CONFIG_PINCTRL) += core.o pinctrl-utils.o +obj-y += core.o pinctrl-utils.o obj-$(CONFIG_PINMUX) += pinmux.o obj-$(CONFIG_PINCONF) += pinconf.o -ifeq ($(CONFIG_OF),y) -obj-$(CONFIG_PINCTRL) += devicetree.o -endif +obj-$(CONFIG_OF) += devicetree.o obj-$(CONFIG_GENERIC_PINCONF) += pinconf-generic.o obj-$(CONFIG_PINCTRL_ADI2) += pinctrl-adi2.o obj-$(CONFIG_PINCTRL_AS3722) += pinctrl-as3722.o -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 8/8] drivers/video/fbdev/vt8623fb: Use arch_phys_wc_add() and pci_iomap_wc()
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available.
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()").
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message about
when MTRR fails and doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jean-Christophe Plagniol-Villard
Cc: Jingoo Han
Cc: Juergen Gross
Cc: "Lad, Prabhakar"
Cc: Laurent Pinchart
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Rob Clark
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-10-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/video/fbdev/vt8623fb.c | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index 8bac309c24b9..dd0f18e42d3e 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -26,13 +26,9 @@
#include /* Why should fb driver call console functions?
because console_lock() */
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
-
struct vt8623fb_info {
char __iomem *mmio_base;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -99,10 +95,7 @@ static struct svga_timing_regs vt8623_timing_regs = {
/* Module parameters */
static char *mode_option = "640x480-8@60";
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
MODULE_AUTHOR("(c) 2006 Ondrej Zajicek ");
MODULE_LICENSE("GPL");
@@ -112,11 +105,8 @@ module_param(mode_option, charp, 0644);
MODULE_PARM_DESC(mode_option, "Default video mode ('640x480-8@60', etc)");
module_param_named(mode, mode_option, charp, 0);
MODULE_PARM_DESC(mode, "Default video mode e.g. '648x480-8@60' (deprecated)");
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable,
default=1)");
-#endif
/* - */
@@ -710,7 +700,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
info->fix.mmio_len = pci_resource_len(dev, 1);
/* Map physical IO memory address into kernel space */
- info->screen_base = pci_iomap(dev, 0, 0);
+ info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -781,12 +771,9 @@ static int vt8623_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par->mtrr_reg = -1;
- par->mtrr_reg =
[PATCH v9 4/8] drivers/video/fbdev/gxt4500: Use pci_ioremap_wc_bar() to map framebuffer
From: "Luis R. Rodriguez"
The driver doesn't use mtrr_add() or arch_phys_wc_add() but since we
know the framebuffer is isolated already on an ioremap() we can take
advantage of write combining for performance where possible.
In this case there are a few motivations for this:
a) Take advantage of PAT when available.
b) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()").
Signed-off-by: Luis R. Rodriguez
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Geert Uytterhoeven
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: Laurent Pinchart
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Rob Clark
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-5-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/video/fbdev/gxt4500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 135d78a02588..f19133a80e8c 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -662,7 +662,7 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
info->fix.smem_start = fb_phys;
info->fix.smem_len = pci_resource_len(pdev, 1);
- info->screen_base = pci_ioremap_bar(pdev, 1);
+ info->screen_base = pci_ioremap_wc_bar(pdev, 1);
if (!info->screen_base) {
dev_err(>dev, "gxt4500: cannot map framebuffer\n");
goto err_unmap_regs;
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 1/8] PCI: Add pci_ioremap_wc_bar()
From: "Luis R. Rodriguez"
This lets drivers take advantage of PAT when available. It should help
with the transition of converting video drivers over to ioremap_wc()
to help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache(), see:
de33c442ed2a ("x86 PAT: fix performance drop for glx, use UC minus for
ioremap(),
ioremap_nocache() and pci_mmap_page_range()")
Signed-off-by: Luis R. Rodriguez
Acked-by: Arnd Bergmann
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: b...@kernel.crashing.org
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Davidlohr Bueso
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mel Gorman
Cc: m...@redhat.com
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: Tomi Valkeinen
Cc: Toshi Kani
Cc: Ville Syrjälä
Cc: Vlastimil Babka
Link:
http://lkml.kernel.org/r/1435195342-26879-2-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/pci/pci.c | 14 ++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 0008c950452c..fdae37b473f8 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -138,6 +138,20 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int
bar)
return ioremap_nocache(res->start, resource_size(res));
}
EXPORT_SYMBOL_GPL(pci_ioremap_bar);
+
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
+{
+ /*
+* Make sure the BAR is actually a memory resource, not an IO resource
+*/
+ if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) {
+ WARN_ON(1);
+ return NULL;
+ }
+ return ioremap_wc(pci_resource_start(pdev, bar),
+ pci_resource_len(pdev, bar));
+}
+EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
#endif
#define PCI_FIND_CAP_TTL 48
diff --git a/include/linux/pci.h b/include/linux/pci.h
index c0dd4ab5c2f5..1193975d20c3 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1657,6 +1657,7 @@ static inline void pci_mmcfg_late_init(void) { }
int pci_ext_cfg_avail(void);
void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar);
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar);
#ifdef CONFIG_PCI_IOV
int pci_iov_virtfn_bus(struct pci_dev *dev, int id);
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 6/8] drivers/video/fbdev/arkfb.c: Use arch_phys_wc_add() and pci_iomap_wc()
From: "Luis R. Rodriguez"
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that also
ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available.
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()").
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message about
when MTRR fails and doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Geert Uytterhoeven
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: "Lad, Prabhakar"
Cc: Laurent Pinchart
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-8-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/video/fbdev/arkfb.c | 36 +---
1 file changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index b305a1e7cc76..6a317de7082c 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -26,13 +26,9 @@
#include /* Why should fb driver call console functions?
because console_lock() */
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
-
struct arkfb_info {
int mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct dac_info *dac;
struct vgastate state;
@@ -102,10 +98,6 @@ static const struct svga_timing_regs ark_timing_regs = {
static char *mode_option = "640x480-8@60";
-#ifdef CONFIG_MTRR
-static int mtrr = 1;
-#endif
-
MODULE_AUTHOR("(c) 2007 Ondrej Zajicek ");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("fbdev driver for ARK 2000PV");
@@ -115,11 +107,6 @@ MODULE_PARM_DESC(mode_option, "Default video mode
('640x480-8@60', etc)");
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, "Default video mode ('640x480-8@60', etc)
(deprecated)");
-#ifdef CONFIG_MTRR
-module_param(mtrr, int, 0444);
-MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable,
default=1)");
-#endif
-
static int threshold = 4;
module_param(threshold, int, 0644);
@@ -1002,7 +989,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
info->fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info->screen_base = pci_iomap(dev, 0, 0);
+ info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -1057,14 +1044,8 @@ static int ark_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par->mtrr_reg = -1;
- par->mtrr_reg = mtrr_add(info->fix.smem_start,
info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
-
+ par->wc_cookie =
[PATCH v9 2/8] drivers/video/fbdev/i740fb: Use arch_phys_wc_add() and pci_ioremap_wc_bar()
From: "Luis R. Rodriguez"
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRR if
write-combining is available, in order to take advantage of that also
ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")
The conversion done is expressed by the following Coccinelle SmPL
patch, it additionally required manual intervention to address all the
ifdeffery and removal of redundant things which arch_phys_wc_add()
already addresses such as verbose message about when MTRR fails and
doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: b...@kernel.crashing.org
Cc: Benoit Taine
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Geert Uytterhoeven
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jean-Christophe Plagniol-Villard
Cc: Jingoo Han
Cc: Juergen Gross
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Rob Clark
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-3-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/video/fbdev/i740fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/i740fb.c b/drivers/video/fbdev/i740fb.c
index a2b4204b42bb..452e1163ad02 100644
--- a/drivers/video/fbdev/i740fb.c
+++ b/drivers/video/fbdev/i740fb.c
@@ -27,24 +27,15 @@
#include
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
-
#include "i740_reg.h"
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
struct i740fb_par {
unsigned char __iomem *regs;
bool has_sgram;
-#ifdef CONFIG_MTRR
- int mtrr_reg;
-#endif
+ int wc_cookie;
bool ddc_registered;
struct i2c_adapter ddc_adapter;
struct i2c_algo_bit_data ddc_algo;
@@ -1040,7 +1031,7 @@ static int i740fb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
goto err_request_regions;
}
- info->screen_base = pci_ioremap_bar(dev, 0);
+ info->screen_base = pci_ioremap_wc_bar(dev, 0);
if (!info->screen_base) {
dev_err(info->device, "error remapping base\n");
ret = -ENOMEM;
@@ -1144,13 +1135,9 @@ static int i740fb_probe(struct pci_dev *dev, const
struct pci_device_id *ent)
fb_info(info, "%s frame buffer device\n", info->fix.id);
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par->mtrr_reg = -1;
- par->mtrr_reg = mtrr_add(info->fix.smem_start,
- info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par->wc_cookie = arch_phys_wc_add(info->fix.smem_start,
+ info->fix.smem_len);
return 0;
err_reg_framebuffer:
@@ -1177,13 +1164,7 @@ static void i740fb_remove(struct pci_dev *dev)
if (info) {
struct i740fb_par *par = info->par;
-
-#ifdef CONFIG_MTRR
- if (par->mtrr_reg >= 0) {
- mtrr_del(par->mtrr_reg, 0, 0);
- par->mtrr_reg = -1;
- }
-#endif
+ arch_phys_wc_del(par->wc_cookie);
unregister_framebuffer(info);
fb_dealloc_cmap(>cmap);
if
[PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
From: "Luis R. Rodriguez" Ingo, Boris is on vacation, he picked up these patches on his bp#tip-mm tree [0] and they have baked there for a while now. That tree receives 0-day bot testing, but other than that its not clear what other tests were run on these patches. Boris modified the commit logs a bit, and made one optimizaiton to bail early on an PCI ioremap call when it should. These patches have no modifications from what is on Boris' tree and tip-mm branch. The 0 day build bot did find issues on Boris' tree but those are related to ioremap_uc() (already upstream) and its first use on atyfb (not upstream) -- I will be addressing a fix for that ioremap_uc() issue through another patch series prior to posting the final set for atyfb which makes use of ioremap_uc(). No issues have been found with this series. Benh did note some possible issues with expectations with what is done for write-combining for PowerPC [1] but the issue is a rather general long standing issue with semantics of ioremap -- in the case for ioremap_wc() on PowerPC benh notes that writel() will never write-combine as it uses too heavy barriers. Benh notes that although writel_relaxed() today is identical to writel() this can be changed. There are other general semantics issues with ioremap() variant calls -- we seem to have all gotten together to discuss all these issues on a thread where Dan Williams is proposing to "unify ioremap prototypes and macro aliases" [1], folks intersted on these issues or semantic concerns can drop in and chime there. Let me know if these are OK or if there are any questions. [0] http://lkml.kernel.org/r/20150625204703.gc4...@pd.tnic [1] http://lkml.kernel.org/r/20150707095012.gq7...@wotan.suse.de Luis R. Rodriguez (8): PCI: Add pci_ioremap_wc_bar() drivers/video/fbdev/i740fb: Use arch_phys_wc_add() and pci_ioremap_wc_bar() drivers/video/fbdev/kyrofb: Use arch_phys_wc_add() and pci_ioremap_wc_bar() drivers/video/fbdev/gxt4500: Use pci_ioremap_wc_bar() to map framebuffer PCI: Add pci_iomap_wc() variants drivers/video/fbdev/arkfb.c: Use arch_phys_wc_add() and pci_iomap_wc() drivers/video/fbdev/s3fb: Use arch_phys_wc_add() and pci_iomap_wc() drivers/video/fbdev/vt8623fb: Use arch_phys_wc_add() and pci_iomap_wc() drivers/pci/pci.c| 14 + drivers/video/fbdev/arkfb.c | 36 +++--- drivers/video/fbdev/gxt4500.c| 2 +- drivers/video/fbdev/i740fb.c | 35 - drivers/video/fbdev/kyro/fbdev.c | 33 +++- drivers/video/fbdev/s3fb.c | 35 - drivers/video/fbdev/vt8623fb.c | 31 --- include/asm-generic/pci_iomap.h | 14 + include/linux/pci.h | 1 + include/video/kyro.h | 4 +-- lib/pci_iomap.c | 66 11 files changed, 131 insertions(+), 140 deletions(-) -- 2.3.2.209.gd67f9d5.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 3/8] drivers/video/fbdev/kyrofb: Use arch_phys_wc_add() and pci_ioremap_wc_bar()
From: "Luis R. Rodriguez"
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRR if
write-combining is available, in order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")
The conversion done is expressed by the following Coccinelle SmPL
patch, it additionally required manual intervention to address all the
ifdeffery and removal of redundant things which arch_phys_wc_add()
already addresses such as verbose message about when MTRR fails and
doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Acked-by: Tomi Valkeinen
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: Arnd Bergmann
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Geert Uytterhoeven
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jean-Christophe Plagniol-Villard
Cc: Jingoo Han
Cc: Juergen Gross
Cc: Laurent Pinchart
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-4-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/video/fbdev/kyro/fbdev.c | 33 +++--
include/video/kyro.h | 4 +---
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/kyro/fbdev.c b/drivers/video/fbdev/kyro/fbdev.c
index 65041e15fd59..5bb01533271e 100644
--- a/drivers/video/fbdev/kyro/fbdev.c
+++ b/drivers/video/fbdev/kyro/fbdev.c
@@ -22,9 +22,6 @@
#include
#include
#include
-#ifdef CONFIG_MTRR
-#include
-#endif
#include
@@ -84,9 +81,7 @@ static device_info_t deviceInfo;
static char *mode_option = NULL;
static int nopan = 0;
static int nowrap = 1;
-#ifdef CONFIG_MTRR
static int nomtrr = 0;
-#endif
/* PCI driver prototypes */
static int kyrofb_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
@@ -570,10 +565,8 @@ static int __init kyrofb_setup(char *options)
nopan = 1;
} else if (strcmp(this_opt, "nowrap") == 0) {
nowrap = 1;
-#ifdef CONFIG_MTRR
} else if (strcmp(this_opt, "nomtrr") == 0) {
nomtrr = 1;
-#endif
} else {
mode_option = this_opt;
}
@@ -691,17 +684,16 @@ static int kyrofb_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
currentpar->regbase = deviceInfo.pSTGReg =
ioremap_nocache(kyro_fix.mmio_start, kyro_fix.mmio_len);
+ if (!currentpar->regbase)
+ goto out_free_fb;
- info->screen_base = ioremap_nocache(kyro_fix.smem_start,
- kyro_fix.smem_len);
+ info->screen_base = pci_ioremap_wc_bar(pdev, 0);
+ if (!info->screen_base)
+ goto out_unmap_regs;
-#ifdef CONFIG_MTRR
if (!nomtrr)
- currentpar->mtrr_handle =
- mtrr_add(kyro_fix.smem_start,
-kyro_fix.smem_len,
-MTRR_TYPE_WRCOMB, 1);
-#endif
+ currentpar->wc_cookie = arch_phys_wc_add(kyro_fix.smem_start,
+kyro_fix.smem_len);
kyro_fix.ypanstep = nopan ? 0 : 1;
kyro_fix.ywrapstep = nowrap ? 0 : 1;
@@ -745,8 +737,10 @@ static int
Re: [PATCH 1/2] ASoC: rt5645: Fix missing free_irq
On Wed, 2015-07-08 at 12:14 +0100, Mark Brown wrote: > On Wed, Jul 08, 2015 at 04:25:50PM +0800, Koro Chen wrote: > > > The driver does not free irq if snd_soc_register_codec fails. > > It does not return error when request irq failed, either. > > Fix this by using devm_request_threaded_irq(), and returns when error. > > Unfortunately this isn't safe... > > > - if (i2c->irq) > > - free_irq(i2c->irq, rt5645); > > - > > cancel_delayed_work_sync(>jack_detect_work); > > This work item is queued up by the interrupt handler so we need to > unregister the interrupt before we cancel any pending work otherwise > it's possible that the interrupt may fire after we cancelled the work. Thank you for seeing this, I didn't notice the delayed work. Do you think I should use devm_request_threaded_irq(), and change free_irq to devm_free_irq in remove? Or I should keep the original request_thread_irq(), and just add a free_irq() during probe failed? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] trivial: fix typos and remove double words
On 07/08/15 01:42, Cristian Stoica wrote: > - to to > - when when > > Signed-off-by: Cristian Stoica > Reviewed-by: Randy Dunlap Reviewed-by: Randy Dunlap Now you can include that tag. You shouldn't add it before I offer it. Thanks. > --- > v3 - updates after Randy's review (v2 missed drivers/i2c/busses/Kconfig) > > Documentation/PCI/pci.txt | 2 +- > Documentation/RCU/lockdep.txt | 4 ++-- > Documentation/cpu-freq/cpu-drivers.txt| 2 +- > arch/arc/mm/cache.c | 2 +- > arch/arm/mach-davinci/cp_intc.c | 2 +- > arch/ia64/kernel/acpi.c | 2 +- > arch/powerpc/sysdev/ppc4xx_cpm.c | 2 +- > arch/x86/kvm/paging_tmpl.h| 2 +- > arch/x86/mm/pgtable.c | 2 +- > drivers/block/cciss.c | 2 +- > drivers/block/cciss_cmd.h | 2 +- > drivers/clk/bcm/clk-kona-setup.c | 2 +- > drivers/crypto/n2_core.c | 2 +- > drivers/dma/ep93xx_dma.c | 2 +- > drivers/gpu/drm/i915/intel_panel.c| 2 +- > drivers/gpu/drm/vmwgfx/svga_reg.h | 2 +- > drivers/i2c/busses/Kconfig| 2 +- > drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 ++-- > drivers/i2c/busses/i2c-viperboard.c | 4 ++-- > drivers/infiniband/hw/qib/qib_pcie.c | 2 +- > drivers/input/mouse/hgpk.c| 2 +- > drivers/md/dm-cache-policy-mq.c | 2 +- > drivers/mmc/core/host.c | 2 +- > drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c | 2 +- > drivers/net/ethernet/chelsio/cxgb4vf/sge.c| 2 +- > drivers/net/ethernet/intel/e1000/e1000_hw.c | 2 +- > drivers/net/wireless/ath/ath10k/mac.c | 2 +- > drivers/net/wireless/ath/ath10k/testmode.c| 4 ++-- > drivers/net/wireless/ath/ath9k/hw.h | 2 +- > drivers/net/wireless/brcm80211/brcmsmac/types.h | 4 ++-- > drivers/net/wireless/iwlwifi/dvm/lib.c| 2 +- > drivers/net/wireless/iwlwifi/mvm/d3.c | 2 +- > drivers/net/wireless/iwlwifi/mvm/fw-api-power.h | 2 +- > drivers/ps3/ps3-lpm.c | 2 +- > drivers/scsi/hpsa.c | 2 +- > drivers/scsi/mpt2sas/mpt2sas_base.h | 2 +- > drivers/scsi/mpt2sas/mpt2sas_transport.c | 2 +- > drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +- > drivers/scsi/mpt3sas/mpt3sas_transport.c | 2 +- > drivers/scsi/snic/snic_debugfs.c | 2 +- > drivers/staging/lustre/lustre/include/cl_object.h | 2 +- > drivers/staging/lustre/lustre/libcfs/hash.c | 2 +- > drivers/staging/wilc1000/host_interface.c | 2 +- > drivers/usb/host/uhci-grlib.c | 2 +- > drivers/usb/host/uhci-platform.c | 2 +- > fs/btrfs/ioctl.c | 2 +- > fs/ocfs2/refcounttree.c | 2 +- > fs/xfs/xfs_trans_ail.c| 2 +- > include/linux/cpufreq.h | 2 +- > include/linux/mm.h| 2 +- > net/mac80211/sta_info.h | 4 ++-- > net/netlink/genetlink.c | 2 +- > net/tipc/msg.c| 2 +- > sound/soc/tegra/tegra20_das.h | 4 ++-- > tools/perf/Documentation/perf-script-perl.txt | 2 +- > tools/perf/Documentation/perf-script-python.txt | 2 +- > tools/perf/util/event.h | 2 +- > tools/testing/ktest/sample.conf | 2 +- > tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc | 2 +- > 59 files changed, 66 insertions(+), 66 deletions(-) -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 27/42] x86: restore end_of_ram to E820_RAM
On Wed, Jul 8, 2015 at 10:44 AM, Matt Fleming wrote:
> On Tue, 07 Jul, at 01:20:13PM, Yinghai Lu wrote:
>> We don't need to create mapping for E820_PRAM.
>>
>> Signed-off-by: Yinghai Lu
>> ---
>> arch/x86/kernel/e820.c | 12
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
>> index a102564..46ec08d 100644
>> --- a/arch/x86/kernel/e820.c
>> +++ b/arch/x86/kernel/e820.c
>> @@ -753,7 +753,7 @@ u64 __init early_reserve_e820(u64 size, u64 align)
>> /*
>> * Find the highest page frame number we have available
>> */
>> -static unsigned long __init e820_end_pfn(unsigned long limit_pfn)
>> +static unsigned long __init e820_end_pfn(unsigned long limit_pfn, unsigned
>> type)
>> {
>> int i;
>> unsigned long last_pfn = 0;
>> @@ -764,11 +764,7 @@ static unsigned long __init e820_end_pfn(unsigned long
>> limit_pfn)
>> unsigned long start_pfn;
>> unsigned long end_pfn;
>>
>> - /*
>> - * Persistent memory is accounted as ram for purposes of
>> - * establishing max_pfn and mem_map.
>> - */
>> - if (ei->type != E820_RAM && ei->type != E820_PRAM)
>> + if (ei->type != type)
>> continue;
>>
>> start_pfn = ei->addr >> PAGE_SHIFT;
>> @@ -793,12 +789,12 @@ static unsigned long __init e820_end_pfn(unsigned long
>> limit_pfn)
>> }
>> unsigned long __init e820_end_of_ram_pfn(void)
>> {
>> - return e820_end_pfn(MAX_ARCH_PFN);
>> + return e820_end_pfn(MAX_ARCH_PFN, E820_RAM);
>> }
>>
>> unsigned long __init e820_end_of_low_ram_pfn(void)
>> {
>> - return e820_end_pfn(1UL << (32-PAGE_SHIFT));
>> + return e820_end_pfn(1UL<<(32 - PAGE_SHIFT), E820_RAM);
>> }
>>
>> static void early_panic(char *msg)
>
> Could you explain why you no longer want to allow pesistent memory to be
> used in figuring out max_pfn? This partially reverts commit ec776ef6bbe1
> ("x86/mm: Add support for the non-standard protected e820 type").
>
pmem is accessed through the driver or through ->direct_access().
Existing NVDIMM devices are already pushing hundreds of gigabytes
which is too large to provide "struct page" coverage by default.
We're looking at other means to provide "struct page" for pmem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net-ipvs: Delete an unnecessary check before the function call "module_put"
On Thu, Jul 02, 2015 at 05:10:41PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 2 Jul 2015 17:00:14 +0200 > > The module_put() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. Thanks, applied to ipvs-next for v4.3. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases
On Tue, Jul 07, 2015 at 05:10:58PM -0600, Toshi Kani wrote:
> On Tue, 2015-07-07 at 18:07 +0200, Luis R. Rodriguez wrote:
> > On Tue, Jul 07, 2015 at 11:13:30AM +0100, Russell King - ARM Linux
> > wrote:
> :
> > > On ARM, we (probably) have a lot of cases where ioremap() is used
> > > multiple
> > > times for the same physical address space, so we shouldn't rule out
> > > having
> > > multiple mappings of the same type.
> >
> > Why is that done? Don't worry if you are not sure why but only
> > speculate of the
> > practice's existence (sloppy drivers or lazy driver developers). FWIW
> > for x86
> > IIRC I ended up concluding that overlapping ioremap() calls with the
> > same type
> > would work but not if they differ in type. Although I haven't
> > written a
> > grammer rule to hunt down overlapping ioremap() I suspected its use
> > was likely
> > odd and likely should be reconsidered. Would this be true for ARM too
> > ? Or are
> > you saying this should be a feature ? I don't expect an answer now
> > but I'm
> > saying we *should* all together decide on this, and if you're
> > inclined to
> > believe that this should ideally be avoided I'd like to hear that. If
> > you feel
> > strongly though this should be a feature I would like to know why.
>
> There are multiple mapping interfaces, and overlapping can happen among
> them as well. For instance, remap_pfn_range() (and
> io_remap_pfn_range(), which is the same as remap_pfn_range() on x86)
> creates a mapping to user space. The same physical ranges may be
> mapped to kernel and user spaces. /dev/mem is one example that may
> create a user space mapping to a physical address that is already
> mapped with ioremap() by other module.
Thanks for the feedback. The restriction seems to be differing cache types
requirements, other than this, are there any other concerns ? For instance are
we completley happy with aliasing so long as cache types match everywhere? I'd
expect no architecture would want cache types to differ when aliasing, what
should differ then I think would just be how to verify this and it doesn't seem
we may be doing this for all architectures.
Even for userspace we seem to be covered -- we enable userspace mmap() calls to
get their mapped space with a cache type, on the kernel we'd say use
pgprot_writecombine() on the vma->vm_page_prot prior to the
io_remap_pfn_range() -- that maps to remap_pfn_range() on x86 and as you note
that checks cache type via reserve_memtype() -- but only on x86...
Other than this differing cache type concern are we OK with aliasing in
userspace all the time ?
If we want to restrict aliasing either for the kernel or userspace mapping
we might be able to do it, I just want to know if we want to or not care
at all.
> pmem and DAX also create mappings to the same NVDIMM ranges. DAX calls
> vm_insert_mixed(), which is particularly a problematic since
> vm_insert_mixed() does not verify aliasing. ioremap() and remap_pfn_range()
> call reserve_memtype() to verify aliasing on x86. reserve_memtype() is
> x86-specific and there is no arch-generic wrapper for such check.
As clarified by Matthew Wilcox via commit d92576f1167cacf7844 ("dax: does not
work correctly with virtual aliasing caches") caches are virtually mapped for
some architectures, it seems it should be possible to fix this for DAX somehow
though.
> I think DAX could get a cache type from pmem to keep them in sync, though.
pmem is x86 specific right now, are other folks going to expose something
similar ? Otherwise we seem to only be addressing these deep concerns for
x86 so far.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/13] arm64: KVM: VHE: Add alternatives for VHE-enabled world-switch
On 07/08/2015 09:19 AM, Marc Zyngier wrote: > In order to switch between host and guest, a VHE-enabled kernel > must use different accessors for certain system registers. > > This patch uses runtime patching to use the right instruction > when required... > > Signed-off-by: Marc Zyngier > --- > arch/arm64/include/asm/kvm_asm.h | 40 ++-- > arch/arm64/kvm/hyp.S | 210 > ++- > arch/arm64/kvm/vhe-macros.h | 18 > 3 files changed, 191 insertions(+), 77 deletions(-) > [] > * Author: Marc Zyngier > * > * This program is free software; you can redistribute it and/or modify > @@ -67,40 +67,52 @@ > stp x29, lr, [x3, #80] > > mrs x19, sp_el0 > - mrs x20, elr_el2// pc before entering el2 > - mrs x21, spsr_el2 // pstate before entering el2 > + str x19, [x3, #96] > +.endm > > - stp x19, x20, [x3, #96] > - str x21, [x3, #112] Hi Marc, trying to make a little sense out of this :) In the case of VHE kernel the two 'mrs_hyp()' and 'mrs_el1()' calls would be accessing same registers - namely EL1 variants? For non VHE EL2, EL1? The mrs_s and sysreg_EL12 are new, not sure what these mean. - Mario > +.macro save_el1_state > + mrs_hyp(x20, ELR) // pc before entering el2 > + mrs_hyp(x21, SPSR) // pstate before entering el2 > > mrs x22, sp_el1 > - mrs x23, elr_el1 > - mrs x24, spsr_el1 > + > + mrs_el1(x23, elr) > + mrs_el1(x24, spsr) > + > + add x3, x2, #CPU_XREG_OFFSET(31)// SP_EL0 > + stp x20, x21, [x3, #8] // HACK: Store to the regs after SP_EL0 > > str x22, [x2, #CPU_GP_REG_OFFSET(CPU_SP_EL1)] > str x23, [x2, #CPU_GP_REG_OFFSET(CPU_ELR_EL1)] > str x24, [x2, #CPU_SPSR_OFFSET(KVM_SPSR_EL1)] > .endm > > -.macro restore_common_regs > +.macro restore_el1_state > // x2: base address for cpu context > // x3: tmp register > > + add x3, x2, #CPU_XREG_OFFSET(31)// SP_EL0 > + ldp x20, x21, [x3, #8] // Same hack again, get guest PC and pstate > + > ldr x22, [x2, #CPU_GP_REG_OFFSET(CPU_SP_EL1)] > ldr x23, [x2, #CPU_GP_REG_OFFSET(CPU_ELR_EL1)] > ldr x24, [x2, #CPU_SPSR_OFFSET(KVM_SPSR_EL1)] > > + msr_hyp(ELR, x20) // pc on return from el2 > + msr_hyp(SPSR, x21) // pstate on return from el2 > + > msr sp_el1, x22 > - msr elr_el1, x23 > - msr spsr_el1, x24 > > - add x3, x2, #CPU_XREG_OFFSET(31)// SP_EL0 > - ldp x19, x20, [x3] > - ldr x21, [x3, #16] > + msr_el1(elr, x23) > + msr_el1(spsr, x24) > +.endm > > +.macro restore_common_regs > + // x2: base address for cpu context > + // x3: tmp register > + > + ldr x19, [x2, #CPU_XREG_OFFSET(31)] // SP_EL0 > msr sp_el0, x19 > - msr elr_el2, x20// pc on return from el2 > - msr spsr_el2, x21 // pstate on return from el2 > > add x3, x2, #CPU_XREG_OFFSET(19) > ldp x19, x20, [x3] > @@ -113,9 +125,15 @@ > > .macro save_host_regs > save_common_regs > +ifnvhe nop,"b skip_el1_save" > + save_el1_state > +skip_el1_save: > .endm > > .macro restore_host_regs > +ifnvhe nop,"b > skip_el1_restore" > + restore_el1_state > +skip_el1_restore: > restore_common_regs > .endm > > @@ -159,6 +177,7 @@ > stp x6, x7, [x3, #16] > > save_common_regs > + save_el1_state > .endm > > .macro restore_guest_regs > @@ -184,6 +203,7 @@ > ldr x18, [x3, #144] > > // x19-x29, lr, sp*, elr*, spsr* > + restore_el1_state > restore_common_regs > > // Last bits of the 64bit state > @@ -203,6 +223,38 @@ > * In other words, don't touch any of these unless you know what > * you are doing. > */ > + > +.macro save_shared_sysregs > + // x2: base address for cpu context > + // x3: tmp register > + > + add x3, x2, #CPU_SYSREG_OFFSET(TPIDR_EL0) > + > + mrs x4, tpidr_el0 > + mrs x5, tpidrro_el0 > + mrs x6, tpidr_el1 > + mrs x7, actlr_el1 > + > + stp x4, x5, [x3] > + stp x6, x7, [x3, #16] > +.endm > + > +.macro restore_shared_sysregs > + // x2: base address for cpu context > + // x3: tmp register > + > + add x3, x2, #CPU_SYSREG_OFFSET(TPIDR_EL0) > + > + ldp x4, x5, [x3] > + ldp x6, x7, [x3, #16] > + > + msr tpidr_el0, x4 > + msr tpidrro_el0,x5 > + msr tpidr_el1, x6 > + msr actlr_el1, x7 > +.endm > + > + > .macro save_sysregs > // x2: base address for cpu context > // x3: tmp register > @@ -211,26 +263,27 @@ > > mrs x4, vmpidr_el2 > mrs
Re: [RESEND 2][PATCH v4] hexdump: fix for non-aligned buffers
> On 09 Jul 2015, at 02:03, Andrew Morton wrote: > > On Thu, 9 Jul 2015 01:44:18 +0200 Horacio Mijail Ant__n Quiles > wrote: > >> An hexdump with a buf not aligned to the groupsize causes >> non-naturally-aligned memory accesses. This was causing a kernel panic on >> the processor BlackFin BF527, when such an unaligned buffer was fed by the >> function ubifs_scanned_corruption in fs/ubifs/scan.c . >> >> To fix this, if the buffer is not aligned to groupsize in a platform which >> does not define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, then change the >> groupsize to 1, so alignment is no longer a problem. >> This behavior is coherent with the way the function currently deals with >> inappropriate parameter combinations, which is to fall back to safe >> "defaults", even if that means changing the output format and the implicit >> access patterns that could have been expected. > > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS seems inappropriate for this. > Having this unset means "can do unaligned accesses, but they're > inefficient". It doesn't mean "unaligned accesses go oops". > > But I can't the appropriate config knob. There's a > CONFIG_CPU_HAS_NO_UNALIGNED, but that’s an m68k-private thing. I’m only a newbie, but I will argue that the lesser evil is checking CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS - until a new configure variable is defined. In Documentation/unaligned-memory-access.txt, an undefined CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is taken as if to mean “the hardware isn’t able to access memory on arbitrary boundaries”. And I certainly can’t see any more appropriate CONFIG_* variable. The other alternative in Documentation/unaligned-memory-access.txt is the macro get_unaligned() from asm/unaligned.h. However, using get_unaligned() would mean a much more intrusive patch, since each case of the groupsize would be changed, and anyway we would still need to check CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to avoid penalising everyone. Lastly, as noted on the patch’s description, hex_dump_to_buffer() as it is has no qualms about sanitizing the received parameter values down to conservative values, and so any current callers are already used to having the expected output and the implicit memory access patterns changed. So I’d say that changing the groupsize is not only harmless, but expected. > >> Resent on 8 Jul because of no answers. >> >> Resent on 29 Jun because of no answers. > > During the merge window. So I have everything sitting there in my > patches-to-process pile. The backlog is excessive this time (700+ > emails) so I'm thinking I'll change things so I'll henceforth be > processing patches-for-the-next-cycle during this-cycle, while keeping > patches-for-next-cycle out of linux-next. No problem for me - if I should squelch the next version of this patch for some time, please let me know. > >> --- a/lib/hexdump.c >> +++ b/lib/hexdump.c >> @@ -124,6 +124,11 @@ int hex_dump_to_buffer(const void *buf, size_t len, int >> rowsize, int groupsize, >> if ((len % groupsize) != 0) /* no mixed size output */ >> groupsize = 1; >> >> +/* fall back to 1-byte groups if buf is not aligned to groupsize */ > > That isn't a great comment. It tells us what the code does (which is > quite obvious just from reading it) but it doesn't tell us *why* it > does it. Something like "if buf is not aligned to groupsize then fall > back to 1-byte groups to avoid unaligned memory accesses on > architectures which do not support them”? Thanks, note taken. > > But as mentioned above, that's different from "architectures which do > not support them efficently"! Maybe we need a new config variable. > > Or maybe blackfin should be handling the unaligned access trap and > transparently handling it, like sparc? > I’ll wait for anyone else to weight in… >> +if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && >> +!IS_ALIGNED((uintptr_t)buf, groupsize)) >> +groupsize = 1; >> + >> >> ... >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] nfit: add support for NVDIMM "latch" flag
On Wed, Jul 8, 2015 at 9:00 AM, Ross Zwisler
wrote:
> Add support in the NFIT BLK I/O path for the "latch" flag
> defined in the "Get Block NVDIMM Flags" _DSM function:
>
> http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
>
> This flag requires the driver to read back the command register after it
> is written in the block I/O path. This ensures that the hardware has
> fully processed the new command and moved the aperture appropriately.
>
> Signed-off-by: Ross Zwisler
> Cc: linux-nvd...@lists.01.org
> Cc: linux-a...@vger.kernel.org
> Cc: "Rafael J. Wysocki"
> Cc: Dan Williams
> Cc: Len Brown
> Cc: Christoph Hellwig
> Cc: Jeff Moyer
> Cc: Toshi Kani
> ---
> drivers/acpi/nfit.c | 33 -
> drivers/acpi/nfit.h | 6 ++
> 2 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
> index b3c446412f61..9062c11c1062 100644
> --- a/drivers/acpi/nfit.c
> +++ b/drivers/acpi/nfit.c
> @@ -1059,7 +1059,9 @@ static void write_blk_ctl(struct nfit_blk *nfit_blk,
> unsigned int bw,
>
> writeq(cmd, mmio->base + offset);
> wmb_blk(nfit_blk);
> - /* FIXME: conditionally perform read-back if mandated by firmware */
> +
> + if (nfit_blk->dimm_flags & ND_BLK_DCR_LATCH)
> + readq(mmio->base + offset);
> }
>
> static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk,
> @@ -1258,6 +1260,28 @@ static int nfit_blk_init_interleave(struct
> nfit_blk_mmio *mmio,
> return 0;
> }
>
> +static int acpi_nfit_blk_get_flags(struct nvdimm_bus_descriptor *nd_desc,
> + struct nvdimm *nvdimm, struct nfit_blk *nfit_blk)
> +{
> + struct nd_cmd_dimm_flags flags;
> + int rc;
> +
> + memset(, 0, sizeof(flags));
> + rc = nd_desc->ndctl(nd_desc, nvdimm, ND_CMD_DIMM_FLAGS, ,
> + sizeof(flags));
> +
> + if (rc >= 0) {
> + if (!flags.status)
> + nfit_blk->dimm_flags = flags.flags;
Subjective nit, I tend to prefer the form (flags.status == 0) for
positive cases. (!flags.status) reads like an error handling case to
me.
> + else if (flags.status == ND_DSM_STATUS_NOT_SUPPORTED)
> + nfit_blk->dimm_flags = 0; /* as per the _DSM spec */
The spec says if command is "not implemented", I would treat "not
supported" like any other non-zero flags.status value and return a
failure.
> + else
> + rc = -EINVAL;
s/EINVAL/ENXIO/ as it is a failure to run the command, not necessarily
bad parameters.
> + }
> +
> + return rc;
This ends up treating -ENOTTY as an error when it is really just an
indication that the flags DSM is not implemented. We should return
zero in that case.
> +}
> +
> static int acpi_nfit_blk_region_enable(struct nvdimm_bus *nvdimm_bus,
> struct device *dev)
> {
> @@ -1333,6 +1357,13 @@ static int acpi_nfit_blk_region_enable(struct
> nvdimm_bus *nvdimm_bus,
> return rc;
> }
>
> + rc = acpi_nfit_blk_get_flags(nd_desc, nvdimm, nfit_blk);
> + if (rc < 0) {
> + dev_dbg(dev, "%s: %s failed get DIMM flags\n",
> + __func__, nvdimm_name(nvdimm));
> + return rc;
> + }
> +
> nfit_flush = nfit_mem->nfit_flush;
> if (nfit_flush && nfit_flush->flush->hint_count != 0) {
> struct acpi_nfit_flush_address *flush = nfit_flush->flush;
> diff --git a/drivers/acpi/nfit.h b/drivers/acpi/nfit.h
> index d284729cc37c..98e36ca0dfc2 100644
> --- a/drivers/acpi/nfit.h
> +++ b/drivers/acpi/nfit.h
> @@ -40,6 +40,11 @@ enum nfit_uuids {
> NFIT_UUID_MAX,
> };
>
> +enum {
> + ND_BLK_DCR_LATCH = 2,
> + ND_DSM_STATUS_NOT_SUPPORTED = 1,
Unless it becomes clear that we need this for debug I'd prefer to not
implement the error status flags at this point and just treat non-zero
status flags generically as -ENXIO.
> +};
> +
> struct nfit_spa {
> struct acpi_nfit_system_address *spa;
> struct list_head list;
> @@ -131,6 +136,7 @@ struct nfit_blk {
> u64 stat_offset;
> u64 cmd_offset;
> void __iomem *nvdimm_flush;
> + u32 dimm_flags;
> };
>
> struct nfit_spa_mapping {
> --
> 1.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] acpi-cpufreq: replace per_cpu with driver_data of policy
hi, Rafael thanks for your kind reply. :) On 2015年07月09日 08:20, Rafael J. Wysocki wrote: > On Tuesday, July 07, 2015 08:04:43 PM Viresh Kumar wrote: >> On 07-07-15, 20:43, Pan Xinhui wrote: >>> >>> Drivers can store their internal per-policy information in >>> policy->driver_data, lets use it. >>> >>> we have benefits after this replacing. >>> 1) memory saving. >>> 2) policy is shared by several cpus, per_cpu seems not correct. using >>> *driver_data* is more reasonable. >>> 3) fix a memory leak in acpi_cpufreq_cpu_exit. as policy->cpu might >>> change during cpu hotplug. So sometimes we cant't free *data*, use >>> *driver_data* to fix it. >>> 4) fix a zero return value of get_cur_freq_on_cpu. Only per_cpu of >>> policy->cpu is set to *data*, if we try to get cpufreq on other cpus, we >>> get zero instead of correct values. Use *driver_data* to fix it. >>> >>> Signed-off-by: Pan Xinhui >>> --- >>> Changes from V1: >>> codes style fix, comments update >>> move cpufreq_cpu_put(policy) after we get *driver_data* >>> --- >>> drivers/cpufreq/acpi-cpufreq.c | 40 >>> ++-- >>> 1 file changed, 22 insertions(+), 18 deletions(-) >> >> Acked-by: Viresh Kumar > > OK > > Does it fix any recent regressions or is it just an old bug? > This patch achieve old bug fix and codes improvements. In past days, policy has no field *driver_data*, So acpi-cpufreq driver has to use per_cpu to store some extra information. But it did not take good care of every scenarios. Now cpufreq core makes awesome effort to store more per-policy information in policy. We can make use of this feature. So I cook this patch. :) I am preparing two patches for other two issues in acpi-cpufreq driver based on this patch. I will fix them step by step. :) thanks xinhui > Rafael > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cris: arch-v10: kernel: kgdb: let is_dyn_brkp as extern variable
On 07/07/2015 06:28 AM, Chen Gang wrote: > On 7/6/15 18:31, valdis.kletni...@vt.edu wrote: >> On Mon, 06 Jul 2015 15:49:20 +0800, Chen Gang said: >>> On 07/06/2015 02:25 AM, valdis.kletni...@vt.edu wrote: On Sun, 05 Jul 2015 06:07:54 +0800, Chen Gang said: > For upstream cris toolchain (gcc is 6.0 typo? >>> >>> Do you mean "toolchain" -> "tool chain"? >> >> No, I was wondering where a gcc 6.0 managed to escape when 5.1 just got >> released about 2 weeks ago >> > Oh, sorry, gcc 5.1 is the same, and at present, for me: - The new gcc have additional optimization for the static variables. It should notice about the related c code when optimizing, but gcc has no idea about assembly code (it should passes them to gas, directly). - If one want gcc skip the related optimization, it can use 'volatile' for it (the static variable which may be used by both c code and assembly code in one file). - So I guess, we need add 'volatile' to the related static variable, we do not want to disable this optimization only because of this issue. Welcome any additional ideas, suggestions and completions. > OK, thanks. At present, gcc 6.0 is the latest in master branch. > > After check fedora released toolchain (gcc 4.9.1, binutils 2.25), it has > no issue (support static variable in our case). So this patch can be > dropped, and I shall try: > > - Use the same configuration parameters of fedora released toolchain to >build the upstream latest cross toolchain again, and try. > > - If it still has issue (not support static variable), I shall try to >fix it. > > > Thanks. > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] cris: arch-v10: kernel: kgdb: let is_dyn_brkp as extern variable
On 07/07/2015 06:28 AM, Chen Gang wrote: > On 7/6/15 18:31, valdis.kletni...@vt.edu wrote: >> On Mon, 06 Jul 2015 15:49:20 +0800, Chen Gang said: >>> On 07/06/2015 02:25 AM, valdis.kletni...@vt.edu wrote: On Sun, 05 Jul 2015 06:07:54 +0800, Chen Gang said: > For upstream cris toolchain (gcc is 6.0 typo? >>> >>> Do you mean "toolchain" -> "tool chain"? >> >> No, I was wondering where a gcc 6.0 managed to escape when 5.1 just got >> released about 2 weeks ago >> > Oh, sorry, gcc 5.1 has the same issue, and at present I guess: - The new gcc have additional optimization for the static variables. It should notice about the related c code when optimizing, but gcc has no idea about assembly code (it should passes them to gas, directly). - If one want gcc skip the related optimization, it can use 'volatile' for it (the static variable which may be used by both c code and assembly code in one file). - So for me, we need add 'volatile' to the related static variable, we do not want to disable this optimization only because of this issue. Welcome any additional ideas, suggestions and completions. > OK, thanks. At present, gcc 6.0 is the latest in master branch. > > After check fedora released toolchain (gcc 4.9.1, binutils 2.25), it has > no issue (support static variable in our case). So this patch can be > dropped, and I shall try: > > - Use the same configuration parameters of fedora released toolchain to >build the upstream latest cross toolchain again, and try. > > - If it still has issue (not support static variable), I shall try to >fix it. > > > Thanks. > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] powerpc/smp: use early_cpu_to_node() instead of direct references to numa_cpu_lookup_table
On Thu, 2 Jul 2015, Nishanth Aravamudan wrote: > A simple move to a wrapper function to numa_cpu_lookup_table, now that > power has the early_cpu_to_node() API. > > Signed-off-by: Nishanth Aravamudan When early_cpu_to_node() is __init: Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,1/2] powerpc/numa: fix cpu_to_node() usage during boot
On Wed, 8 Jul 2015, Nishanth Aravamudan wrote: > > It looks like the symptom is that the per-cpu areas are all allocated on > > node > > 0, is that all that goes wrong? > > Yes, that's the symptom. I cc'd a few folks to see if they could help > indicate the performance implications of such a setup -- sorry, I should > have been more explicit about that. > Yeah, not sure it's really a bugfix but rather a performance optimization since cpu_to_node() with CONFIG_USE_PERCPU_NUMA_NODE_ID is only about performance. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] powerpc/numa: fix cpu_to_node() usage during boot
On Thu, 2 Jul 2015, Nishanth Aravamudan wrote:
> Much like on x86, now that powerpc is using USE_PERCPU_NUMA_NODE_ID, we
> have an ordering issue during boot with early calls to cpu_to_node().
> The value returned by those calls now depend on the per-cpu area being
> setup, but that is not guaranteed to be the case during boot. Instead,
> we need to add an early_cpu_to_node() which doesn't use the per-CPU area
> and call that from certain spots that are known to invoke cpu_to_node()
> before the per-CPU areas are not configured.
>
> On an example 2-node NUMA system with the following topology:
>
> available: 2 nodes (0-1)
> node 0 cpus: 0 1 2 3
> node 0 size: 2029 MB
> node 0 free: 1753 MB
> node 1 cpus: 4 5 6 7
> node 1 size: 2045 MB
> node 1 free: 1945 MB
> node distances:
> node 0 1
> 0: 10 40
> 1: 40 10
>
> we currently emit at boot:
>
> [0.00] pcpu-alloc: [0] 0 1 2 3 [0] 4 5 6 7
>
> After this commit, we correctly emit:
>
> [0.00] pcpu-alloc: [0] 0 1 2 3 [1] 4 5 6 7
>
> Signed-off-by: Nishanth Aravamudan
>
> diff --git a/arch/powerpc/include/asm/topology.h
> b/arch/powerpc/include/asm/topology.h
> index 5f1048e..f2c4c89 100644
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -39,6 +39,8 @@ static inline int pcibus_to_node(struct pci_bus *bus)
> extern int __node_distance(int, int);
> #define node_distance(a, b) __node_distance(a, b)
>
> +extern int early_cpu_to_node(int);
> +
> extern void __init dump_numa_cpu_topology(void);
>
> extern int sysfs_add_device_to_node(struct device *dev, int nid);
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index c69671c..23a2cf3 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -715,8 +715,8 @@ void __init setup_arch(char **cmdline_p)
>
> static void * __init pcpu_fc_alloc(unsigned int cpu, size_t size, size_t
> align)
> {
> - return __alloc_bootmem_node(NODE_DATA(cpu_to_node(cpu)), size, align,
> - __pa(MAX_DMA_ADDRESS));
> + return __alloc_bootmem_node(NODE_DATA(early_cpu_to_node(cpu)), size,
> + align, __pa(MAX_DMA_ADDRESS));
> }
>
> static void __init pcpu_fc_free(void *ptr, size_t size)
> @@ -726,7 +726,7 @@ static void __init pcpu_fc_free(void *ptr, size_t size)
>
> static int pcpu_cpu_distance(unsigned int from, unsigned int to)
> {
> - if (cpu_to_node(from) == cpu_to_node(to))
> + if (early_cpu_to_node(from) == early_cpu_to_node(to))
> return LOCAL_DISTANCE;
> else
> return REMOTE_DISTANCE;
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 5e80621..9ffabf4 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -157,6 +157,11 @@ static void map_cpu_to_node(int cpu, int node)
> cpumask_set_cpu(cpu, node_to_cpumask_map[node]);
> }
>
> +int early_cpu_to_node(int cpu)
> +{
> + return numa_cpu_lookup_table[cpu];
> +}
> +
> #if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_PPC_SPLPAR)
> static void unmap_cpu_from_node(unsigned long cpu)
> {
>
>
early_cpu_to_node() looks like it's begging to be __init since we
shouldn't have a need to reference to numa_cpu_lookup_table after boot and
that appears like it can be done if pcpu_cpu_distance() is made __init in
this patch and smp_prepare_boot_cpu() is made __init in the next patch.
So I think this is fine, but those functions and things like
reset_numa_cpu_lookup_table() should be in init.text.
After the percpu areas on initialized and cpu_to_node() is correct, it
would be really nice to be able to make numa_cpu_lookup_table[] be
__initdata since it shouldn't be necessary anymore. That probably has cpu
callbacks that need to be modified to no longer look at
numa_cpu_lookup_table[] or pass the value in, but it would make it much
cleaner. Then nobody will have to worry about figuring out whether
early_cpu_to_node() or cpu_to_node() is the right one to call.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] usb: renesas_usbhs: Allow an OTG PHY driver to provide VBUS
Hi Phil,
On Wednesday 08 July 2015 08:08:27 Phil Edworthy wrote:
> On 08 July 2015 00:08, Laurent wrote:
> > On Tuesday 07 July 2015 12:52:43 Phil Edworthy wrote:
> > > These changes allow a PHY driver to trigger a VBUS interrupt and
> > > to provide the value of VBUS.
> > >
> > > Signed-off-by: Phil Edworthy
> >
> > This looks much better to me. I just have two comments, please see below.
> >
> > > ---
> > >
> > > v5:
> > > - Avoid race when vbus_is_indirect may or may not be read
> > >
> > > before the phy has called vbus_session. In doing so, the
> > > changes have also been isolated to mod_gadget.c
> > >
> > > v4:
> > > - Use true/false with bool vars.
> > > - Clean up "transceiver found" message.
> > >
> > > v3:
> > > - Changed how indirect vbus is plumbed in.
> > > - Removed unnecessary (void) on call to otg_set_peripheral.
> > > - Moved code that connects to bus through transceiver so it
> > >
> > > is before setting gpriv->driver.
> > >
> > > v2:
> > > - vbus variables changed from int to bool.
> > > - dev_info() changed to dev_err()
> > >
> > > ---
> > >
> > > drivers/usb/renesas_usbhs/mod_gadget.c | 62 +++
> > > 1 file changed, 62 insertions(+)
> > >
> > > diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > b/drivers/usb/renesas_usbhs/mod_gadget.c index dc2aa32..19a22a3 100644
> > > --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
[snip]
> > > @@ -882,12 +906,28 @@ static int usbhsg_gadget_start(struct usb_gadget
> > > *gadget,
> > > {
> > > struct usbhsg_gpriv *gpriv = usbhsg_gadget_to_gpriv(gadget);
> > > struct usbhs_priv *priv = usbhsg_gpriv_to_priv(gpriv);
> > > + struct device *dev = usbhs_priv_to_dev(priv);
> > > + int ret;
> > >
> > > if (!driver ||
> > > !driver->setup ||
> > > driver->max_speed < USB_SPEED_FULL)
> > > return -EINVAL;
> > >
> > > + /* connect to bus through transceiver */
> > > + if (!IS_ERR_OR_NULL(gpriv->transceiver)) {
> > > + ret = otg_set_peripheral(gpriv->transceiver->otg,
> > > + >gadget);
> > > + if (ret) {
> > > + dev_err(dev, "%s: can't bind to transceiver\n",
> > > + gpriv->gadget.name);
> > > + return ret;
> > > + }
> > > +
> > > + /* get vbus using phy versions */
> > > + usbhs_mod_phy_mode(priv);
> >
> > Given that the presence of an external PHY is known at probe time,
> > couldn't this call be moved to the probe function ? It would then probably
> > conflict with the usbhs_mod_autonomy_mode() call from usbhs_probe(), which
> > would need to be fixed.
>
> You could do this, but as you say it would conflict with usbhs_probe(). I
> can't see a simple way to check for the external phy connection, so I would
> prefer to keep it here.
> Is that ok?
I can live with that, but I can't help feeling that it's not the best
architecture. Coming to think about it, why do we get the transceiver (by
calling usb_get_phy) in the gadget code ? Isn't the transceiver shared between
host and peripheral modes ? Shouldn't it be handled by core code then ? I
might miss something as my knowledge of the USB subsystem isn't perfect.
If we decide to refactor the code it can be done in a follow-up patch, this
patch has been delayed for long enough.
> > > + }
> > > +
> > >
> > > /* first hook up the driver ... */
> > > gpriv->driver = driver;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_gem_gtt.c
between commit:
00245266b4be ("drm/i915/ppgtt: Break loop in gen8_ppgtt_clear_range failure
path")
from Linus' tree and commit:
567047be2a7e ("drm/i915/gtt: Use macros to access dma mapped pages")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_gem_gtt.c
index dcc6a88c560e,ed65f24867b4..
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@@ -513,10 -583,9 +583,9 @@@ static void gen8_ppgtt_clear_range(stru
while (num_entries) {
struct i915_page_directory *pd;
struct i915_page_table *pt;
- struct page *page_table;
if (WARN_ON(!ppgtt->pdp.page_directory[pdpe]))
- continue;
+ break;
pd = ppgtt->pdp.page_directory[pdpe];
@@@ -525,11 -594,9 +594,9 @@@
pt = pd->page_table[pde];
- if (WARN_ON(!pt->page))
+ if (WARN_ON(!px_page(pt)))
- continue;
+ break;
- page_table = pt->page;
-
last_pte = pte + num_entries;
if (last_pte > GEN8_PTES)
last_pte = GEN8_PTES;
pgpWINygRJk41.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes trees
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commits:
63fef06ada94 ("drm/i915: Check crtc->active in intel_crtc_disable_planes")
dec4f799d0a4 ("drm/i915: Use crtc_state->active in primary check_plane func")
from the drm-intel-fixes tree and commit:
a539205a1628 ("drm/i915: atomic plane updates in a nutshell")
da20eabd2c69 ("drm/i915: Split plane updates of crtc->atomic into a helper,
v2.")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index ba9321998a41,4bcbff9793d4..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4851,25 -4800,13 +4800,16 @@@ static void intel_crtc_disable_planes(s
{
struct drm_device *dev = crtc->dev;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_plane *intel_plane;
+ struct drm_plane *p;
int pipe = intel_crtc->pipe;
+ if (!intel_crtc->active)
+ return;
+
- intel_crtc_wait_for_pending_flips(crtc);
-
- intel_pre_disable_primary(crtc);
-
intel_crtc_dpms_overlay_disable(intel_crtc);
- for_each_intel_plane(dev, intel_plane) {
- if (intel_plane->pipe == pipe) {
- struct drm_crtc *from = intel_plane->base.crtc;
- intel_plane->disable_plane(_plane->base,
- from ?: crtc, true);
- }
- }
+ drm_for_each_plane_mask(p, dev, plane_mask)
+ to_intel_plane(p)->disable_plane(p, crtc);
/*
* FIXME: Once we grow proper nuclear flip support out of this we need
pgpTRdEzT675K.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers
On Wed, Jul 8, 2015 at 5:49 PM, Dmitry Torokhov wrote: > On Wed, Jul 08, 2015 at 05:36:04PM -0700, Dan Williams wrote: >> On Mon, Jul 6, 2015 at 4:40 PM, Dmitry Torokhov >> wrote: >> > On Tue, Jul 07, 2015 at 01:23:15AM +0200, Luis R. Rodriguez wrote: >> >> On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote: >> >> > On Fri, Jul 3, 2015 at 11:30 AM, Luis R. Rodriguez >> >> > wrote: >> >> > > On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote: >> >> > >> On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov >> >> > >> wrote: >> >> > >> > Some devices take a long time when initializing, and not all >> >> > >> > drivers are >> >> > >> > suited to initialize their devices when they are open. For example, >> >> > >> > input drivers need to interrogate their devices in order to publish >> >> > >> > device's capabilities before userspace will open them. When such >> >> > >> > drivers >> >> > >> > are compiled into kernel they may stall entire kernel >> >> > >> > initialization. >> >> > >> > >> >> > >> > This change allows drivers request for their probe functions to be >> >> > >> > called asynchronously during driver and device registration (manual >> >> > >> > binding is still synchronous). Because async_schedule is used to >> >> > >> > perform >> >> > >> > asynchronous calls module loading will still wait for the probing >> >> > >> > to >> >> > >> > complete. >> >> > >> > >> >> > >> > Note that the end goal is to make the probing asynchronous by >> >> > >> > default, >> >> > >> > so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary >> >> > >> > measure that allows us to speed up boot process while we >> >> > >> > validating and >> >> > >> > fixing the rest of the drivers and preparing userspace. >> >> > >> > >> >> > >> > This change is based on earlier patch by "Luis R. Rodriguez" >> >> > >> > >> >> > >> > >> >> > >> > Signed-off-by: Dmitry Torokhov >> >> > >> > --- >> >> > >> > drivers/base/base.h| 1 + >> >> > >> > drivers/base/bus.c | 31 +++--- >> >> > >> > drivers/base/dd.c | 149 >> >> > >> > ++--- >> >> > >> > include/linux/device.h | 28 ++ >> >> > >> > 4 files changed, 182 insertions(+), 27 deletions(-) >> >> > >> >> >> > >> Just noticed this patch. It caught my eye because I had a hard time >> >> > >> getting an open coded implementation of asynchronous probing to work >> >> > >> in the new libnvdimm subsystem. Especially the messy races of >> >> > >> tearing >> >> > >> things down while probing is still in flight. I ended up >> >> > >> implementing >> >> > >> asynchronous device registration which eliminated a lot of complexity >> >> > >> and of course the bugs. In general I tend to think that async >> >> > >> registration is less risky than async probe since it keeps wider >> >> > >> portions of the traditional device model synchronous >> >> > > >> >> > > but its not see -DEFER_PROBE even before async probe. >> >> > >> >> > Except in that case you know probe has been seen by the driver at >> >> > least once. So I see that as less of a surprise, but point taken. >> >> > >> >> > >> and leverages the >> >> > >> fact that the device model is already well prepared for asynchronous >> >> > >> arrival of devices due to hotplug. >> >> > > >> >> > > I think this sounds reasonable, do you have your code upstream or >> >> > > posted? >> >> > >> >> > Yes, see nd_device_register() in drivers/nvdimm/bus.c >> >> >> >> It should be I think rather easy for Dmitry to see if he can convert this >> >> input >> >> driver (not yet upstream) to this API and see if the same issues are >> >> fixed. >> > >> > No, I would rather not as it means we lose error handling on device >> > registration. >> > >> >> I think this is a red herring as I don't see how async probing is any >> better at handling device registration errors. The error is logged >> and "handled" by the fact that a device fails to appear, what other >> action would you take? In fact libnvdimm does detect registration >> failures and reports that in a parent device attribute (at least for a >> region device and their namespace child devices). > > What is libnvdimm behavior if you try to unload a module that tries to > register a device but it failed? Memory leak or crash, right? No, in the case of the "region" driver it is part of the core libnvdimm and it is pinned while any region device is active. But, it is a fair point for a generic facility it would need to consider cases where a driver registers children and then is unloaded. I'll need to think about that one more relative to async probing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv3 0/5] enable migration of driver pages
On Tue, Jul 07, 2015 at 01:36:20PM +0900, Gioh Kim wrote: > From: Gioh Kim > > Hello, > > This series try to enable migration of non-LRU pages, such as driver's page. > > My ARM-based platform occured severe fragmentation problem after long-term > (several days) test. Sometimes even order-3 page allocation failed. It has > memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic > processing > and 20~30 memory is reserved for zram. > > I found that many pages of GPU driver and zram are non-movable pages. So I > reported Minchan Kim, the maintainer of zram, and he made the internal > compaction logic of zram. And I made the internal compaction of GPU driver. > > They reduced some fragmentation but they are not enough effective. > They are activated by its own interface, /sys, so they are not cooperative > with kernel compaction. If there is too much fragmentation and kernel starts > to compaction, zram and GPU driver cannot work with the kernel compaction. > > This patch set combines 5 patches. > > 1. patch 1/5: get inode from anon_inodes > This patch adds new interface to create inode from anon_inodes. > > 2. patch 2/5: framework to isolate/migrate/putback page > Add isolatepage, putbackpage into address_space_operations > and wrapper function to call them > > 3. patch 3/5: apply the framework into balloon driver > The balloon driver is applied into the framework. It gets a inode > from anon_inodes and register operations in the inode. > Any other drivers can register operations via inode like this > to migrate it's pages. > > 4. patch 4/5: compaction/migration call the generic interfaces > Compaction and migration pages call the generic interfaces of the framework, > instead of calling balloon migration directly. > > 5. patch 5/5: remove direct calling of migration of driver pages > Non-lru pages are migrated with lru pages by move_to_new_page(). > > This patch set is tested: > - turn on Ubuntu 14.04 with 1G memory on qemu. > - do kernel building > - after several seconds check more than 512MB is used with free command > - command "balloon 512" in qemu monitor > - check hundreds MB of pages are migrated > > My thanks to Konstantin Khlebnikov for his reviews of the v2 patch set. > Most of the changes were based on his feedback. > > Changes since v2: > - change the name of page type from migratable page into mobile page > - get and lock page to isolate page > - add wrapper interfaces for page->mapping->a_ops->isolate/putback > - leave balloon pages marked as balloon > > This patch-set is based on v4.1 > > Gioh Kim (5): > fs/anon_inodes: new interface to create new inode > mm/compaction: enable mobile-page migration > mm/balloon: apply mobile page migratable into balloon > mm/compaction: call generic migration callbacks > mm: remove direct calling of migration > > drivers/virtio/virtio_balloon.c| 3 ++ > fs/anon_inodes.c | 6 +++ > fs/proc/page.c | 3 ++ > include/linux/anon_inodes.h| 1 + > include/linux/balloon_compaction.h | 15 +-- > include/linux/compaction.h | 76 > ++ > include/linux/fs.h | 2 + > include/linux/page-flags.h | 19 + > include/uapi/linux/kernel-page-flags.h | 1 + > mm/balloon_compaction.c| 71 ++- > mm/compaction.c| 8 ++-- > mm/migrate.c | 24 +++ > 12 files changed, 154 insertions(+), 75 deletions(-) > > -- > 2.1.4 > Acked-by: Rafael Aquini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/asm/entry/64: Clean up entry_64.S
Having failed to bisect, let's look at the trace: On Mon, Jul 6, 2015 at 8:00 AM, Sasha Levin wrote: > [3157054.661763] [ cut here ] > [3157054.662552] kernel BUG at arch/x86/kernel/nmi.c:533! > [3157054.663277] invalid opcode: [#1] PREEMPT SMP KASAN > [3157054.664164] Dumping ftrace buffer: > [3157054.664740](ftrace buffer empty) > [3157054.665274] Modules linked in: > [3157054.665768] CPU: 16 PID: 11446 Comm: trinity-main Not tainted > 4.1.0-next-20150703-sasha-00040-gd868f14-dirty #2292 > [3157054.667203] task: 880408813000 ti: 8803d29c8000 task.ti: > 8803d29c8000 > [3157054.668256] RIP: do_nmi (arch/x86/kernel/nmi.c:533 (discriminator 1)) > [3157054.669378] RSP: 0018:88077800bed8 EFLAGS: 00010006 > [3157054.670141] > == > [3157054.671268] BUG: KASan: out of bounds on stack in > __show_regs+0x7f6/0x940 at addr 88077800be50 I bet that__show_regs interacts poorly with KASan for some reason. But that's not the underlying bug. In fact, the bad read is quite close the RSP, so this is almost certainly a bug in KASan or __show_regs. > [3157054.674604] Read of size 8 by task trinity-main/11446 > [3157054.676521] page:ea001de002c0 count:1 mapcount:0 mapping: > (null) index:0x0 > [3157054.679451] flags: 0x42f8400(reserved) > [3157054.681237] page dumped because: kasan: bad access detected > [3157054.683326] CPU: 16 PID: 11446 Comm: trinity-main Not tainted > 4.1.0-next-20150703-sasha-00040-gd868f14-dirty #2292 > [3157054.687097] 88077800be50 9c65e33f 88077800b9f8 > a0ac8938 > [3157054.690303] 1d4003bc0058 88077800ba88 88077800ba78 > 9759796e > [3157054.693365] 88077800bab8 a0abe0b3 0082 > a2fe39e4 > [3157054.696209] Call Trace: > [3157054.697180] dump_stack (lib/dump_stack.c:52) > [3157054.699390] kasan_report_error (mm/kasan/report.c:132 > mm/kasan/report.c:193) > [3157054.701663] ? printk (kernel/printk/printk.c:1896) > [3157054.703531] ? bitmap_weight (include/linux/bitmap.h:303) > [3157054.705553] __asan_report_load8_noabort (mm/kasan/report.c:230 > mm/kasan/report.c:251) > [3157054.708014] ? __show_regs (arch/x86/kernel/process_64.c:68) > [3157054.710046] __show_regs (arch/x86/kernel/process_64.c:68) > [3157054.712066] ? printk (kernel/printk/printk.c:1896) > [3157054.713878] ? bitmap_weight (include/linux/bitmap.h:303) > [3157054.715875] ? start_thread_common.constprop.0 > (arch/x86/kernel/process_64.c:58) > [3157054.718336] ? dump_stack_print_info (kernel/printk/printk.c:3121) > [3157054.720619] show_regs (arch/x86/kernel/dumpstack_64.c:313) > [3157054.722530] __die (arch/x86/kernel/dumpstack.c:294) > [3157054.724290] die (arch/x86/kernel/dumpstack.c:316) > [3157054.725962] do_trap (arch/x86/kernel/traps.c:214 > arch/x86/kernel/traps.c:260) > [3157054.727805] do_error_trap (arch/x86/kernel/traps.c:298 > include/linux/jump_label.h:125 include/linux/context_tracking_state.h:29 > include/linux/context_tracking.h:46 arch/x86/kernel/traps.c:302) > [3157054.729843] ? do_device_not_available (arch/x86/kernel/traps.c:291) > [3157054.732211] ? do_nmi (arch/x86/kernel/nmi.c:533 (discriminator 1)) > [3157054.734101] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:87 > arch/x86/kernel/kvmclock.c:86) > [3157054.736165] ? sched_clock (arch/x86/kernel/tsc.c:305) > [3157054.738126] ? nmi_handle (arch/x86/kernel/nmi.c:134) > [3157054.740133] ? trace_hardirqs_off_thunk (arch/x86/entry/thunk_64.S:40) > [3157054.742997] do_invalid_op (arch/x86/kernel/traps.c:313) > [3157054.744991] invalid_op (arch/x86/entry/entry_64.S:925) So we got #UD somewhere... > [3157054.746873] ? do_nmi (arch/x86/kernel/nmi.c:533 (discriminator 1)) > [3157054.748769] ? do_nmi (arch/x86/kernel/nmi.c:515 > arch/x86/kernel/nmi.c:531) > [3157054.750658] end_repeat_nmi (arch/x86/entry/entry_64.S:1435) ...here, perhaps? Do you know what line 1435 was in the version you tested? There shouldn't be funny instructions in end_repeat_nmi, though. Did we end up off an instruction boundary? Here's my wild guess. The repeat_nmi thing is really rare. What if there's a CPU or emulator that can't do mov %cr2, %r12 or vice versa? mov from cr has a somewhat unusual encoding. What platform is this? Does KASan play games that would cause KVM to emulate a mov to or from cr2? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers
On Wed, Jul 08, 2015 at 05:54:26PM -0700, Dan Williams wrote: > On Wed, Jul 8, 2015 at 5:52 PM, Dmitry Torokhov > wrote: > > On Wed, Jul 08, 2015 at 05:43:23PM -0700, Dan Williams wrote: > >> On Mon, Jul 6, 2015 at 4:38 PM, Dmitry Torokhov > >> wrote: > >> > On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote: > >> >> The problem I ran into was needing to remove devices that still had > >> >> yet to be probed and not being able to use registration completion vs > >> >> the device_lock() to effectively synchronize the sub-system. > >> > > >> > Why do you need to "synchronize the sub-system"? The asynchronous > >> > probing should be transparent to the driver. Just unregister the device > >> > (or the driver) and driver core will ensure that probe() is not in > >> > flight. > >> > >> Async registration is indeed transparent to the driver. The primary > >> need to "flush registration" is the case of "region" devices that > >> reference a set of NVDIMM devices. A region device requires all > >> related NVDIMMs to be active before the region can be enabled. > > > > Sounds like you need to call into the subsystem to let it know that the > > device is active and activate region devices when they are ready. Could > > be either explicit call or you can try using bus notifiers for > > bind/unbind events. > > > > BTW, do you handle bind/unbind via sysfs (everyone forgets about this > > mechanism)? > > bind/unbind via systs is central to how libnvdimm operates. It's > covered by our unit tests. Ah, excellent then. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 4.2-rc1
On Thu, Jul 9, 2015 at 1:29 AM, Linus Torvalds wrote: > On Wed, Jul 8, 2015 at 10:17 AM, Linus Torvalds > wrote: >> >> Decoding the "Code:" line shows that this is the "->fw_id" dereference in >> >> if (add_uevent_var(env, "FIRMWARE=%s", fw_priv->buf->fw_id)) >> return -ENOMEM; >> >> and that "fw_priv->buf" pointer is NULL. >> >> However, I don't see anything that looks like it should have changed >> any of this since 4.1. > > Looking at the otehr uses of "fw_priv->buf", they all check that > pointer for NULL. I see code like > > fw_buf = fw_priv->buf; > if (!fw_buf) > goto out; > > etc. > > Also, it looks like you need to hold the "fw_lock" to even look at > that pointer, since the buffer can get reallocated etc. Yes, the above code with holding 'fw_lock' is right fix for the issue since sysfs read can happen anytime, and there is one race between firmware request abort and reading uevent of sysfs. > So that uevent code really looks buggy. It just doesn't look like a > *new* bug to me. That code looks old, going back to 2012 and commit > 1244691c73b2. Exactly. Thanks, Ming -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/5] tee: generic TEE subsystem
On Wed, Jul 08, 2015 at 04:52:03PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jul 08, 2015 at 04:28:26PM -0700, Dmitry Torokhov wrote:
> > On Wed, Jul 08, 2015 at 03:33:25PM -0700, Greg Kroah-Hartman wrote:
> > > On Wed, Jul 08, 2015 at 04:26:49PM -0600, Jason Gunthorpe wrote:
> > > > On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
> > > > > > > + cdev_init(>cdev, _fops);
> > > > > > > + teedev->cdev.owner = teedesc->owner;
> > > > > >
> > > > > > This also needs to set teedev->cdev.kobj.parent.
> > > > > > I'm guessing:
> > > > > >
> > > > > > teedev->cdev.kobj.parent = >dev.kobj;
> > > > > >
> > > > > > TPM had the same mistake..
> > > > >
> > > > > Really? As of a few years ago, A cdev's kobject should not be touched
> > > > > by anything other than the cdev core. It's not a "real" kobject in
> > > > > that
> > > > > it is never registered in sysfs, and no one sees it. I keep meaning
> > > > > to
> > > >
> > > > Well, when I looked at it, it looked like it was necessary to maintain
> > > > the refcount on the memory that is holding cdev.
> > > >
> > > > The basic issue is that cdev_del doesn't seem to be synchronizing.
> > > >
> > > > The use after free race is then something like:
> > > >
> > > >struct tpm_chip {
> > > > struct device dev;
> > > > struct cdev cdev;
> > >
> > > Oops, right there's your problem. You can't have two reference counted
> > > objects trying to manage the memory of a single structure. No matter
> > > what you do, it's going to be a pain to deal with this, so don't :)
> > >
> > > >
> > > >CPU0CPU1
> > > > = ==
> > > > tpm_chip = kalloc
> > > > cdev_add(_chip->cdev)
> > > > device_add(_chip->dev)
> > > > chrdev_open
> > > > filp->f_op->open
> > > > cdev_del(_chip->cdev)
> > > > device_unregister
> > > >(_chip->dev)
> > > > kfree(tpm_chip)
> > > > tpm_chip = container_of
> > > > fput
> > > > cdev_put(.. cdev)
> > > >
> > > > Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
> > > > called.
> > >
> > > No, separate them, make the cdev a pointer and all should be fine.
> > >
> > > > > just use something else one of these days for that structure, as lots
> > > > > of
> > > > > people get it wrong. Or has things changed there?
> > > >
> > > > Not recently, but this is the commit:
> > > >
> > > > commit 2f0157f13f42800aa3d9017ebb0fb80a65f7b2de
> > > > Author: Dmitry Torokhov
> > > > Date: Sun Oct 21 17:57:19 2012 -0700
> > > >
> > > > char_dev: pin parent kobject
> > > >
> > > > In certain cases (for example when a cdev structure is embedded into
> > > > another object whose lifetime is controlled by a separate kobject)
> > > > it is
> > > > beneficial to tie lifetime of another object to the lifetime of
> > > > character device so that related object is not freed until after
> > > > char_dev object is freed.
> > > >
> > > > To achieve this let's pin kobject's parent when doing cdev_add() and
> > > > unpin when last reference to cdev structure is being released.
> > > >
> > > > Signed-off-by: Dmitry Torokhov
> > > > Acked-by: Al Viro
> > > > Signed-off-by: Linus Torvalds
> > > >
> > > > It doesn't seem the be the best situation, this is the 3rd time this
> > > > week I've noticed cdev with a kalloc'd struct being used improperly.
> > > >
> > > > Perhaps cdev_init should accept the module and kref parent as an
> > > > argument?
> > >
> > > Oh yeah, that commit :(
> > >
> > > If you know _exactly_ what you are doing, you can get away with this,
> > > but I strongly recommend not doing that. As proof of that, in some new
> > > code I'm working on, I did not do this, just because I'm not smart
> > > enough to ensure it's all working properly...
> >
> > I know you like to allocate everything separately and access it via
> > pointers (ala device_create) but cdevs explicitly allow embedding them
> > into other structures (cdev_init vs cdev_alloc). I do not think there is
> > anything wrong with this, as well as there is nothing wrong in embedding
> > a struct device into other structures, but it does require coordinating
> > lifetime rules and selecting a "master" kobject. I think having
> > cdev_init accept such "master" kobject would bring author's attention to
> > the issue and avoid such mistakes in the future.
>
> Embedding cdevs into other structures is great, I like that. What I
> don't like is having two different reference counts for the same
> structure based on the lifetime rules of two different embedded
> structures. That's a very difficult thing to get right and I would
> argue, is something that should almost never be done.
I think if we stop thinking about
Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers
On Wed, Jul 8, 2015 at 5:52 PM, Dmitry Torokhov wrote: > On Wed, Jul 08, 2015 at 05:43:23PM -0700, Dan Williams wrote: >> On Mon, Jul 6, 2015 at 4:38 PM, Dmitry Torokhov >> wrote: >> > On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote: >> >> The problem I ran into was needing to remove devices that still had >> >> yet to be probed and not being able to use registration completion vs >> >> the device_lock() to effectively synchronize the sub-system. >> > >> > Why do you need to "synchronize the sub-system"? The asynchronous >> > probing should be transparent to the driver. Just unregister the device >> > (or the driver) and driver core will ensure that probe() is not in >> > flight. >> >> Async registration is indeed transparent to the driver. The primary >> need to "flush registration" is the case of "region" devices that >> reference a set of NVDIMM devices. A region device requires all >> related NVDIMMs to be active before the region can be enabled. > > Sounds like you need to call into the subsystem to let it know that the > device is active and activate region devices when they are ready. Could > be either explicit call or you can try using bus notifiers for > bind/unbind events. > > BTW, do you handle bind/unbind via sysfs (everyone forgets about this > mechanism)? bind/unbind via systs is central to how libnvdimm operates. It's covered by our unit tests. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers
On Wed, Jul 08, 2015 at 05:43:23PM -0700, Dan Williams wrote: > On Mon, Jul 6, 2015 at 4:38 PM, Dmitry Torokhov > wrote: > > On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote: > >> The problem I ran into was needing to remove devices that still had > >> yet to be probed and not being able to use registration completion vs > >> the device_lock() to effectively synchronize the sub-system. > > > > Why do you need to "synchronize the sub-system"? The asynchronous > > probing should be transparent to the driver. Just unregister the device > > (or the driver) and driver core will ensure that probe() is not in > > flight. > > Async registration is indeed transparent to the driver. The primary > need to "flush registration" is the case of "region" devices that > reference a set of NVDIMM devices. A region device requires all > related NVDIMMs to be active before the region can be enabled. Sounds like you need to call into the subsystem to let it know that the device is active and activate region devices when they are ready. Could be either explicit call or you can try using bus notifiers for bind/unbind events. BTW, do you handle bind/unbind via sysfs (everyone forgets about this mechanism)? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kthread: export park/unpark facility
Hi,
The kthread park/unpark facility is not used in the kernel, so
one would assume that it's made for kernel modules. This patch should
definitely help most modules.
Patch untested, at your own risks...
Regards,
Jean
Signed-off-by: Jean Tourrilhes
diff -u -p linux-3.18.17/kernel/kthread.j2.c linux-3.18.17/kernel/kthread.c
--- linux-3.18.17/kernel/kthread.j2.c 2015-07-08 17:01:39.010554169 -0700
+++ linux-3.18.17/kernel/kthread.c 2015-07-08 17:09:13.016096189 -0700
@@ -97,6 +97,7 @@ bool kthread_should_park(void)
{
return test_bit(KTHREAD_SHOULD_PARK, _kthread(current)->flags);
}
+EXPORT_SYMBOL(kthread_should_park);
/**
* kthread_freezable_should_stop - should this freezable kthread return now?
@@ -171,6 +172,7 @@ void kthread_parkme(void)
{
__kthread_parkme(to_kthread(current));
}
+EXPORT_SYMBOL(kthread_parkme);
static int kthread(void *_create)
{
@@ -411,6 +413,7 @@ void kthread_unpark(struct task_struct *
if (kthread)
__kthread_unpark(k, kthread);
}
+EXPORT_SYMBOL(kthread_unpark);
/**
* kthread_park - park a thread created by kthread_create().
@@ -441,6 +444,7 @@ int kthread_park(struct task_struct *k)
}
return ret;
}
+EXPORT_SYMBOL(kthread_park);
/**
* kthread_stop - stop a thread created by kthread_create().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers
On Wed, Jul 08, 2015 at 05:36:04PM -0700, Dan Williams wrote: > On Mon, Jul 6, 2015 at 4:40 PM, Dmitry Torokhov > wrote: > > On Tue, Jul 07, 2015 at 01:23:15AM +0200, Luis R. Rodriguez wrote: > >> On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote: > >> > On Fri, Jul 3, 2015 at 11:30 AM, Luis R. Rodriguez > >> > wrote: > >> > > On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote: > >> > >> On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov > >> > >> wrote: > >> > >> > Some devices take a long time when initializing, and not all > >> > >> > drivers are > >> > >> > suited to initialize their devices when they are open. For example, > >> > >> > input drivers need to interrogate their devices in order to publish > >> > >> > device's capabilities before userspace will open them. When such > >> > >> > drivers > >> > >> > are compiled into kernel they may stall entire kernel > >> > >> > initialization. > >> > >> > > >> > >> > This change allows drivers request for their probe functions to be > >> > >> > called asynchronously during driver and device registration (manual > >> > >> > binding is still synchronous). Because async_schedule is used to > >> > >> > perform > >> > >> > asynchronous calls module loading will still wait for the probing to > >> > >> > complete. > >> > >> > > >> > >> > Note that the end goal is to make the probing asynchronous by > >> > >> > default, > >> > >> > so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary > >> > >> > measure that allows us to speed up boot process while we validating > >> > >> > and > >> > >> > fixing the rest of the drivers and preparing userspace. > >> > >> > > >> > >> > This change is based on earlier patch by "Luis R. Rodriguez" > >> > >> > > >> > >> > > >> > >> > Signed-off-by: Dmitry Torokhov > >> > >> > --- > >> > >> > drivers/base/base.h| 1 + > >> > >> > drivers/base/bus.c | 31 +++--- > >> > >> > drivers/base/dd.c | 149 > >> > >> > ++--- > >> > >> > include/linux/device.h | 28 ++ > >> > >> > 4 files changed, 182 insertions(+), 27 deletions(-) > >> > >> > >> > >> Just noticed this patch. It caught my eye because I had a hard time > >> > >> getting an open coded implementation of asynchronous probing to work > >> > >> in the new libnvdimm subsystem. Especially the messy races of tearing > >> > >> things down while probing is still in flight. I ended up implementing > >> > >> asynchronous device registration which eliminated a lot of complexity > >> > >> and of course the bugs. In general I tend to think that async > >> > >> registration is less risky than async probe since it keeps wider > >> > >> portions of the traditional device model synchronous > >> > > > >> > > but its not see -DEFER_PROBE even before async probe. > >> > > >> > Except in that case you know probe has been seen by the driver at > >> > least once. So I see that as less of a surprise, but point taken. > >> > > >> > >> and leverages the > >> > >> fact that the device model is already well prepared for asynchronous > >> > >> arrival of devices due to hotplug. > >> > > > >> > > I think this sounds reasonable, do you have your code upstream or > >> > > posted? > >> > > >> > Yes, see nd_device_register() in drivers/nvdimm/bus.c > >> > >> It should be I think rather easy for Dmitry to see if he can convert this > >> input > >> driver (not yet upstream) to this API and see if the same issues are fixed. > > > > No, I would rather not as it means we lose error handling on device > > registration. > > > > I think this is a red herring as I don't see how async probing is any > better at handling device registration errors. The error is logged > and "handled" by the fact that a device fails to appear, what other > action would you take? In fact libnvdimm does detect registration > failures and reports that in a parent device attribute (at least for a > region device and their namespace child devices). What is libnvdimm behavior if you try to unload a module that tries to register a device but it failed? Memory leak or crash, right? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
