Re: kexec on panic
On 2017-02-18 09:42, Jon Masters wrote:
Hi Denys,
On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote:
After years of using kexec and recent unpleasant experience with
modern (supposed to be blazing fast to boot) hardware that need 5-10
minutes just to pass POST tests,
one question came up to me:
Is it possible anyhow to execute regular (not special "panic" one to
capture crash data) kexec on panic to reduce reboot time?
Generally, you don't want to do this, because various platform hardware
might be in non-quiescent states (still doing DMA to random memory,
etc.)
and other nastiness that means you don't want to do more than the
minimal
amount in a kexec on panic (crash). We've seen no end of fun and games
even with just regular crash dumps while hardware is busily writing to
memory that it shouldn't be. An IOMMU helps, but isn't a cure-all.
Jon.
Well, i have to try, even sometimes i am facing issues with non-booting
hardware even on regular kexec, but having at small customer HP server
that need almost 6 minutes to boot,
no hot-spare(and hard to do by many reasons, no spare 10G ports, cost of
hardware and etc) and some nasty bugs that is not resolved yet - forcing
me to search way to reduce reboot time.
If i will find way to save backtrace and reboot fast, it will help a lot
to debug kernels with minimal downtime, if bug is reproducible only on
live system.
What i did now, might be insanely wrong, but:
diff -Naur linux-4.9.9-vanilla/kernel/kexec_core.c
linux-4.9.9/kernel/kexec_core.c
--- linux-4.9.9-vanilla/kernel/kexec_core.c 2017-02-09
07:08:40.0 +
+++ linux-4.9.9/kernel/kexec_core.c 2017-02-17 12:54:49.0 +
@@ -897,6 +897,10 @@
machine_crash_shutdown(&fixed_regs);
machine_kexec(kexec_crash_image);
}
+ if (kexec_image) {
+ machine_shutdown();
+ machine_kexec(kexec_image);
+ }
mutex_unlock(&kexec_mutex);
}
}
Then
kexec -l /mnt/flash/kernel --append="intel_idle.max_cstate=0
processor.max_cstate=1"
and
echo c >/proc/sysrq-trigger
worked even on busy network router, but i'm not sure it will be same on
real networking stack crash.
Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
Hi Dmitry, On Fri, 17 Feb 2017 12:40:41 -0800 Dmitry Torokhov wrote: [...] > > Let me cite myself: > > > > >> This makes it possible to pre-calibrate the touch so that is > > >> (almost) > > Yes, it allows you to pre-calibrate, I get it. But you still do > properly calibrate later, right? So you are doing double work here, > once in kernel, and second time in userspace. > I as a daily user of that tsc2007 patch series say that I had never the wish to calibrate it later in a better way. I am doing console work with a virtual keyboard on it. So it is rarely double work here. Regards, Andreas pgp0dCtMHdU3C.pgp Description: OpenPGP digital signature
[PATCH] soc: ti: knav_dma: Fix some error handling
'pktdma_get_regs()' never returns NULL. It returns an error pointer or a
valid pointer.
So test its return value with IS_ERR.
Signed-off-by: Christophe JAILLET
---
After checking with IS_ERR, it could be better to propagate the error code
instead of returning -ENODEV uncondionnaly
---
drivers/soc/ti/knav_dma.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index ecebe2eecc3a..3272b379bfcd 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -649,7 +649,7 @@ static int dma_init(struct device_node *cloud, struct
device_node *dma_node)
}
dma->reg_global = pktdma_get_regs(dma, node, 0, &size);
- if (!dma->reg_global)
+ if (IS_ERR(dma->reg_global))
return -ENODEV;
if (size < sizeof(struct reg_global)) {
dev_err(kdev->dev, "bad size %pa for global regs\n", &size);
@@ -657,22 +657,22 @@ static int dma_init(struct device_node *cloud, struct
device_node *dma_node)
}
dma->reg_tx_chan = pktdma_get_regs(dma, node, 1, &size);
- if (!dma->reg_tx_chan)
+ if (IS_ERR(dma->reg_tx_chan))
return -ENODEV;
max_tx_chan = size / sizeof(struct reg_chan);
dma->reg_rx_chan = pktdma_get_regs(dma, node, 2, &size);
- if (!dma->reg_rx_chan)
+ if (IS_ERR(dma->reg_rx_chan))
return -ENODEV;
max_rx_chan = size / sizeof(struct reg_chan);
dma->reg_tx_sched = pktdma_get_regs(dma, node, 3, &size);
- if (!dma->reg_tx_sched)
+ if (IS_ERR(dma->reg_tx_sched))
return -ENODEV;
max_tx_sched = size / sizeof(struct reg_tx_sched);
dma->reg_rx_flow = pktdma_get_regs(dma, node, 4, &size);
- if (!dma->reg_rx_flow)
+ if (IS_ERR(ma->reg_rx_flow))
return -ENODEV;
max_rx_flow = size / sizeof(struct reg_rx_flow);
--
2.9.3
[RESEND 2] [PATCH] rlimits: Print more information when limits are exceeded
This dumps some information in logs when a process exceeds its CPU or RT
limits (soft and hard). Makes debugging easier when userspace triggers
these limits.
Signed-off-by: Arun Raghavan
---
kernel/time/posix-cpu-timers.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
Hello,
This has come up a couple of times in the past, but we haven't been able to
resolve whatever issues were pointed out.
In the mean time, we have frustrated users who don't know where they're getting
a SIGKILL from, and I'd really like to have a way for people to not have to go
through this.
The issues that came up the last time were:
1. SIGXCPU messages shouldn't be needed since they can be caught: it's still
useful to have the log because it isn't always possible to pin down the
thread causing the problem in userspace.
2. SIGKILL logging should be centralised: there seem to be multiple paths that
trigger a SIGKILL -- and it seemed a bit ugly to try to add a reason
parameter on all of them for the KILL case. Any other suggestions on how to
deal with this?
I'm happy to fix this up to actually make it this time, but if there aren't
none, just pushing this out will make our lives a little less painful.
Thanks,
Arun
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index e9e8c10..6dbcf84 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -860,6 +860,9 @@ static void check_thread_timers(struct task_struct *tsk,
* At the hard limit, we just die.
* No need to calculate anything else now.
*/
+ printk(KERN_INFO
+ "CPU Watchdog Timeout (hard): %s[%d]\n",
+ tsk->comm, task_pid_nr(tsk));
__group_send_sig_info(SIGKILL, SEND_SIG_PRIV, tsk);
return;
}
@@ -872,7 +875,7 @@ static void check_thread_timers(struct task_struct *tsk,
sig->rlim[RLIMIT_RTTIME].rlim_cur = soft;
}
printk(KERN_INFO
- "RT Watchdog Timeout: %s[%d]\n",
+ "RT Watchdog Timeout (soft): %s[%d]\n",
tsk->comm, task_pid_nr(tsk));
__group_send_sig_info(SIGXCPU, SEND_SIG_PRIV, tsk);
}
@@ -980,6 +983,9 @@ static void check_process_timers(struct task_struct *tsk,
* At the hard limit, we just die.
* No need to calculate anything else now.
*/
+ printk(KERN_INFO
+ "RT Watchdog Timeout (hard): %s[%d]\n",
+ tsk->comm, task_pid_nr(tsk));
__group_send_sig_info(SIGKILL, SEND_SIG_PRIV, tsk);
return;
}
@@ -987,6 +993,9 @@ static void check_process_timers(struct task_struct *tsk,
/*
* At the soft limit, send a SIGXCPU every second.
*/
+ printk(KERN_INFO
+ "CPU Watchdog Timeout (soft): %s[%d]\n",
+ tsk->comm, task_pid_nr(tsk));
__group_send_sig_info(SIGXCPU, SEND_SIG_PRIV, tsk);
if (soft < hard) {
soft++;
--
2.9.3
[PATCH] irqchip/qcom: Fix error handling
'devm_ioremap()' returns NULL on error, not an error pointer.
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Christophe JAILLET
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/qcom-irq-combiner.c
b/drivers/irqchip/qcom-irq-combiner.c
index 03251da95397..226558698344 100644
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -202,9 +202,9 @@ static acpi_status get_registers_cb(struct acpi_resource
*ares, void *context)
}
vaddr = devm_ioremap(ctx->dev, reg->address, REG_SIZE);
- if (IS_ERR(vaddr)) {
+ if (!vaddr) {
dev_err(ctx->dev, "Can't map register @%pa\n", &paddr);
- ctx->err = PTR_ERR(vaddr);
+ ctx->err = -ENOMEM;
return AE_ERROR;
}
--
2.9.3
Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot
On Thu 2017-02-16 12:21:13, Linus Torvalds wrote: > On Thu, Feb 16, 2017 at 12:06 PM, Pavel Machek wrote: > > > > Hmm, that would explain problems at boot _and_ problems during > > suspend/resume. > > I've committed the revert, and I'm just assuming that the revert also > fixed your suspend/resume issues, but I wanted to just double-check > that since it's only implied, no staed explicitly.. So boot issue is fixed, but it hung on resume, again. v4.9 worked ok. Display is restored when it hangs on resume, but mouse is dead; I guess that means there should be some chance to get debugging messages during the resume. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: kexec on panic
Hi Denys, On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote: > After years of using kexec and recent unpleasant experience with modern > (supposed to be blazing fast to boot) hardware that need 5-10 minutes just to > pass POST tests, > one question came up to me: > Is it possible anyhow to execute regular (not special "panic" one to capture > crash data) kexec on panic to reduce reboot time? Generally, you don't want to do this, because various platform hardware might be in non-quiescent states (still doing DMA to random memory, etc.) and other nastiness that means you don't want to do more than the minimal amount in a kexec on panic (crash). We've seen no end of fun and games even with just regular crash dumps while hardware is busily writing to memory that it shouldn't be. An IOMMU helps, but isn't a cure-all. Jon.
Re: [PATCH v2 3/3] Make vmbus register arguments read-only
Hi Eddie, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc8 next-20170217] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Eddie-Kovsky/provide-check-for-ro_after_init-memory-sections/20170218-141040 config: x86_64-rhel (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >> ERROR: "kernel_ro_address" [drivers/hv/hv_vmbus.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH][RFC v4] ACPI throttling: Disable the MSR T-state if enabled after resumed
On Fri 2017-02-17 16:27:30, Chen Yu wrote:
> Previously a bug was reported that on certain Broadwell
> platform, after resumed from S3, the CPU is running at
> an anomalously low speed, due to the BIOS has enabled the
> MSR throttling across S3. The solution to this was to introduce
> a quirk framework to save/restore tstate MSR register around
> suspend/resume, in Commit 7a9c2dd08ead ("x86/pm:
> Introduce quirk framework to save/restore extra MSR
> registers around suspend/resume").
>
> However there are still three problems left:
> 1. More and more reports show that other platforms also
>encountered the same issue, so the quirk list might
>be endless.
> 2. Each CPUs should take the save/restore operation into
>consideration, rather than the boot CPU alone.
> 3. Normally ACPI T-state re-evaluation is done on resume,
>however there is no _TSS on the bogus platform, thus
>above re-evaluation code does not run on that machine.
>
> Solution:
> This patch is based on the fact that, we generally should not
> expect the system to come back from resume with throttling
> enabled, but leverage the OS components to deal with it,
> such as thermal event. So we simply clear the MSR T-state
> and print the warning if it is found to be enabled after
> resumed back. Besides, we can remove the quirk in previous patch
> later.
What if the machine _is_ hot?
> +static int acpi_throttling_init_ops(void)
> +{
> + /*
> + * Reevaluate on boot CPU. Since it is not always CPU0,
> + * we can not invoke throttling_msr_reevaluate(0) directly.
> + */
Boot cpu is not cpu#0? How can that be?
Should we introduce generic framework to "fix" all the cpus? Actually,
should this be done right on cpu hotplug?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
Hi! > > Well, there is some historic confusion wether this driver reports resistance > > or pressure. > > > > The unpatched tsc2007 driver does it wrong (please test!) and we fix it on > > the fly (because a separate patch is much more complex than doing it right > > immediately). > > > > This ti,report-resistance property is a means to get the old (wrong) > > meaning back > > in case someone urgently needs it and can't fix the user-space workaround > > which > > he must be using. > > > > > > AFAIK there is no mainline board using the DT except ours (and the upcoming > > OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove > > this > > compatibility property. We don't need it for our devices. N900 is mainline and uses DT. > > That the function name is wrong is a second issue and this double negation > > might > > confuse a litte. > > > > Please test on a real device if the patched driver reports pressure now > > (unless > > ti,report-resistance is specified). > > I unfortunately can not test this driver as I do not have the hardware. > So all my observations are from code and data sheets. > > That said, what is the values emitted as ABS_PRESSURE when finger is not > touching the device, barely touching the device, or pressing firmly? > It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have > confusion as to what is being reported. > > I am adding a few more folks to the CC so we can try and soft this out. > Sebastian, Pali, Pavel, any input here? X work ok on N900. Nikolaus wrote rather long email, but I'm not what the meaning is and what is supposed to be broken there. I do this on X startup: xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation Matrix" 1.10 0.00 -0.05 0.00 1.18 -0.10 0.00 0.00 1.00 xinput --set-prop --type=int "TSC200X touchscreen" "Evdev Axis Inversion" 0 1 xinput --set-prop --type=float "TSC2005 touchscreen" "Coordinate Transformation Matrix" 1\ .10 0.00 -0.05 0.00 1.18 -0.10 0.00 0.00 1.00 xinput --set-prop --type=int "TSC2005 touchscreen" "Evdev Axis Inversion" 0 1 And I agree that kernel should _not_ attempt rescaling itself, as it would lose precision. Providing default calibration info is ok. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH trivial 3/4] drm/amd: Spelling s/SDMA_WRTIE_SUB_OPCODE_TILED/SDMA_WRITE_SUB_OPCODE_TILED/
Am 17.02.2017 um 16:36 schrieb Geert Uytterhoeven: Signed-off-by: Geert Uytterhoeven Cc: Alex Deucher Cc: Christian König Cc: dri-devel@lists.freedesktop.orgamd-...@lists.freedesktop.org Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/cikd.h | 2 +- drivers/gpu/drm/radeon/cikd.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/cikd.h b/drivers/gpu/drm/amd/amdgpu/cikd.h index 6cbd913fd12ed6f9..6a9e38a3d2a0bbee 100644 --- a/drivers/gpu/drm/amd/amdgpu/cikd.h +++ b/drivers/gpu/drm/amd/amdgpu/cikd.h @@ -502,7 +502,7 @@ # define SDMA_COPY_SUB_OPCODE_T2T_SUB_WINDOW6 #define SDMA_OPCODE_WRITE 2 # define SDMA_WRITE_SUB_OPCODE_LINEAR 0 -# define SDMA_WRTIE_SUB_OPCODE_TILED1 +# define SDMA_WRITE_SUB_OPCODE_TILED1 #define SDMA_OPCODE_INDIRECT_BUFFER 4 #define SDMA_OPCODE_FENCE 5 #define SDMA_OPCODE_TRAP 6 diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h index 48db93577c1dacad..e21015475ed52f31 100644 --- a/drivers/gpu/drm/radeon/cikd.h +++ b/drivers/gpu/drm/radeon/cikd.h @@ -2016,7 +2016,7 @@ # define SDMA_COPY_SUB_OPCODE_T2T_SUB_WINDOW6 #define SDMA_OPCODE_WRITE 2 # define SDMA_WRITE_SUB_OPCODE_LINEAR 0 -# define SDMA_WRTIE_SUB_OPCODE_TILED1 +# define SDMA_WRITE_SUB_OPCODE_TILED1 #define SDMA_OPCODE_INDIRECT_BUFFER 4 #define SDMA_OPCODE_FENCE 5 #define SDMA_OPCODE_TRAP 6
Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR
On Fri, Feb 17, 2017 at 12:02:13PM -0800, Linus Torvalds wrote:
> I also get he feeling that the whole thing is unnecessary. I'm
> wondering if we should just instead say that the whole 47 vs 56-bit
> virtual address is _purely_ about "get_unmapped_area()", and nothing
> else.
>
> IOW, I'm wondering if we can't just say that
>
> - if the processor and kernel support 56-bit user address space, then
> you can *always* use the whole space
>
> - but by default, get_unmapped_area() will only return mappings that
> fit in the 47 bit address space.
>
> So if you use MAP_FIXED and give an address in the high range, it will
> just always work, and the MM will always consider the task size to be
> the full address space.
>
> But for the common case where a process does no use MAP_FIXED, the
> kernel will never give a high address by default, and you have to do
> the process control thing to say "I want those high addresses".
>
> Hmm?
>
> In other words, I'd like to at least start out trying to keep the
> differences between the 47-bit and 56-bit models as simple and minimal
> as possible. Not make such a big deal out of it.
>
> We already have "arch_get_unmapped_area()" that controls the whole
> "what will non-MAP_FIXED mmap allocations return", so I'd hope that
> the above kind of semantics could be done without *any* actual
> TASK_SIZE changes _anywhere_ in the VM code.
>
> Comments?
Okay, below is my try on implementing this.
I've chosen to respect hint address even without MAP_FIXED, but only if
it doesn't collide with other mappings. Otherwise, fallback to look for
unmapped area within 47-bit window.
Interaction with MPX would requires more work. I'm not yet sure what is the
right way to address it.
Also Dave noticed that some test-cases from ltp would break with the
approach. See for instance hugemmap03. I don't think it matter much as it
tests for negative outcome and I don't expect real world application to do
anything like this.
Test-case that I used to test the patch:
#include
#include
#define SIZE (2UL << 20)
#define LOW_ADDR ((void *) (1UL << 30))
#define HIGH_ADDR ((void *) (1UL << 50))
int main(int argc, char **argv)
{
void *p;
p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
printf("mmap(NULL): %p\n", p);
p = mmap(LOW_ADDR, SIZE, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
printf("mmap(%p): %p\n", LOW_ADDR, p);
p = mmap(HIGH_ADDR, SIZE, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
printf("mmap(%p): %p\n", HIGH_ADDR, p);
p = mmap(HIGH_ADDR, SIZE, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
printf("mmap(%p) again: %p\n", HIGH_ADDR, p);
p = mmap(HIGH_ADDR, SIZE, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
printf("mmap(%p, MAP_FIXED): %p\n", HIGH_ADDR, p);
return 0;
}
8<---
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index e7f155c3045e..9c6315d9aa34 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -250,7 +250,7 @@ extern int force_personality32;
the loader. We need to make sure that it is out of the way of the program
that it will "exec", and that there is sufficient room for the brk. */
-#define ELF_ET_DYN_BASE(TASK_SIZE / 3 * 2)
+#define ELF_ET_DYN_BASE(DEFAULT_MAP_WINDOW / 3 * 2)
/* This yields a mask that user programs can use to figure out what
instruction set this CPU supports. This could be done in user space,
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index e6cfe7ba2d65..492548c87cb1 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -789,6 +789,7 @@ static inline void spin_lock_prefetch(const void *x)
*/
#define TASK_SIZE PAGE_OFFSET
#define TASK_SIZE_MAX TASK_SIZE
+#define DEFAULT_MAP_WINDOW TASK_SIZE
#define STACK_TOP TASK_SIZE
#define STACK_TOP_MAX STACK_TOP
@@ -828,7 +829,9 @@ static inline void spin_lock_prefetch(const void *x)
* particular problem by preventing anything from being mapped
* at the maximum canonical address.
*/
-#define TASK_SIZE_MAX ((1UL << 47) - PAGE_SIZE)
+#define TASK_SIZE_MAX ((1UL << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)
+
+#define DEFAULT_MAP_WINDOW ((1UL << 47) - PAGE_SIZE)
/* This decides where the kernel will search for a free chunk of vm
* space during mmap's.
@@ -841,7 +844,7 @@ static inline void spin_lock_prefetch(const voi
[tip:irq/core] irqchip/qcom: Fix error handling
Commit-ID: 569293c9ca9c5b9b5f7fa3c314ffceafc62957a8
Gitweb: http://git.kernel.org/tip/569293c9ca9c5b9b5f7fa3c314ffceafc62957a8
Author: Christophe JAILLET
AuthorDate: Sat, 18 Feb 2017 09:34:34 +0100
Committer: Thomas Gleixner
CommitDate: Sat, 18 Feb 2017 10:19:07 +0100
irqchip/qcom: Fix error handling
'devm_ioremap()' returns NULL on error, not an error pointer.
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Christophe JAILLET
Cc: marc.zyng...@arm.com
Cc: kernel-janit...@vger.kernel.org
Cc: ja...@lakedaemon.net
Link:
http://lkml.kernel.org/r/20170218083434.2289-1-christophe.jail...@wanadoo.fr
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/qcom-irq-combiner.c
b/drivers/irqchip/qcom-irq-combiner.c
index 03251da..2265586 100644
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -202,9 +202,9 @@ static acpi_status get_registers_cb(struct acpi_resource
*ares, void *context)
}
vaddr = devm_ioremap(ctx->dev, reg->address, REG_SIZE);
- if (IS_ERR(vaddr)) {
+ if (!vaddr) {
dev_err(ctx->dev, "Can't map register @%pa\n", &paddr);
- ctx->err = PTR_ERR(vaddr);
+ ctx->err = -ENOMEM;
return AE_ERROR;
}
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates
On Fri, Feb 17, 2017 at 05:12:44PM -0800, Steve Longerbeam wrote: > Hi Russell, > > I signed-off on this but after more review I'm not sure this is right. > > The CSI-2 receiver really has no control over frame rate. It's output > frame rate is the same as the rate that is delivered to it. > > So this subdev should either not implement these ops, or it should > refer them to the attached source subdev. Where in the V4L2 documentation does it say that is permissible? If you don't implement these, media-ctl fails to propagate _anything_ to the next sink pad if you specify a frame rate, because media-ctl throws an error and exits immediately. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH] Staging: xgifb:XGI_main_26: Fixed coding style issues
Fixed coding style issues. Patch applies to linux-next-20170217 tree.
Signed-off-by: Georgios Emmanouil
---
drivers/staging/xgifb/XGI_main_26.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/xgifb/XGI_main_26.c
b/drivers/staging/xgifb/XGI_main_26.c
index 6930f7e..1be0343 100644
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@ -1480,9 +1480,9 @@ static void XGIfb_detect_VB(struct xgifb_video_info
*xgifb_info)
cr32 = xgifb_reg_get(XGICR, IND_XGI_SCRATCH_REG_CR32);
- if ((cr32 & SIS_CRT1) && !XGIfb_crt1off)
+ if ((cr32 & SIS_CRT1) && !XGIfb_crt1off) {
XGIfb_crt1off = 0;
- else {
+ } else {
if (cr32 & 0x5F)
XGIfb_crt1off = 1;
else
@@ -1500,18 +1500,19 @@ static void XGIfb_detect_VB(struct xgifb_video_info
*xgifb_info)
xgifb_info->display2 = XGIFB_DISP_NONE;
}
- if (XGIfb_tvplug != -1)
+ if (XGIfb_tvplug != -1) {
/* Override with option */
xgifb_info->TV_plug = XGIfb_tvplug;
- else if (cr32 & SIS_VB_HIVISION) {
+ } else if (cr32 & SIS_VB_HIVISION) {
xgifb_info->TV_type = TVMODE_HIVISION;
xgifb_info->TV_plug = TVPLUG_SVIDEO;
- } else if (cr32 & SIS_VB_SVIDEO)
+ } else if (cr32 & SIS_VB_SVIDEO) {
xgifb_info->TV_plug = TVPLUG_SVIDEO;
- else if (cr32 & SIS_VB_COMPOSITE)
+ } else if (cr32 & SIS_VB_COMPOSITE) {
xgifb_info->TV_plug = TVPLUG_COMPOSITE;
- else if (cr32 & SIS_VB_SCART)
+ } else if (cr32 & SIS_VB_SCART) {
xgifb_info->TV_plug = TVPLUG_SCART;
+ }
if (xgifb_info->TV_type == 0) {
temp = xgifb_reg_get(XGICR, 0x38);
--
2.1.4
[GIT pull] timer fixes for 4.10
Linus,
please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
Two small fixes::
- Prevent deadlock on the tick broadcast lock. Found and fixed by Mike.
- Stop using printk() in the timekeeping debug code to prevent a deadlock
against the scheduler.
Thanks,
tglx
-->
Mike Galbraith (1):
tick/broadcast: Prevent deadlock on tick_broadcast_lock
Sergey Senozhatsky (1):
timekeeping: Use deferred printk() in debug code
kernel/time/tick-broadcast.c| 15 +++
kernel/time/timekeeping_debug.c | 4 ++--
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 3109204c87cc..17ac99b60ee5 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -347,17 +347,16 @@ static void tick_handle_periodic_broadcast(struct
clock_event_device *dev)
*
* Called when the system enters a state where affected tick devices
* might stop. Note: TICK_BROADCAST_FORCE cannot be undone.
- *
- * Called with interrupts disabled, so clockevents_lock is not
- * required here because the local clock event device cannot go away
- * under us.
*/
void tick_broadcast_control(enum tick_broadcast_mode mode)
{
struct clock_event_device *bc, *dev;
struct tick_device *td;
int cpu, bc_stopped;
+ unsigned long flags;
+ /* Protects also the local clockevent device. */
+ raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
td = this_cpu_ptr(&tick_cpu_device);
dev = td->evtdev;
@@ -365,12 +364,11 @@ void tick_broadcast_control(enum tick_broadcast_mode mode)
* Is the device not affected by the powerstate ?
*/
if (!dev || !(dev->features & CLOCK_EVT_FEAT_C3STOP))
- return;
+ goto out;
if (!tick_device_is_functional(dev))
- return;
+ goto out;
- raw_spin_lock(&tick_broadcast_lock);
cpu = smp_processor_id();
bc = tick_broadcast_device.evtdev;
bc_stopped = cpumask_empty(tick_broadcast_mask);
@@ -420,7 +418,8 @@ void tick_broadcast_control(enum tick_broadcast_mode mode)
tick_broadcast_setup_oneshot(bc);
}
}
- raw_spin_unlock(&tick_broadcast_lock);
+out:
+ raw_spin_unlock_irqrestore(&tick_broadcast_lock, flags);
}
EXPORT_SYMBOL_GPL(tick_broadcast_control);
diff --git a/kernel/time/timekeeping_debug.c b/kernel/time/timekeeping_debug.c
index ca9fb800336b..38bc4d2208e8 100644
--- a/kernel/time/timekeeping_debug.c
+++ b/kernel/time/timekeeping_debug.c
@@ -75,7 +75,7 @@ void tk_debug_account_sleep_time(struct timespec64 *t)
int bin = min(fls(t->tv_sec), NUM_BINS-1);
sleep_time_bin[bin]++;
- pr_info("Suspended for %lld.%03lu seconds\n", (s64)t->tv_sec,
- t->tv_nsec / NSEC_PER_MSEC);
+ printk_deferred(KERN_INFO "Suspended for %lld.%03lu seconds\n",
+ (s64)t->tv_sec, t->tv_nsec / NSEC_PER_MSEC);
}
[GIT pull] locking fix for 4.10
Linus, please pull the latest locking-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-urgent-for-linus Move the futex init function to core initcall so user mode helper does not run into an uninitialized futex syscall. Thanks, tglx --> Yang Yang (1): futex: Move futex_init() to core_initcall kernel/futex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/futex.c b/kernel/futex.c index 0842c8ca534b..cdf365036141 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -3323,4 +3323,4 @@ static int __init futex_init(void) return 0; } -__initcall(futex_init); +core_initcall(futex_init);
[GIT pull] x86 fix for 4.10
Linus,
please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
Make the build clean by working around yet another GCC stupidity.
Thanks,
tglx
-->
Kirill A. Shutemov (1):
x86/vm86: Fix unused variable warning if THP is disabled
arch/x86/kernel/vm86_32.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
index ec5d7545e6dc..0442d98367ae 100644
--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -160,11 +160,12 @@ void save_v86_state(struct kernel_vm86_regs *regs, int
retval)
static void mark_screen_rdonly(struct mm_struct *mm)
{
+ struct vm_area_struct *vma;
+ spinlock_t *ptl;
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
pte_t *pte;
- spinlock_t *ptl;
int i;
down_write(&mm->mmap_sem);
@@ -177,7 +178,7 @@ static void mark_screen_rdonly(struct mm_struct *mm)
pmd = pmd_offset(pud, 0xA);
if (pmd_trans_huge(*pmd)) {
- struct vm_area_struct *vma = find_vma(mm, 0xA);
+ vma = find_vma(mm, 0xA);
split_huge_pmd(vma, pmd, 0xA);
}
if (pmd_none_or_clear_bad(pmd))
[PATCH] usercopy: Don't test 64-bit get/put_user() on 32-bit powerpc
Add PPC32 to the opt-out list, otherwise it breaks the build. Signed-off-by: Michael Ellerman --- lib/test_user_copy.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c index 4a79f2c1cd6e..6f335a3d4ae2 100644 --- a/lib/test_user_copy.c +++ b/lib/test_user_copy.c @@ -37,6 +37,7 @@ !defined(CONFIG_MICROBLAZE) && \ !defined(CONFIG_MN10300) && \ !defined(CONFIG_NIOS2) && \ + !defined(CONFIG_PPC32) && \ !defined(CONFIG_SUPERH)) # define TEST_U64 #endif -- 2.7.4
Re: [kernel-hardening] Re: [PATCH] usercopy: Add tests for all get_user() sizes
Kees Cook writes:
> On Wed, Feb 15, 2017 at 12:50 AM, Geert Uytterhoeven
> wrote:
>> On Tue, Feb 14, 2017 at 9:40 PM, Kees Cook wrote:
>>> The existing test was only exercising native unsigned long size
>>> get_user(). For completeness, we should check all sizes.
>>>
>>> Signed-off-by: Kees Cook
>>> ---
>>> lib/test_user_copy.c | 45 ++---
>>> 1 file changed, 34 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c
>>> index ac3a60ba9331..49569125b7c5 100644
>>> --- a/lib/test_user_copy.c
>>> +++ b/lib/test_user_copy.c
>>> @@ -40,8 +40,11 @@ static int __init test_user_copy_init(void)
>>> char __user *usermem;
>>> char *bad_usermem;
>>> unsigned long user_addr;
>>> - unsigned long value = 0x5A;
>>> char *zerokmem;
>>> + u8 val_u8;
>>> + u16 val_u16;
>>> + u32 val_u32;
>>> + u64 val_u64;
>>>
>>> kmem = kmalloc(PAGE_SIZE * 2, GFP_KERNEL);
>>> if (!kmem)
>>> @@ -72,10 +75,20 @@ static int __init test_user_copy_init(void)
>>> "legitimate copy_from_user failed");
>>> ret |= test(copy_to_user(usermem, kmem, PAGE_SIZE),
>>> "legitimate copy_to_user failed");
>>> - ret |= test(get_user(value, (unsigned long __user *)usermem),
>>> - "legitimate get_user failed");
>>> - ret |= test(put_user(value, (unsigned long __user *)usermem),
>>> - "legitimate put_user failed");
>>> +
>>> +#define test_legit(size) \
>>> + do { \
>>> + ret |= test(get_user(val_##size, (size __user *)usermem), \
>>> + "legitimate get_user (" #size ") failed");\
>>> + ret |= test(put_user(val_##size, (size __user *)usermem), \
>>> + "legitimate put_user (" #size ") failed");\
>>> + } while (0)
>>> +
>>> + test_legit(u8);
>>> + test_legit(u16);
>>> + test_legit(u32);
>>> + test_legit(u64);
>>> +#undef test_legit
>>
>> ERROR: "__get_user_bad" [lib/test_user_copy.ko] undefined!
>>
>> http://kisskb.ellerman.id.au/kisskb/buildresult/12936728/
>>
>> So 64-bit get_user() support is mandatory now?
>
> That's not my intention. :) In my sampling of architectures, I missed
> a couple 32-bit archs that don't support 64-bit getuser(). I'm not
> sure how to correctly write these tests, though, since it seems rather
> ad-hoc. e.g. m68k has 64-bit getuser() commented out due to an old gcc
> bug...
>
> Should I just universally skip 64-bit getuser on 32-bit archs?
I think you should just make it opt-in for 32-bit arches.
cheers
Re: [PATCH trivial 1/4] HID: picoLCD: Spelling s/REPORT_WRTIE_MEMORY/REPORT_WRITE_MEMORY/
Hi Geert, Jiri, Fine with me, Acked-by: Bruno Prémont On Fri, 17 Feb 2017 16:36:36 Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > Cc: Bruno Prémont > Cc: linux-in...@vger.kernel.org > --- > drivers/hid/hid-picolcd_debugfs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hid/hid-picolcd_debugfs.c > b/drivers/hid/hid-picolcd_debugfs.c > index 3c13af6844108f97..3e0feb4bb5380978 100644 > --- a/drivers/hid/hid-picolcd_debugfs.c > +++ b/drivers/hid/hid-picolcd_debugfs.c > @@ -736,7 +736,7 @@ void picolcd_debug_raw_event(struct picolcd_data *data, > } > break; > case REPORT_MEMORY: > - /* Data buffer in response to REPORT_READ_MEMORY or > REPORT_WRTIE_MEMORY */ > + /* Data buffer in response to REPORT_READ_MEMORY or > REPORT_WRITE_MEMORY */ > snprintf(buff, BUFF_SZ, "report %s (%d, size=%d)\n", > "REPORT_MEMORY", report->id, size-1); > hid_debug_event(hdev, buff);
next_tick hang was Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot
Hi! [I droped some CCs here, you may want to check the CC list]. > > These are different bugs. > > > > On x60, I see failures doing hotplug/unplug in a loop, or lot of > > suspends. Someone seen it in v4.8-stable etc. Old bug. Rare to hit. > > > > Desktop machine was failing to boot, and had some fun with > > suspend/resume too. Boot hang was reproducible with right > > procedure. (Hard poweroff, cold boot.). That one was introduced in > > 4.10-rc cycle. > > Pavel, is there any chance you could apply this patch on top of latest linus > tree > and send me your resulting dmesg log? This has the two reverted patches plus > some > debugging code. The amount of printk shouldn't be too big, I tested it home > without > issue. > > If you can't manage to dump the dmesg, please try to take a picture of your > screen > so that I can see the last messages starting with "NEXT_TICK_READ". > > Thanks! I guess I can. But I'll only have one 80x25 screen to look at... .config is attached. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html config.gz Description: application/gzip signature.asc Description: Digital signature
Re: [PATCH v7 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family
2017-02-16 14:00 GMT+08:00 Baoyou Xie : > This patch adds i2c controller driver for ZTE's zx2967 family. > > Signed-off-by: Baoyou Xie > Reviewed-by: Shawn Guo > Reviewed-by: Andy Shevchenko Reviewed-by: Jun Nie
Re: [PATCH] platform/x86: ideapad-laptop: Add sysfs interface for touchpad state
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Dmitry, On Fri, 2017-02-17 at 11:52 -0800, Dmitry Torokhov wrote: > OK, if firmware disables the touchpad automatically, then it is fine. > > I am wondering about the utility of the new interface though. Are there > already major users of it? Not yet. I proposed this interface because we want something like this for Onboard. For detailed discussion, please see: https://bugs.launchpad.net/onboard/+bug/1366421/comments/43 hp-wmi and thinkpad-acpi do provide a similar interface, but for tablet. > If there are no users, then there is no point > in adding it, it will stay there unused and forgotten by anyone. > Teaching ideapad to emit SW_TABLET_MODE is more useful IMO. If accepted, Onboard will be a consumer. Yes. SW_TABLET_MODE would be ideal. But looking at the drive's code, I don't know if it has an EC command for it. - -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlioGScACgkQpjpYo/Lh dWnEvA/5AfQQYaBiOsunZuR6OcM1BrFy1vpSGAToRNdWkaV18p7IfZGSkDUbZ3U+ rLdL5URnD5/CsHhcOPpUp4IhM4wdce+Rxc4T4LdEyjqZ29IlGrA7k21i2fJXfEws 5Mjd+pN01PitXGGBjc/BcX0ol37pcXyLfMpl3UKvE44LU2CwU5sahnSDyHgM+G77 Gnoy5Po0eLAQoOPAJIsLwSaxJlzoZAknZWuAwqQfNXxXdxVFfTr5OmV9pcTx2vgw cPdg+8lrU8M7w2SNrK91AvccnXLV5T/rNOolk3VHoH/AQJdgxbiZKdkv0jyg/WKp TyGIkgwNSFjYeph/JZ/IqXkOnkuB/TcKQq7uVKN5b71U2VouV6gEe/2RcOQ+lSYg au3NX4Wq6Ot9MSMfqwIZ0+TgazGGjbUlFLhf1TFRZ9o8ERsZrtaXsC5c1U3egAS/ XZWuiI0CI5c3k1WTxWpy76pX963gh+3d9kejanWug2LIriIALmD5/ryN56Jml41S 3I3JnnuiLuwnZ/t/ehA3c9JVhsbTJg4dBbZE9tKgnAjIV/MmmbE9kCtnCRcBuFUa W2vViMxv2eVBfiHP3Z8TC7E0UUqe69htDEomFfwDpQ1oSqDLzm6gafH8LStbYML8 j+/qGUTyg8d3yP/jrUL5UDO6dMkj+FV5bNi4qlue4uVLV7bx4o8= =flDx -END PGP SIGNATURE-
[PATCH] spi: spi-ti-qspi: Fix error handling
'dma_request_chan_by_mask()' can not return NULL.
Try to keep the logic in 'no_dma:' by resetting 'qspi->rx_chan' in case
of error.
Signed-off-by: Christophe JAILLET
---
drivers/spi/spi-ti-qspi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index ec6fb09e2e17..0fefa6423ff4 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -714,9 +714,10 @@ static int ti_qspi_probe(struct platform_device *pdev)
dma_cap_set(DMA_MEMCPY, mask);
qspi->rx_chan = dma_request_chan_by_mask(&mask);
- if (!qspi->rx_chan) {
+ if (IS_ERR(qspi->rx_chan)) {
dev_err(qspi->dev,
"No Rx DMA available, trying mmap mode\n");
+ qspi->rx_chan = NULL;
ret = 0;
goto no_dma;
}
--
2.9.3
[tip:timers/core] hrtimer: Catch invalid clockids again
Commit-ID: 336a9cde10d641e70bac67d90ae91b3190c3edca
Gitweb: http://git.kernel.org/tip/336a9cde10d641e70bac67d90ae91b3190c3edca
Author: Marc Zyngier
AuthorDate: Fri, 15 Jan 2016 17:41:09 +
Committer: Thomas Gleixner
CommitDate: Sat, 18 Feb 2017 10:58:39 +0100
hrtimer: Catch invalid clockids again
commit 82e88ff1ea94 ("hrtimer: Revert CLOCK_MONOTONIC_RAW support") removed
unfortunately a sanity check in the hrtimer code which was part of that
MONOTONIC_RAW patch series.
It would have caught the bogus usage of CLOCK_MONOTONIC_RAW in the wireless
code. So bring it back.
It is way too easy to take any random clockid and feed it to the hrtimer
subsystem. At best, it gets mapped to a monotonic base, but it would be
better to just catch illegal values as early as possible.
Detect invalid clockids, map them to CLOCK_MONOTONIC and emit a warning.
[ tglx: Replaced the BUG by a WARN and gracefully map to CLOCK_MONOTONIC ]
Signed-off-by: Marc Zyngier
Cc: Tomasz Nowicki
Cc: Christoffer Dall
Link:
http://lkml.kernel.org/r/1452879670-16133-3-git-send-email-marc.zyng...@arm.com
Signed-off-by: Thomas Gleixner
---
kernel/time/hrtimer.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index edabde6..8e11d8d 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -94,17 +94,15 @@ DEFINE_PER_CPU(struct hrtimer_cpu_base, hrtimer_bases) =
};
static const int hrtimer_clock_to_base_table[MAX_CLOCKS] = {
+ /* Make sure we catch unsupported clockids */
+ [0 ... MAX_CLOCKS - 1] = HRTIMER_MAX_CLOCK_BASES,
+
[CLOCK_REALTIME]= HRTIMER_BASE_REALTIME,
[CLOCK_MONOTONIC] = HRTIMER_BASE_MONOTONIC,
[CLOCK_BOOTTIME]= HRTIMER_BASE_BOOTTIME,
[CLOCK_TAI] = HRTIMER_BASE_TAI,
};
-static inline int hrtimer_clockid_to_base(clockid_t clock_id)
-{
- return hrtimer_clock_to_base_table[clock_id];
-}
-
/*
* Functions and macros which are different for UP/SMP systems are kept in a
* single place
@@ -1081,6 +1079,18 @@ u64 hrtimer_get_next_event(void)
}
#endif
+static inline int hrtimer_clockid_to_base(clockid_t clock_id)
+{
+ if (likely(clock_id < MAX_CLOCKS)) {
+ int base = hrtimer_clock_to_base_table[clock_id];
+
+ if (likely(base != HRTIMER_MAX_CLOCK_BASES))
+ return base;
+ }
+ WARN(1, "Invalid clockid %d. Using MONOTONIC\n", clock_id);
+ return HRTIMER_BASE_MONOTONIC;
+}
+
static void __hrtimer_init(struct hrtimer *timer, clockid_t clock_id,
enum hrtimer_mode mode)
{
Re: [PATCH] soc: ti: knav_dma: Fix some error handling
Hi Christophe, [auto build test ERROR on v4.9-rc8] [also build test ERROR on next-20170217] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Christophe-JAILLET/soc-ti-knav_dma-Fix-some-error-handling/20170218-164533 config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): drivers/soc/ti/knav_dma.c: In function 'dma_init': >> drivers/soc/ti/knav_dma.c:675:13: error: 'ma' undeclared (first use in this >> function) if (IS_ERR(ma->reg_rx_flow)) ^~ drivers/soc/ti/knav_dma.c:675:13: note: each undeclared identifier is reported only once for each function it appears in vim +/ma +675 drivers/soc/ti/knav_dma.c 669 dma->reg_tx_sched = pktdma_get_regs(dma, node, 3, &size); 670 if (IS_ERR(dma->reg_tx_sched)) 671 return -ENODEV; 672 673 max_tx_sched = size / sizeof(struct reg_tx_sched); 674 dma->reg_rx_flow = pktdma_get_regs(dma, node, 4, &size); > 675 if (IS_ERR(ma->reg_rx_flow)) 676 return -ENODEV; 677 678 max_rx_flow = size / sizeof(struct reg_rx_flow); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH v2] soc: ti: knav_dma: Fix some error handling
'pktdma_get_regs()' never returns NULL. It returns an error pointer or a
valid pointer.
So test its return value with IS_ERR.
Signed-off-by: Christophe JAILLET
---
After checking with IS_ERR, it could be better to propagate the error code
instead of returning -ENODEV uncondionnaly
v2: fix typo leading to an undeclared identifier build error
(thx kbuild test robot for spotting it)
---
drivers/soc/ti/knav_dma.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index ecebe2eecc3a..3272b379bfcd 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -649,7 +649,7 @@ static int dma_init(struct device_node *cloud, struct
device_node *dma_node)
}
dma->reg_global = pktdma_get_regs(dma, node, 0, &size);
- if (!dma->reg_global)
+ if (IS_ERR(dma->reg_global))
return -ENODEV;
if (size < sizeof(struct reg_global)) {
dev_err(kdev->dev, "bad size %pa for global regs\n", &size);
@@ -657,22 +657,22 @@ static int dma_init(struct device_node *cloud, struct
device_node *dma_node)
}
dma->reg_tx_chan = pktdma_get_regs(dma, node, 1, &size);
- if (!dma->reg_tx_chan)
+ if (IS_ERR(dma->reg_tx_chan))
return -ENODEV;
max_tx_chan = size / sizeof(struct reg_chan);
dma->reg_rx_chan = pktdma_get_regs(dma, node, 2, &size);
- if (!dma->reg_rx_chan)
+ if (IS_ERR(dma->reg_rx_chan))
return -ENODEV;
max_rx_chan = size / sizeof(struct reg_chan);
dma->reg_tx_sched = pktdma_get_regs(dma, node, 3, &size);
- if (!dma->reg_tx_sched)
+ if (IS_ERR(dma->reg_tx_sched))
return -ENODEV;
max_tx_sched = size / sizeof(struct reg_tx_sched);
dma->reg_rx_flow = pktdma_get_regs(dma, node, 4, &size);
- if (!dma->reg_rx_flow)
+ if (IS_ERR(dma->reg_rx_flow))
return -ENODEV;
max_rx_flow = size / sizeof(struct reg_rx_flow);
--
2.9.3
Re: [PATCH] Tty: serial - Fix possible NULL derefrence.
Hello Greg,
Does that also mean that this isn't possible in the sc16is7xx.c driver
in
sc16is7xx_spi_probe() line 1358 and sc16is7xx_i2c_probe() line 1419 ?
If so, should these checks be removed?
Kind regards,
Maarten
On 2017-01-30 20:37, Greg Kroah-Hartman wrote:
On Fri, Jan 27, 2017 at 04:46:13PM +0530, Shailendra Verma wrote:
of_match_device could return NULL, and so can cause a NULL
pointer dereference later.
Signed-off-by: Shailendra Verma
---
drivers/tty/serial/max310x.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/max310x.c
b/drivers/tty/serial/max310x.c
index 8a3e926..a94d147 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -1323,6 +1323,10 @@ static int max310x_spi_probe(struct spi_device
*spi)
if (spi->dev.of_node) {
const struct of_device_id *of_id =
of_match_device(max310x_dt_ids, &spi->dev);
+ if (!of_id) {
+ dev_err(&spi->dev, "Error: No device match found\n");
+ return -ENODEV;
+ }
Patch now dropped as this isn't possible.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-serial"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches
On Friday 17 February 2017 23:38:12 Finn Thain wrote:
> On Thu, 16 Feb 2017, Ondrej Zary wrote:
> > On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
> > [...]
> >
> > > Are you trying to figure out which commands are going to disconnect
> > > during a transfer? This is really a function of the firmware in the
> > > target; there are no good heuristics AFAICT, so the PDMA algorithm has
> > > to be robust. mac_scsi has to cope with this too.
> > >
> > > Does the problem go away when you assign no IRQ? When instance->irq ==
> > > NO_IRQ, the core driver will inhibit disconnect privileges.
> >
> > Yes, it seems to run fine with IRQ/disconnect disabled. With IRQ
> > enabled, "dd if=/dev/sr0 of=anything" stops after a while.
>
> When you say "stops", do you mean an infinite loop in
> generic_NCR5380_pread or does the loop complete (which would presumably
> leave the target stuck in DATA IN phase, and a scsi command timeout would
> probably follow after 30 seconds...)
I've added timeouts to the possibly-infinite loops. It times out waiting for
the host buffer to become ready. Then everything breaks.
Now I found why: pread() returns without waiting for the 53C80 registers to be
ready. Adding the wait allows to continue in PIO mode with "tag#0 switching
to slow handshake".
> > I get gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.
>
> You can use NCR5380_print() to get a decoded register dump.
>
> When I decode the above values I get,
>
> BASR = 0x10 = BASR_IRQ
> MODE = 0x0e = MR_ENABLE_EOP_INTR | MR_MONITOR_BSY | MR_DMA_MODE
> STATUS = 0x7c = SR_BSY | SR_REQ | SR_MSG | SR_CD | SR_IO
>
> Since BASR_PHASE_MATCH is not set, the interrupt is almost certainly a
> phase mismatch. The new phase is SR_MSG | SR_CD | SR_IO = PHASE_MSGIN,
> which shows that the target has given up on the DATA IN phase and is
> presumably trying to send a DISCONNECT message.
Looks you're right. The transfersize is 4096, i.e. 2 CD-ROM sectors. When the
2nd sector is not ready in the drive internal buffer, the drive probably
disconnects which breaks the fragile pdma transfer. When the transfersize is
limited to 2048 bytes, the problem goes away.
The problem also went away with enabled interrupts because I had some debug
printks added which were slowing down the transfer enough for the drive (SONY
CDU-55S) to keep up and not disconnect. Got the same result by inserting
udelay(100) after each 128 byte block trasnferred in pread().
> > When I enable interrupts during PDMA (like the removed UNSAFE macro
> > did), the problems go away. I see an IRQ after each pread call.
>
> You shouldn't need an interrupt, because NCR5380_dma_complete() gets
> called regardless. AFAICT, the only difference is the timing, which
> becomes less predictable. Calling spinlock_irq_restore() before the
> transfer seems to create a race condition between hostdata->dma_len store
> and load.
>
> I think that the pread call has not yet returned when the interrupt fires
> and NCR5380_dma_complete() is called. Hence hostdata->dma_len has not yet
> been initialized. So when NCR5380_dma_complete() is called by the
> interrupt handler, SCp.this_residual will not change at all because
> hostdata->dma_len is still zero.
>
> > (had to disable "no 53C80 gated irq after transfer" and "no end dma
> > signal" messages to reduce log spam)
>
> That may provide a quick way to detect the failed PDMA transfer, at least
> for testing purposes. There may be a more conclusive test for a partial
> transfer.
>
> We could to implement something like macscsi_dma_residual() to take care
> of a failed PDMA transfer. That way, the failure can be taken into account
> when NCR5380_dma_complete() is called at the end of the transfer.
>
> See patch below for example. It should confirm the theory above though it
> really needs some timeouts added (NCR5380_poll_politely()). And perhaps we
> could do something more clever than retry indefinitely, though we can
> still rely on the command timeout.
Thanks for idea
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index 6f9665d..75cfaf3 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -497,15 +497,17 @@ static inline int generic_NCR5380_pread(struct
> NCR5380_hostdata *hostdata, blocks--;
> }
>
> + hostdata->pdma_residual = 0;
> +
> if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
> - printk("53C400r: no 53C80 gated irq after transfer");
> + hostdata->pdma_residual = hostdata->dma_len;
>
> /* wait for 53C80 registers to be available */
> while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG))
> ;
>
> if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
> - printk(KERN_ERR "53C400r: no end dma signal\n");
> + hostdata->pdma_residual = hostdata->dma_len;
>
> return 0;
> }
> @@ -576,12 +578,14 @@ static inline int generic_NCR5380_pwrite(struct
>
Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)
Hi Dmitry, > Am 17.02.2017 um 21:43 schrieb Dmitry Torokhov : > > On Wed, Feb 15, 2017 at 03:03:07PM +0100, H. Nikolaus Schaller wrote: >> Hi Dmitry, >> >>> Am 12.02.2017 um 16:18 schrieb H. Nikolaus Schaller : >>> >>> Hi Dmitry, >>> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller : Hi Dmitry, there have been no further comments/complaints about this patch series in the last month. And it appears as if only your action is needed. What is missing for this patch series to be finally accepted? >>> >>> Did you find time to look into my comment on patch 1/9 and make a decision >>> on patch 6/8? >>> >>> Is there anything open which prohibits inclusion to (and further testing >>> within) linux/next? >> >> May I ask a question for my fundamental understanding of the Linux >> integration process. >> Maybe, I have a wrong expectation which you can clarify. >> >> My question is how it does come that patches like >> >> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=449aa83e69ff10d77fe088eadacafe1e97937c14 >> >> appear within 2 days in linux-next, but our patch series had months of >> review (we are at v9) >> and there have been no further comments from the community for weeks? > > Simpler patches are easy to apply, patches that have some contention > tend to get unapplied longer, as they require more consideration. Fine. Now I have better understanding. > >> >> What is still missing what we can do or provide as information? > > I just replied to the other email from you. BR and thanks, Nikolaus
[PATCH] x86/events: Remove last remnants of old filenames
From: Borislav Petkov
Update to the new file paths, remove them from introductory comments.
Signed-off-by: Borislav Petkov
---
arch/x86/events/amd/core.c | 2 +-
arch/x86/events/intel/cstate.c | 2 +-
arch/x86/events/intel/rapl.c | 2 +-
arch/x86/events/intel/uncore.h | 6 +++---
tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index afb222b63cae..c84584bb9402 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -604,7 +604,7 @@ amd_get_event_constraints_f15h(struct cpu_hw_events *cpuc,
int idx,
return &amd_f15_PMC20;
}
case AMD_EVENT_NB:
- /* moved to perf_event_amd_uncore.c */
+ /* moved to uncore.c */
return &emptyconstraint;
default:
return &emptyconstraint;
diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
index aff4b5b69d40..238ae3248ba5 100644
--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -1,5 +1,5 @@
/*
- * perf_event_intel_cstate.c: support cstate residency counters
+ * Support cstate residency counters
*
* Copyright (C) 2015, Intel Corp.
* Author: Kan Liang (kan.li...@intel.com)
diff --git a/arch/x86/events/intel/rapl.c b/arch/x86/events/intel/rapl.c
index 22054ca49026..9d05c7e67f60 100644
--- a/arch/x86/events/intel/rapl.c
+++ b/arch/x86/events/intel/rapl.c
@@ -1,5 +1,5 @@
/*
- * perf_event_intel_rapl.c: support Intel RAPL energy consumption counters
+ * Support Intel RAPL energy consumption counters
* Copyright (C) 2013 Google, Inc., Stephane Eranian
*
* Intel RAPL interface is specified in the IA-32 Manual Vol3b
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index ad986c1e29bc..df5989f27b1b 100644
--- a/arch/x86/events/intel/uncore.h
+++ b/arch/x86/events/intel/uncore.h
@@ -360,7 +360,7 @@ extern struct list_head pci2phy_map_head;
extern struct pci_extra_dev *uncore_extra_pci_dev;
extern struct event_constraint uncore_constraint_empty;
-/* perf_event_intel_uncore_snb.c */
+/* uncore_snb.c */
int snb_uncore_pci_init(void);
int ivb_uncore_pci_init(void);
int hsw_uncore_pci_init(void);
@@ -371,7 +371,7 @@ void nhm_uncore_cpu_init(void);
void skl_uncore_cpu_init(void);
int snb_pci2phy_map_init(int devid);
-/* perf_event_intel_uncore_snbep.c */
+/* uncore_snbep.c */
int snbep_uncore_pci_init(void);
void snbep_uncore_cpu_init(void);
int ivbep_uncore_pci_init(void);
@@ -385,5 +385,5 @@ void knl_uncore_cpu_init(void);
int skx_uncore_pci_init(void);
void skx_uncore_cpu_init(void);
-/* perf_event_intel_uncore_nhmex.c */
+/* uncore_nhmex.c */
void nhmex_uncore_cpu_init(void);
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
b/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
index 7913363bde5c..4f3c758d875d 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
@@ -31,7 +31,7 @@
#error Instruction buffer size too small
#endif
-/* Based on branch_type() from perf_event_intel_lbr.c */
+/* Based on branch_type() from arch/x86/events/intel/lbr.c */
static void intel_pt_insn_decoder(struct insn *insn,
struct intel_pt_insn *intel_pt_insn)
{
--
2.11.0
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
Hi Dmitry,
> Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov :
>
> Hi Nikolaus,
>
> On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>>
>>> Am 28.01.2017 um 20:33 schrieb Dmitry Torokhov :
>>>
>>> Hi Nikolaus,
>>>
>>> On Wed, Dec 28, 2016 at 03:53:16PM +0100, H. Nikolaus Schaller wrote:
commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.
commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted /
swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.
Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.
A new feature is to introduce scaling the min/max ADC values to the screen
size.
This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.
>>>
>>> I question whether doing scaling in kernel is really right solution.
>>
>> Since lower left corner does not exactly report [0 0] and upper right corner
>> does not report [4095 4095] from the ADC we need offset and steepness
>> correction
>> of the ADC values.
>>
>> This steepness is the scaling that must happen in kernel and I don't
>> understand
>> why you want to propagate this ADC errors to user-space by avoiding scaling.
>>
>> Let me iterate what we want to achieve:
>> * use new common bindings
>> * offset and steepness calibration of the ADC (called pre-calibration).
>> This makes a real device much more reliable to operate with factory
>> installed
>> scaling factors.
>> * flipping and rotation
>>
>> (note that touch pixel to LCD pixel scaling is not explicitly on this list!)
>
> That was explicitly called out in the patch:
>
> "A new feature is to introduce scaling the min/max ADC values to the
> screen size."
Because it is a feature that was not planned nor required, but is there. So it
came
into the description of what can be done. If this is the key problem I am happy
with
removing it from the commit messages.
Anyways, scaling to screen coordinates is not my invention. It is based on
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
which defines the size to be in pixels. Well, a resistive touch screen does not
have pixels.
It might have a resolution/precision given by the ADC conversion steps but I
assume
this is not meant here.
So this scaling to screen size was also stimulated by this DT bindings.
>
>>
>> Now to achieve the ADC pre-calibration we must calculate
>>
>> x' = (x - ti,min-x) / (ti,max-x-ti,min-x) giving a rante from 0.0 ...
>> 1.0
>>
>> This is scaled up to what is defined by touchscreen-size-x, i.e.
>>
>> x' = (touchscreen-size-x * (x - ti,min-x)) / (ti,max-x-ti,min-x)
>>
>> How do you want to avoid this scaling to take place? It happens
>> automatically.
>> It is not even an additional line of code. And is necessary for compensating
>> ADC
>> offsets and steepness.
>>
>> So the only way to avoid the scaling option is to eliminate the
>> precalibration/ADC
>> compensation which is essential for a device which has no means to properly
>> calibrate before operating the device through touch.
>>
>> The other option would be to avoid common bindings and set
>>
>> touchscreen-size-x = (ti,max-x-ti,min-x)
>>
>> This is heavily dependent on specific ADC offsets forwarded to user-space.
>> IMHO the worst we can do (and the current tsc2007 driver does it that way!).
>>
>>>
>>> Why do you want this?
>>
>> It seems that you assume that we want to enforce 1:1 scaling between touch
>> pixels
>> and LCD pixels and have designed code to achieve exactly that.
>>
>> This is not the case. It is just a byproduct that you can do it.
>>
>> And since it is easier to understand we have made the examples this way.
>>
>>> If your touch resolution is lower than your screen
>>> then it might be useful, but if it is lower then you are losing data
>>> that can be very helpful for gesture recognition, and I hope you design
>>> your userspace so it can handle not only "bad" hardware, but "good" as
>>> well. And even with "bad" there are a lot of tricks that can be done to
>>> get "better" touch position in userspace.
>>
>> You can just *choose* DT parameters touchscreen-size-x to match the LCD size.
>> This of course reduces the touch precision to full LCD pixels. For finger-
>> touch operated devices, subpixel precision is rarely needed.
>>
>> Also, some user-spaces (e.g. older Replicant for GTA04) assume that there is
>> such an 1:1 mapping and they will be perfectly happy about this.
>>
>> But
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
Hi Pavel, > Am 18.02.2017 um 10:15 schrieb Pavel Machek : > > Hi! > >>> Well, there is some historic confusion wether this driver reports resistance >>> or pressure. >>> >>> The unpatched tsc2007 driver does it wrong (please test!) and we fix it on >>> the fly (because a separate patch is much more complex than doing it right >>> immediately). >>> >>> This ti,report-resistance property is a means to get the old (wrong) >>> meaning back >>> in case someone urgently needs it and can't fix the user-space workaround >>> which >>> he must be using. >>> >>> >>> AFAIK there is no mainline board using the DT except ours (and the upcoming >>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove >>> this >>> compatibility property. We don't need it for our devices. > > N900 is mainline and uses DT. Yes, but it does not use the tsc2007 and will not be influenced at all by this patch. > >>> That the function name is wrong is a second issue and this double negation >>> might >>> confuse a litte. >>> >>> Please test on a real device if the patched driver reports pressure now >>> (unless >>> ti,report-resistance is specified). >> >> I unfortunately can not test this driver as I do not have the hardware. >> So all my observations are from code and data sheets. >> >> That said, what is the values emitted as ABS_PRESSURE when finger is not >> touching the device, barely touching the device, or pressing firmly? >> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have >> confusion as to what is being reported. >> >> I am adding a few more folks to the CC so we can try and soft this out. >> Sebastian, Pali, Pavel, any input here? > > X work ok on N900. Nikolaus wrote rather long email, but I'm not what > the meaning is and what is supposed to be broken there. IMHO it is broken that you have to do a subtle calibration step in user-space and repeat it for different GUI toolkits. > > I do this on X startup: > > xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate > Transformation Matrix" 1.10 0.00 -0.05 0.00 1.18 -0.10 0.00 0.00 1.00 > xinput --set-prop --type=int "TSC200X touchscreen" "Evdev Axis Inversion" 0 1 > xinput --set-prop --type=float "TSC2005 touchscreen" "Coordinate > Transformation Matrix" 1\ > .10 0.00 -0.05 0.00 1.18 -0.10 0.00 0.00 1.00 > xinput --set-prop --type=int "TSC2005 touchscreen" "Evdev Axis Inversion" 0 1 Wouldn't it be nice to get rid of this completely, because the DT/kernel knows these factors? Especially since they are well defined by the hardware? > > And I agree that kernel should _not_ attempt rescaling itself, as it > would lose precision. With an almost 1:1 mapping you won't loose precision. > Providing default calibration info is ok. IMHO it is missing one step of automation. BR and thanks, Nikolaus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
Hi Sebastian, > Am 18.02.2017 um 04:22 schrieb Sebastian Reichel : > > Hi, > > On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote: >>> AFAIK there is no mainline board using the DT except ours (and the upcoming >>> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove >>> this >>> compatibility property. We don't need it for our devices. > > $ cd linux.git/arch > $ git grep -l tsc2004 > arm/boot/dts/imx6qdl-nit6xlite.dtsi > arm/boot/dts/imx7d-nitrogen7.dts > arm/boot/dts/logicpd-torpedo-37xx-devkit.dts > arm/boot/dts/omap4-var-som-om44.dtsi > $ git grep -l tsc2005 > arm/boot/dts/omap3-n900.dts Those are not relevant since tsc2004/5 and tsc2007 are independent drivers and don't share code. Hence the N900 is not influenced by this patch series. If it has a similar issue, it should be fixed of course. > $ git grep -l tsc2007 > arm/boot/dts/imx28-tx28.dts > arm/boot/dts/imx35-eukrea-cpuimx35.dtsi > arm/boot/dts/imx51-eukrea-cpuimx51.dtsi > arm/boot/dts/imx53-tx53-x03x.dts > arm/boot/dts/imx6qdl-tx6.dtsi > arm/boot/dts/imx6ul-tx6ul.dtsi > arm/boot/dts/omap3-gta04.dtsi > sh/boards/mach-ecovec24/setup.c Sorry, I was a little imprecise here, because I looked for the min/max properties. Of course, the imx devices use the tsc2007 as well. Maybe we should edit all these DTS and set the "ti,report-resistance" property by default. Then, no user should notice a difference. Is any user/maintainer of these devices following this discussion and can comment? > >> You seem to be treating DT data as something very fluid, which is wrong. >> You need to treat it as a firmware, unlikely to change once device is >> shipped. Unlike legacy platform data, the fact that DTS files are not >> present in mainline does not mean that we can ignore such users and >> change behavior at will. >> >> That said, if driver behavior is out of line from the subsystem >> expectations, we need to fix it. >> >> >>> That the function name is wrong is a second issue and this double negation >>> might >>> confuse a litte. >>> >>> Please test on a real device if the patched driver reports pressure now >>> (unless >>> ti,report-resistance is specified). >> >> I unfortunately can not test this driver as I do not have the hardware. >> So all my observations are from code and data sheets. >> >> That said, what is the values emitted as ABS_PRESSURE when finger is not >> touching the device, barely touching the device, or pressing firmly? >> It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have >> confusion as to what is being reported. > > As far as I can see all calculate Rtouch and ADS7846 reports > (Rmax - Rtouch), which looks sensible. I don't see where this subtraction from Rmax takes place for the tsc2007: http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131 > >> I am adding a few more folks to the CC so we can try and soft this out. >> Sebastian, Pali, Pavel, any input here? > > I think tsc200x works, since usually userspace is Xorg and I think > it only cares for x/y coordinates + boolean pressure. Since > no-pressure is correctly reported as 0, everything works as > expected. No pressure is usually treated as a special case in these drivers, so reduction to "boolean" in user-space works well by accident and might still hide a bug. > I currently don't have X running on my N900 due some > omapdrm bug, so I can't test this, sorry. I usually look with evtest if ABS_PRESSURE is monotonic. > > I suggest to put the resistance vs pressure thing in its own patch, > that also fixes tsc200x-core and merge it to linux-next after the > merge window. > > -- Sebastian BR and thanks, Nikolaus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH v9 8/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature
> Am 17.02.2017 um 22:27 schrieb Dmitry Torokhov :
>
> On Fri, Dec 30, 2016 at 08:36:30PM +, Jonathan Cameron wrote:
>> On 28/12/16 14:53, H. Nikolaus Schaller wrote:
>>> The tsc2007 chip not only has a resistive touch screen controller but
>>> also an external AUX adc imput which can be used for an ambient
>>> light sensor, battery voltage monitoring or any general purpose.
>>>
>>> Additionally it can measure the chip temperature.
>>>
>>> This extension provides an iio interface for these adc channels.
>>>
>>> Since it is not wasting much resources and is very straightforward,
>>> we simply provide all other adc channels as optional iio interfaces
>>> as weel. This can be used for debugging or special applications.
>>>
>>> This patch also splits the tsc2007 driver in several source files:
>>> tsc2007.h -- constants, structs and stubs
>>> tsc2007_core.c -- functional parts of the original driver
>>> tsc2007_iio.c -- the optional iio stuff
>>>
>>> Makefile magic allows to conditionally link the iio stuff
>>> if CONFIG_IIO=y or =m in a way that it works with
>>> CONFIG_TOUCHSCREEN_TSC2007=m.
>>>
>>> Signed-off-by: H. Nikolaus Schaller
>>> Reviewed-by: Jonathan Cameron
>> Just for the record, I'm happy with the few changes from earlier versions.
>
> I untangled this from the rest of the patches (as it turned out to be
> the least controversial ;) ) and applied with some minor changes (see
> below). Please take a look at my tsc2007 branch on kernel.org to see if
> I missed anything.
Looks good!
BR and thanks,
Nikolaus
>
> Thanks.
>
>>
>> Jonathan
>>> ---
>>> drivers/input/touchscreen/Kconfig | 10 ++
>>> drivers/input/touchscreen/Makefile | 2 +
>>> drivers/input/touchscreen/tsc2007.h| 116
>>> .../touchscreen/{tsc2007.c => tsc2007_core.c} | 95 +++--
>>> drivers/input/touchscreen/tsc2007_iio.c| 150
>>> +
>>> 5 files changed, 299 insertions(+), 74 deletions(-)
>>> create mode 100644 drivers/input/touchscreen/tsc2007.h
>>> rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (86%)
>>> create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
>>>
>>> diff --git a/drivers/input/touchscreen/Kconfig
>>> b/drivers/input/touchscreen/Kconfig
>>> index efca013..1616a8d 100644
>>> --- a/drivers/input/touchscreen/Kconfig
>>> +++ b/drivers/input/touchscreen/Kconfig
>>> @@ -1035,6 +1035,16 @@ config TOUCHSCREEN_TSC2007
>>> To compile this driver as a module, choose M here: the
>>> module will be called tsc2007.
>>>
>>> +config TOUCHSCREEN_TSC2007_IIO
>>> + bool "IIO interface for external ADC input and temperature"
>>> + depends on TOUCHSCREEN_TSC2007
>>> + depends on IIO=y || IIO=TOUCHSCREEN_TSC2007
>>> + help
>>> + Saying Y here adds an iio interface to the tsc2007 which
>>> + provides values for the AUX input (used for e.g. battery
>>> + or ambient light monitoring), temperature and raw input
>>> + values.
>>> +
>>> config TOUCHSCREEN_W90X900
>>> tristate "W90P910 touchscreen driver"
>>> depends on ARCH_W90X900
>>> diff --git a/drivers/input/touchscreen/Makefile
>>> b/drivers/input/touchscreen/Makefile
>>> index 81b8645..05d1cc8 100644
>>> --- a/drivers/input/touchscreen/Makefile
>>> +++ b/drivers/input/touchscreen/Makefile
>>> @@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO) += tsc40.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE) += tsc200x-core.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2004) += tsc2004.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o
>>> +tsc2007-y := tsc2007_core.o
>>> +tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO) += tsc2007_iio.o
>>> obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o
>>> obj-$(CONFIG_TOUCHSCREEN_UCB1400) += ucb1400_ts.o
>>> obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001) += wacom_w8001.o
>>> diff --git a/drivers/input/touchscreen/tsc2007.h
>>> b/drivers/input/touchscreen/tsc2007.h
>>> new file mode 100644
>>> index 000..16efb60
>>> --- /dev/null
>>> +++ b/drivers/input/touchscreen/tsc2007.h
>>> @@ -0,0 +1,116 @@
>>> +/*
>>> + * Copyright (c) 2008 MtekVision Co., Ltd.
>>> + * Kwangwoo Lee
>>> + *
>>> + * Using code from:
>>> + * - ads7846.c
>>> + * Copyright (c) 2005 David Brownell
>>> + * Copyright (c) 2006 Nokia Corporation
>>> + * - corgi_ts.c
>>> + * Copyright (C) 2004-2005 Richard Purdie
>>> + * - omap_ts.[hc], ads7846.h, ts_osk.c
>>> + * Copyright (C) 2002 MontaVista Software
>>> + * Copyright (C) 2004 Texas Instruments
>>> + * Copyright (C) 2005 Dirk Behme
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include
>>> +
>>> +#define TSC2007_MEASURE_TEMP0 (0x0 << 4)
>>> +#define TSC2007_MEASURE_AUX(0x2 << 4)
>>> +#define TSC2007_MEASURE_TEMP1 (0x4 <<
[PATCH] RDMA/qedr: Fix some error handling
'qedr_alloc_pbl_tbl()' can not return NULL.
In qedr_init_user_queue():
- simplify the test for the return value, no need to test for NULL
- propagate the error pointer if needed, otherwise 0 (success) is returned.
This is spurious.
In init_mr_info():
- test the return value with IS_ERR
- propagate the error pointer if needed instead of an exlictit -ENOMEM.
This is a no-op as the only error pointer that we can have here is
already -ENOMEM
Signed-off-by: Christophe JAILLET
---
drivers/infiniband/hw/qedr/verbs.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/qedr/verbs.c
b/drivers/infiniband/hw/qedr/verbs.c
index ef83a3f322d6..0c51657af151 100644
--- a/drivers/infiniband/hw/qedr/verbs.c
+++ b/drivers/infiniband/hw/qedr/verbs.c
@@ -771,8 +771,10 @@ static inline int qedr_init_user_queue(struct ib_ucontext
*ib_ctx,
goto err0;
q->pbl_tbl = qedr_alloc_pbl_tbl(dev, &q->pbl_info, GFP_KERNEL);
- if (IS_ERR_OR_NULL(q->pbl_tbl))
+ if (IS_ERR(q->pbl_tbl)) {
+ rc = PTR_ERR(q->pbl_tbl);
goto err0;
+ }
qedr_populate_pbls(dev, q->umem, q->pbl_tbl, &q->pbl_info);
@@ -2105,8 +2107,8 @@ static int init_mr_info(struct qedr_dev *dev, struct
mr_info *info,
goto done;
info->pbl_table = qedr_alloc_pbl_tbl(dev, &info->pbl_info, GFP_KERNEL);
- if (!info->pbl_table) {
- rc = -ENOMEM;
+ if (IS_ERR(info->pbl_table)) {
+ rc = PTR_ERR(info->pbl_table);
goto done;
}
@@ -2117,7 +2119,7 @@ static int init_mr_info(struct qedr_dev *dev, struct
mr_info *info,
* list and allocating another one
*/
tmp = qedr_alloc_pbl_tbl(dev, &info->pbl_info, GFP_KERNEL);
- if (!tmp) {
+ if (IS_ERR(tmp)) {
DP_DEBUG(dev, QEDR_MSG_MR, "Extra PBL is not allocated\n");
goto done;
}
--
2.9.3
Re: [PATCH v4 00/36] i.MX Media Driver
Hi Philipp and Russell, On Fri, Feb 17, 2017 at 04:04:30PM +0100, Philipp Zabel wrote: > On Fri, 2017-02-17 at 14:22 +0200, Sakari Ailus wrote: > > Hi Philipp, Steve and Russell, > > > > On Fri, Feb 17, 2017 at 12:43:38PM +0100, Philipp Zabel wrote: > > > On Thu, 2017-02-16 at 14:27 -0800, Steve Longerbeam wrote: > > > > > > > > On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote: > > > > > On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote: > > > > >> In version 4: > > > > > > > > > > With this version, I get: > > > > > > > > > > [28762.892053] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x > > > > > [28762.899409] ipu1_csi0: pipeline_set_stream failed with -110 > > > > > > > > > > > > > Right, in the imx219, on exit from s_power(), the clock and data lanes > > > > must be placed in the LP-11 state. This has been done in the ov5640 and > > > > tc358743 subdevs. > > > > > > > > If we want to bring in the patch that adds a .prepare_stream() op, > > > > the csi-2 bus would need to be placed in LP-11 in that op instead. > > > > > > > > Philipp, should I go ahead and add your .prepare_stream() patch? > > > > > > I think with Russell's explanation of how the imx219 sensor operates, > > > we'll have to do something before calling the sensor s_stream, but right > > > now I'm still unsure what exactly. > > > > Indeed there appears to be no other way to achieve the LP-11 state than > > going through the streaming state for this particular sensor, apart from > > starting streaming. > > > > Is there a particular reason why you're waiting for the transmitter to > > transfer to LP-11 state? That appears to be the last step which is done in > > the csi2_s_stream() callback. > > > > What the sensor does next is to start streaming, and the first thing it does > > in that process is to switch to LP-11 state. > > > > Have you tried what happens if you simply drop the LP-11 check? To me that > > would seem the right thing to do. > > Removing the wait for LP-11 alone might not be an issue in my case, as > the TC358743 is known to be in stop state all along. So I just have to > make sure that the time between s_stream(csi2) starting the receiver and > s_stream(tc358743) causing LP-11 to be changed to the next state is long > enough for the receiver to detect LP-11 (which I really can't, I just > have to pray I2C transmissions are slow enough). Fair enough; it appears that the timing of the bus setup is indeed ill defined between the transmitter and the receiver. So there can be hardware specific matters in stream starting that have to be taken into account. :-( This is quite annoying, as there does not appear to be a good way to tell the sensor to set the receiver to LP-11 state without going through the streaming state. If there was, just doing that in s_power(, 1) callback would be quite practical. I guess then there's no really a way to avoid having an extra callback that would explicitly tell the sensor to go to LP-11 state. It should be no issue if the transmitter is already in that state from power-on, but the new callback should guarantee that. Another question is that how far do you need to proceed with streaming in a case where you want to go to LP-11 through streaming? Is simply starting streaming and stopping it right after enough? On some devices it might be but not on others. As the receiver is not started yet, you can't wait for the first frame to start either. And how long it would take for the first frame to start is not defined either in general case: or a driver such as SMIA that's not exactly aware of the underlying hardware but is relying on a standard device interface and behaviour, such approach could be best effort only. Of course it's possible to make changes to the driver if you encounter a combination of a sensor and a receiver that doesn't seem to work, but still it's hardly an ideal solution. How about calling the new callback phy_prepare(), for instance? We could document that it must explicitly set up the transmitter PHY in LP-11 state for CSI-2. The current documentation states that the device should be already in LP-11 after power-on but that apparently is not the case in general. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
RE: [RFC 7/8] fpga-region: add sysfs interface
On February 17, 2017 6:30 PM, Moritz Fischer wrote: On Fri, Feb 17, 2017 at 04:28:37PM -0600, Yves Vandervennet wrote: > Moritz, > > whatever solution we decide to go with has to work with other OS'es. > The last thing we want to do is to have wrappers that are Linux specific. I do agree that we should make sure the format is reasonably well documented. In my earlier email I pointed out several projects successfully integrating libfdt. There's nothing Linux specific about libfdt. FreeBSD uses it, U-Boot, Qemu ... I know nothing about how windows kernel development works, but I assume however one goes about making FPGA programming work there, someone will most likely have to write a kernel mode driver to take the job of the fpga-mgr framework. I assume this will be written in C or C++ or whatever people use these days for kernel development so pulling in libfdt shouldn't be too hard if we were to try that. To be clear: I did not suggest fdt to make it hard for other OSs, or because this is my personal pet project. I think we're more likely to get it right by reusing an existing format, with parsers that other people already successfully use. It does not have to be fdt (I suggested that because that was around), but I do think we certainly can do better than HTTP-eque plaintext headers. Thanks, Moritz -- To unsubscribe from this list: send the line "unsubscribe linux-fpga" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi all, Interesting discussion. The discussion so far has brought out many concerns such as OS independence. There is an existing format, well-known to developers, with widespread support, and which is quite extensible: Type-Length-Value triples. To elaborate, a TLV-based format has many advantages: * It is highly extensible in many ways -- You can express structures and arrays using TLVs. Our needs right now may seem limited but requirements grow over time. -- The space of Type values can be decomposed into standard pre-defined values that are in upstreamed code, and possibly experimental or feature-specific values. -- Forward compatibility: We can write parsers that can skip unexpected type values, thus allowing old parsers to work with new additions. With some tweaks, old parsers can also reject unexpected values in some ranges while accepting them in other ranges. * It is OS-independent. * It can be easily parsed, in kernel or user space. * It can be validated, in terms of Type values, acceptable lengths, etc. It is not directly human-readable but that can be easily addressed with a tool that parses TLVs. Compared to some other proposals: * Compared to DTs, TLVs are OS-independent. * Compared to strings as key-value pairs, TLVs can express structures/arrays, can be validated, etc. So, I suggest we use TLVs to express metadata in image files. Thank you very much, Sundar Nadathur
Re: [RFC v2 01/20] block: DAC960: Replace PCI pool old API
On Sat, Feb 18, 2017 at 09:35:37AM +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API.
>
no new errors added, tested by compilation only.
> Signed-off-by: Romain Perier
> Acked-by: Peter Senna Tschudin
> Tested-by: Peter Senna Tschudin
> ---
> drivers/block/DAC960.c | 36 ++--
> drivers/block/DAC960.h | 4 ++--
> 2 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c
> index 26a51be..2b221cc 100644
> --- a/drivers/block/DAC960.c
> +++ b/drivers/block/DAC960.c
> @@ -268,17 +268,17 @@ static bool
> DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
>void *AllocationPointer = NULL;
>void *ScatterGatherCPU = NULL;
>dma_addr_t ScatterGatherDMA;
> - struct pci_pool *ScatterGatherPool;
> + struct dma_pool *ScatterGatherPool;
>void *RequestSenseCPU = NULL;
>dma_addr_t RequestSenseDMA;
> - struct pci_pool *RequestSensePool = NULL;
> + struct dma_pool *RequestSensePool = NULL;
>
>if (Controller->FirmwareType == DAC960_V1_Controller)
> {
>CommandAllocationLength = offsetof(DAC960_Command_T, V1.EndMarker);
>CommandAllocationGroupSize = DAC960_V1_CommandAllocationGroupSize;
> - ScatterGatherPool = pci_pool_create("DAC960_V1_ScatterGather",
> - Controller->PCIDevice,
> + ScatterGatherPool = dma_pool_create("DAC960_V1_ScatterGather",
> + &Controller->PCIDevice->dev,
> DAC960_V1_ScatterGatherLimit * sizeof(DAC960_V1_ScatterGatherSegment_T),
> sizeof(DAC960_V1_ScatterGatherSegment_T), 0);
>if (ScatterGatherPool == NULL)
> @@ -290,18 +290,18 @@ static bool
> DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
> {
>CommandAllocationLength = offsetof(DAC960_Command_T, V2.EndMarker);
>CommandAllocationGroupSize = DAC960_V2_CommandAllocationGroupSize;
> - ScatterGatherPool = pci_pool_create("DAC960_V2_ScatterGather",
> - Controller->PCIDevice,
> + ScatterGatherPool = dma_pool_create("DAC960_V2_ScatterGather",
> + &Controller->PCIDevice->dev,
> DAC960_V2_ScatterGatherLimit * sizeof(DAC960_V2_ScatterGatherSegment_T),
> sizeof(DAC960_V2_ScatterGatherSegment_T), 0);
>if (ScatterGatherPool == NULL)
> return DAC960_Failure(Controller,
> "AUXILIARY STRUCTURE CREATION (SG)");
> - RequestSensePool = pci_pool_create("DAC960_V2_RequestSense",
> - Controller->PCIDevice, sizeof(DAC960_SCSI_RequestSense_T),
> + RequestSensePool = dma_pool_create("DAC960_V2_RequestSense",
> + &Controller->PCIDevice->dev, sizeof(DAC960_SCSI_RequestSense_T),
> sizeof(int), 0);
>if (RequestSensePool == NULL) {
> - pci_pool_destroy(ScatterGatherPool);
> + dma_pool_destroy(ScatterGatherPool);
> return DAC960_Failure(Controller,
> "AUXILIARY STRUCTURE CREATION (SG)");
>}
> @@ -335,16 +335,16 @@ static bool
> DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
>Command->Next = Controller->FreeCommands;
>Controller->FreeCommands = Command;
>Controller->Commands[CommandIdentifier-1] = Command;
> - ScatterGatherCPU = pci_pool_alloc(ScatterGatherPool, GFP_ATOMIC,
> + ScatterGatherCPU = dma_pool_alloc(ScatterGatherPool, GFP_ATOMIC,
> &ScatterGatherDMA);
>if (ScatterGatherCPU == NULL)
> return DAC960_Failure(Controller, "AUXILIARY STRUCTURE CREATION");
>
>if (RequestSensePool != NULL) {
> - RequestSenseCPU = pci_pool_alloc(RequestSensePool, GFP_ATOMIC,
> + RequestSenseCPU = dma_pool_alloc(RequestSensePool, GFP_ATOMIC,
> &RequestSenseDMA);
> if (RequestSenseCPU == NULL) {
> -pci_pool_free(ScatterGatherPool, ScatterGatherCPU,
> +dma_pool_free(ScatterGatherPool, ScatterGatherCPU,
> ScatterGatherDMA);
> return DAC960_Failure(Controller,
> "AUXILIARY STRUCTURE CREATION");
> @@ -379,8 +379,8 @@ static bool
> DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
> static void DAC960_DestroyAuxiliaryStructures(DAC960_Controller_T
> *Controller)
> {
>int i;
> - struct pci_pool *ScatterGatherPool = Controller->ScatterGatherPool;
> - struct pci_pool *RequestSensePool = NULL;
> + struct dma_pool *ScatterGatherPool = Controller->ScatterGatherPool;
> + struct dma_pool *RequestSensePool = NULL;
>void *ScatterGatherCPU;
>dma_addr_t ScatterGatherDMA;
>void *RequestSenseCPU;
> @@ -411,9 +411,9 @@ static void
> DAC960_DestroyAuxiliaryStructures(DAC960_Controller_T *Controller)
> RequestS
[PATCH 2/6] staging: rtl8192e: Remove CamelCase
This patch renames pBA to pba to avoid camelcase.
Signed-off-by: simran singhal
---
drivers/staging/rtl8192e/rtl819x_BAProc.c | 100 +++---
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_BAProc.c
b/drivers/staging/rtl8192e/rtl819x_BAProc.c
index bdbd21c..e51ec16 100644
--- a/drivers/staging/rtl8192e/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_BAProc.c
@@ -18,18 +18,18 @@
#include "rtllib.h"
#include "rtl819x_BA.h"
-static void ActivateBAEntry(struct rtllib_device *ieee, struct ba_record *pBA,
+static void ActivateBAEntry(struct rtllib_device *ieee, struct ba_record *pba,
u16 Time)
{
- pBA->bValid = true;
+ pba->bValid = true;
if (Time != 0)
- mod_timer(&pBA->Timer, jiffies + msecs_to_jiffies(Time));
+ mod_timer(&pba->Timer, jiffies + msecs_to_jiffies(Time));
}
-static void DeActivateBAEntry(struct rtllib_device *ieee, struct ba_record
*pBA)
+static void DeActivateBAEntry(struct rtllib_device *ieee, struct ba_record
*pba)
{
- pBA->bValid = false;
- del_timer_sync(&pBA->Timer);
+ pba->bValid = false;
+ del_timer_sync(&pba->Timer);
}
static u8 TxTsDeleteBA(struct rtllib_device *ieee, struct tx_ts_record *pTxTs)
@@ -63,16 +63,16 @@ static u8 RxTsDeleteBA(struct rtllib_device *ieee, struct
rx_ts_record *pRxTs)
return bSendDELBA;
}
-void ResetBaEntry(struct ba_record *pBA)
+void ResetBaEntry(struct ba_record *pba)
{
- pBA->bValid = false;
- pBA->BaParamSet.shortData = 0;
- pBA->BaTimeoutValue = 0;
- pBA->DialogToken= 0;
- pBA->BaStartSeqCtrl.ShortData = 0;
+ pba->bValid = false;
+ pba->BaParamSet.shortData = 0;
+ pba->BaTimeoutValue = 0;
+ pba->DialogToken= 0;
+ pba->BaStartSeqCtrl.ShortData = 0;
}
static struct sk_buff *rtllib_ADDBA(struct rtllib_device *ieee, u8 *Dst,
- struct ba_record *pBA,
+ struct ba_record *pba,
u16 StatusCode, u8 type)
{
struct sk_buff *skb = NULL;
@@ -83,8 +83,8 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device
*ieee, u8 *Dst,
netdev_dbg(ieee->dev, "%s(): frame(%d) sentd to: %pM, ieee->dev:%p\n",
__func__, type, Dst, ieee->dev);
- if (!pBA) {
- netdev_warn(ieee->dev, "pBA is NULL\n");
+ if (!pba) {
+ netdev_warn(ieee->dev, "pba is NULL\n");
return NULL;
}
skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
@@ -107,7 +107,7 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device
*ieee, u8 *Dst,
tag = (u8 *)skb_put(skb, 9);
*tag++ = ACT_CAT_BA;
*tag++ = type;
- *tag++ = pBA->DialogToken;
+ *tag++ = pba->DialogToken;
if (type == ACT_ADDBARSP) {
RT_TRACE(COMP_DBG, ">to send ADDBARSP\n");
@@ -116,14 +116,14 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device
*ieee, u8 *Dst,
tag += 2;
}
- put_unaligned_le16(pBA->BaParamSet.shortData, tag);
+ put_unaligned_le16(pba->BaParamSet.shortData, tag);
tag += 2;
- put_unaligned_le16(pBA->BaTimeoutValue, tag);
+ put_unaligned_le16(pba->BaTimeoutValue, tag);
tag += 2;
if (type == ACT_ADDBAREQ) {
- memcpy(tag, (u8 *)&(pBA->BaStartSeqCtrl), 2);
+ memcpy(tag, (u8 *)&(pba->BaStartSeqCtrl), 2);
tag += 2;
}
@@ -135,7 +135,7 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device
*ieee, u8 *Dst,
}
static struct sk_buff *rtllib_DELBA(struct rtllib_device *ieee, u8 *dst,
- struct ba_record *pBA,
+ struct ba_record *pba,
enum tr_select TxRxSelect, u16 ReasonCode)
{
union delba_param_set DelbaParamSet;
@@ -151,7 +151,7 @@ static struct sk_buff *rtllib_DELBA(struct rtllib_device
*ieee, u8 *dst,
memset(&DelbaParamSet, 0, 2);
DelbaParamSet.field.Initiator = (TxRxSelect == TX_DIR) ? 1 : 0;
- DelbaParamSet.field.TID = pBA->BaParamSet.field.TID;
+ DelbaParamSet.field.TID = pba->BaParamSet.field.TID;
skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
if (!skb)
@@ -187,11 +187,11 @@ static struct sk_buff *rtllib_DELBA(struct rtllib_device
*ieee, u8 *dst,
}
static void rtllib_send_ADDBAReq(struct rtllib_device *ieee, u8 *dst,
-struct ba_record *pBA)
+struct ba_record *pba)
{
struct sk_buff *skb;
- skb = rtllib_ADDBA(ieee, dst, pBA, 0, ACT_ADDBAREQ);
+ skb = rtllib_ADDBA(ieee, dst, pba,
Re: [Outreachy kernel] [PATCH 2/6] staging: rtl8192e: Remove CamelCase
On Sat, 18 Feb 2017, simran singhal wrote:
> This patch renames pBA to pba to avoid camelcase.
I think that this was tried in the last round and was rejected, because BA
is meaningful. You also see BA in the name of a header file. The kind of
camel case that one should remove is whenTextIsWrittenLikeThis.
julia
>
> Signed-off-by: simran singhal
> ---
> drivers/staging/rtl8192e/rtl819x_BAProc.c | 100
> +++---
> 1 file changed, 50 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl819x_BAProc.c
> b/drivers/staging/rtl8192e/rtl819x_BAProc.c
> index bdbd21c..e51ec16 100644
> --- a/drivers/staging/rtl8192e/rtl819x_BAProc.c
> +++ b/drivers/staging/rtl8192e/rtl819x_BAProc.c
> @@ -18,18 +18,18 @@
> #include "rtllib.h"
> #include "rtl819x_BA.h"
>
> -static void ActivateBAEntry(struct rtllib_device *ieee, struct ba_record
> *pBA,
> +static void ActivateBAEntry(struct rtllib_device *ieee, struct ba_record
> *pba,
> u16 Time)
> {
> - pBA->bValid = true;
> + pba->bValid = true;
> if (Time != 0)
> - mod_timer(&pBA->Timer, jiffies + msecs_to_jiffies(Time));
> + mod_timer(&pba->Timer, jiffies + msecs_to_jiffies(Time));
> }
>
> -static void DeActivateBAEntry(struct rtllib_device *ieee, struct ba_record
> *pBA)
> +static void DeActivateBAEntry(struct rtllib_device *ieee, struct ba_record
> *pba)
> {
> - pBA->bValid = false;
> - del_timer_sync(&pBA->Timer);
> + pba->bValid = false;
> + del_timer_sync(&pba->Timer);
> }
>
> static u8 TxTsDeleteBA(struct rtllib_device *ieee, struct tx_ts_record
> *pTxTs)
> @@ -63,16 +63,16 @@ static u8 RxTsDeleteBA(struct rtllib_device *ieee, struct
> rx_ts_record *pRxTs)
> return bSendDELBA;
> }
>
> -void ResetBaEntry(struct ba_record *pBA)
> +void ResetBaEntry(struct ba_record *pba)
> {
> - pBA->bValid = false;
> - pBA->BaParamSet.shortData = 0;
> - pBA->BaTimeoutValue = 0;
> - pBA->DialogToken= 0;
> - pBA->BaStartSeqCtrl.ShortData = 0;
> + pba->bValid = false;
> + pba->BaParamSet.shortData = 0;
> + pba->BaTimeoutValue = 0;
> + pba->DialogToken= 0;
> + pba->BaStartSeqCtrl.ShortData = 0;
> }
> static struct sk_buff *rtllib_ADDBA(struct rtllib_device *ieee, u8 *Dst,
> - struct ba_record *pBA,
> + struct ba_record *pba,
> u16 StatusCode, u8 type)
> {
> struct sk_buff *skb = NULL;
> @@ -83,8 +83,8 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device
> *ieee, u8 *Dst,
> netdev_dbg(ieee->dev, "%s(): frame(%d) sentd to: %pM, ieee->dev:%p\n",
> __func__, type, Dst, ieee->dev);
>
> - if (!pBA) {
> - netdev_warn(ieee->dev, "pBA is NULL\n");
> + if (!pba) {
> + netdev_warn(ieee->dev, "pba is NULL\n");
> return NULL;
> }
> skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
> @@ -107,7 +107,7 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device
> *ieee, u8 *Dst,
> tag = (u8 *)skb_put(skb, 9);
> *tag++ = ACT_CAT_BA;
> *tag++ = type;
> - *tag++ = pBA->DialogToken;
> + *tag++ = pba->DialogToken;
>
> if (type == ACT_ADDBARSP) {
> RT_TRACE(COMP_DBG, ">to send ADDBARSP\n");
> @@ -116,14 +116,14 @@ static struct sk_buff *rtllib_ADDBA(struct
> rtllib_device *ieee, u8 *Dst,
> tag += 2;
> }
>
> - put_unaligned_le16(pBA->BaParamSet.shortData, tag);
> + put_unaligned_le16(pba->BaParamSet.shortData, tag);
> tag += 2;
>
> - put_unaligned_le16(pBA->BaTimeoutValue, tag);
> + put_unaligned_le16(pba->BaTimeoutValue, tag);
> tag += 2;
>
> if (type == ACT_ADDBAREQ) {
> - memcpy(tag, (u8 *)&(pBA->BaStartSeqCtrl), 2);
> + memcpy(tag, (u8 *)&(pba->BaStartSeqCtrl), 2);
> tag += 2;
> }
>
> @@ -135,7 +135,7 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device
> *ieee, u8 *Dst,
> }
>
> static struct sk_buff *rtllib_DELBA(struct rtllib_device *ieee, u8 *dst,
> - struct ba_record *pBA,
> + struct ba_record *pba,
> enum tr_select TxRxSelect, u16 ReasonCode)
> {
> union delba_param_set DelbaParamSet;
> @@ -151,7 +151,7 @@ static struct sk_buff *rtllib_DELBA(struct rtllib_device
> *ieee, u8 *dst,
> memset(&DelbaParamSet, 0, 2);
>
> DelbaParamSet.field.Initiator = (TxRxSelect == TX_DIR) ? 1 : 0;
> - DelbaParamSet.field.TID = pBA->BaParamSet.field.TID;
> + DelbaParamSet.field.TID = pba->BaParamSet.field.TID;
>
> skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
> if (!skb)
> @@ -187,11 +187,11 @@ static struct sk_buff *rt
Re: [PATCH] Tty: serial - Fix possible NULL derefrence.
On Sat, Feb 18, 2017 at 11:25:19AM +0100, Maarten Brock wrote: > Hello Greg, > > Does that also mean that this isn't possible in the sc16is7xx.c driver in > sc16is7xx_spi_probe() line 1358 and sc16is7xx_i2c_probe() line 1419 ? > > If so, should these checks be removed? Probably.
Re: [RFC v2 00/20] Replace PCI pool by DMA pool API
On Sat, Feb 18, 2017 at 09:35:36AM +0100, Romain Perier wrote: > The current PCI pool API are simple macro functions direct expanded to > the appropriated dma pool functions. The prototypes are almost the same > and semantically, they are very similar. I propose to use the DMA pool > API directly and get rid of the old API. > > This set of patches, replaces the old API by the dma pool API, adds > support to warn about this old API in checkpath.pl and remove the > defines. Why is this a "RFC" series? Personally, I never apply those as it implies that the author doesn't think they are ready to be merged :) thanks, greg k-h
Re: [Outreachy kernel] [PATCH 1/6] staging: rtl8192e: Replaced comparison to NULL statements
On Sat, 18 Feb 2017, simran singhal wrote:
> This patch corrects check generated by checkpatch.pl by
There is not much information in the first line. Use the imperative:
Replace comparisons to NULL by ...
> replacing comparison to null statements with equivalent
> statements in the form of "!x".
Actually, they are expressions. An expression returns a value. A
statement is performed for its side effects only.
julia
> Signed-off-by: simran singhal
> ---
> drivers/staging/rtl8192e/rtl819x_BAProc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl819x_BAProc.c
> b/drivers/staging/rtl8192e/rtl819x_BAProc.c
> index 20260af..bdbd21c 100644
> --- a/drivers/staging/rtl8192e/rtl819x_BAProc.c
> +++ b/drivers/staging/rtl8192e/rtl819x_BAProc.c
> @@ -83,12 +83,12 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device
> *ieee, u8 *Dst,
> netdev_dbg(ieee->dev, "%s(): frame(%d) sentd to: %pM, ieee->dev:%p\n",
> __func__, type, Dst, ieee->dev);
>
> - if (pBA == NULL) {
> + if (!pBA) {
> netdev_warn(ieee->dev, "pBA is NULL\n");
> return NULL;
> }
> skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
> - if (skb == NULL)
> + if (!skb)
> return NULL;
>
> memset(skb->data, 0, sizeof(struct rtllib_hdr_3addr));
> @@ -154,7 +154,7 @@ static struct sk_buff *rtllib_DELBA(struct rtllib_device
> *ieee, u8 *dst,
> DelbaParamSet.field.TID = pBA->BaParamSet.field.TID;
>
> skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
> - if (skb == NULL)
> + if (!skb)
> return NULL;
>
> skb_reserve(skb, ieee->tx_headroom);
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20170218071115.GA10540%40singhal-Inspiron-5558.
> For more options, visit https://groups.google.com/d/optout.
>
[PATCH] staging: xgifb: function definition argument should also have an identifier name'
function definition argument 'struct vb_device_info *' and 'unsigned long' should also have an identifier name. Signed-off-by: Arushi Singhal --- drivers/staging/xgifb/vb_init.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/xgifb/vb_init.h b/drivers/staging/xgifb/vb_init.h index 500cabe41a3c..e4929314d33e 100644 --- a/drivers/staging/xgifb/vb_init.h +++ b/drivers/staging/xgifb/vb_init.h @@ -1,6 +1,6 @@ #ifndef _VBINIT_ #define _VBINIT_ unsigned char XGIInitNew(struct pci_dev *pdev); -void XGIRegInit(struct vb_device_info *, unsigned long); +void XGIRegInit(struct vb_device_info *pVBInfo, unsigned long BaseAddr); #endif -- 2.11.0
Re: [Outreachy kernel] [PATCH] staging: xgifb: function definition argument should also have an identifier name'
On Sat, 18 Feb 2017, Arushi Singhal wrote: > function definition argument 'struct vb_device_info *' and 'unsigned > long' should also have an identifier name. This could be a bit more clear as "Add variable names to function prototype parameter list." > > Signed-off-by: Arushi Singhal > --- > drivers/staging/xgifb/vb_init.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/xgifb/vb_init.h b/drivers/staging/xgifb/vb_init.h > index 500cabe41a3c..e4929314d33e 100644 > --- a/drivers/staging/xgifb/vb_init.h > +++ b/drivers/staging/xgifb/vb_init.h > @@ -1,6 +1,6 @@ > #ifndef _VBINIT_ > #define _VBINIT_ > unsigned char XGIInitNew(struct pci_dev *pdev); > -void XGIRegInit(struct vb_device_info *, unsigned long); > +void XGIRegInit(struct vb_device_info *pVBInfo, unsigned long BaseAddr); Actually, you should use the same names as found in the definition of the function, which seem to be: void XGIRegInit(struct vb_device_info *XGI_Pr, unsigned long BaseAddr) julia > #endif > > -- > 2.11.0 > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20170218132356.GA4907%40arushi-HP-Pavilion-Notebook. > For more options, visit https://groups.google.com/d/optout. >
Re: [PATCH v2 3/3] Make vmbus register arguments read-only (fwd)
It looks like brace are missing on the if on lines 1057-1059.
julia
-- Forwarded message --
Date: Sat, 18 Feb 2017 15:46:30 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: Re: [PATCH v2 3/3] Make vmbus register arguments read-only
CC: kbuild-...@01.org
In-Reply-To: <20170218055844.1457-4-...@edkovsky.org>
Hi Eddie,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8 next-20170217]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Eddie-Kovsky/provide-check-for-ro_after_init-memory-sections/20170218-141040
:: branch date: 2 hours ago
:: commit date: 2 hours ago
>> drivers/hv/vmbus_drv.c:1058:2-45: code aligned with following code on line
>> 1059
drivers/hv/vmbus_drv.c:1129:2-45: code aligned with following code on line
1130
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 1fed72d7adca008d13119f00c095e1e379f319a1
vim +1058 drivers/hv/vmbus_drv.c
cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan 2011-12-01 1052
ret = vmbus_exists();
cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan 2011-12-01 1053
if (ret < 0)
cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan 2011-12-01 1054
return ret;
cf6a2eac drivers/hv/vmbus_drv.c K. Y. Srinivasan 2011-12-01 1055
1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky 2017-02-17 1056
ret = kernel_ro_address(&hv_driver);
1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky 2017-02-17 1057
if (ret < 1)
1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky 2017-02-17 @1058
pr_err("Module address is not read-only.");
1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky 2017-02-17 @1059
return ret;
1fed72d7 drivers/hv/vmbus_drv.c Eddie Kovsky 2017-02-17 1060
768fa219 drivers/staging/hv/vmbus_drv.c Greg Kroah-Hartman 2011-08-25 1061
hv_driver->driver.name = hv_driver->name;
768fa219 drivers/staging/hv/vmbus_drv.c Greg Kroah-Hartman 2011-08-25 1062
hv_driver->driver.owner = owner;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH] staging: xgifb: function definition argument should also have an identifier name'
function definition argument 'struct vb_device_info *' and 'unsigned long' should also have an identifier name. Signed-off-by: Arushi Singhal --- drivers/staging/xgifb/vb_init.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/xgifb/vb_init.h b/drivers/staging/xgifb/vb_init.h index 500cabe41a3c..e835054b87bf 100644 --- a/drivers/staging/xgifb/vb_init.h +++ b/drivers/staging/xgifb/vb_init.h @@ -1,6 +1,5 @@ #ifndef _VBINIT_ #define _VBINIT_ unsigned char XGIInitNew(struct pci_dev *pdev); -void XGIRegInit(struct vb_device_info *, unsigned long); +void XGIRegInit(struct vb_device_info *XGI_Pr, unsigned long BaseAddr); #endif - -- 2.11.0
[PATCH v2 1/6] staging: rtl8192e: Replaced comparison to NULL statements
This patch removes the explicit NULL comparison. This issue was found by
checkpatch.
Signed-off-by: simran singhal
---
v2:
-Modified commit message
drivers/staging/rtl8192e/rtl819x_BAProc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_BAProc.c
b/drivers/staging/rtl8192e/rtl819x_BAProc.c
index 20260af..bdbd21c 100644
--- a/drivers/staging/rtl8192e/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_BAProc.c
@@ -83,12 +83,12 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device
*ieee, u8 *Dst,
netdev_dbg(ieee->dev, "%s(): frame(%d) sentd to: %pM, ieee->dev:%p\n",
__func__, type, Dst, ieee->dev);
- if (pBA == NULL) {
+ if (!pBA) {
netdev_warn(ieee->dev, "pBA is NULL\n");
return NULL;
}
skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
- if (skb == NULL)
+ if (!skb)
return NULL;
memset(skb->data, 0, sizeof(struct rtllib_hdr_3addr));
@@ -154,7 +154,7 @@ static struct sk_buff *rtllib_DELBA(struct rtllib_device
*ieee, u8 *dst,
DelbaParamSet.field.TID = pBA->BaParamSet.field.TID;
skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
- if (skb == NULL)
+ if (!skb)
return NULL;
skb_reserve(skb, ieee->tx_headroom);
--
2.7.4
Re: [Outreachy kernel] [PATCH v2 1/6] staging: rtl8192e: Replaced comparison to NULL statements
On Sat, 18 Feb 2017, simran singhal wrote:
> This patch removes the explicit NULL comparison. This issue was found by
> checkpatch.
>
> Signed-off-by: simran singhal
Acked-by: Julia Lawall
> ---
>
> v2:
>-Modified commit message
>
> drivers/staging/rtl8192e/rtl819x_BAProc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl819x_BAProc.c
> b/drivers/staging/rtl8192e/rtl819x_BAProc.c
> index 20260af..bdbd21c 100644
> --- a/drivers/staging/rtl8192e/rtl819x_BAProc.c
> +++ b/drivers/staging/rtl8192e/rtl819x_BAProc.c
> @@ -83,12 +83,12 @@ static struct sk_buff *rtllib_ADDBA(struct rtllib_device
> *ieee, u8 *Dst,
> netdev_dbg(ieee->dev, "%s(): frame(%d) sentd to: %pM, ieee->dev:%p\n",
> __func__, type, Dst, ieee->dev);
>
> - if (pBA == NULL) {
> + if (!pBA) {
> netdev_warn(ieee->dev, "pBA is NULL\n");
> return NULL;
> }
> skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
> - if (skb == NULL)
> + if (!skb)
> return NULL;
>
> memset(skb->data, 0, sizeof(struct rtllib_hdr_3addr));
> @@ -154,7 +154,7 @@ static struct sk_buff *rtllib_DELBA(struct rtllib_device
> *ieee, u8 *dst,
> DelbaParamSet.field.TID = pBA->BaParamSet.field.TID;
>
> skb = dev_alloc_skb(len + sizeof(struct rtllib_hdr_3addr));
> - if (skb == NULL)
> + if (!skb)
> return NULL;
>
> skb_reserve(skb, ieee->tx_headroom);
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20170218134248.GA21186%40singhal-Inspiron-5558.
> For more options, visit https://groups.google.com/d/optout.
>
[PATCH v2] staging: xgifb: function definition argument should also have an identifier name'
function definition argument 'struct vb_device_info *' and 'unsigned long' should also have an identifier name. Signed-off-by: Arushi Singhal --- drivers/staging/xgifb/vb_init.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/xgifb/vb_init.h b/drivers/staging/xgifb/vb_init.h index 500cabe41a3c..e835054b87bf 100644 --- a/drivers/staging/xgifb/vb_init.h +++ b/drivers/staging/xgifb/vb_init.h @@ -1,6 +1,5 @@ #ifndef _VBINIT_ #define _VBINIT_ unsigned char XGIInitNew(struct pci_dev *pdev); -void XGIRegInit(struct vb_device_info *, unsigned long); +void XGIRegInit(struct vb_device_info *XGI_Pr, unsigned long BaseAddr); #endif - -- 2.11.0
Re: [Outreachy kernel] [PATCH] staging: xgifb: function definition argument should also have an identifier name'
On Sat, 18 Feb 2017, Arushi Singhal wrote: > function definition argument 'struct vb_device_info *' and 'unsigned > long' should also have an identifier name. > > Signed-off-by: Arushi Singhal Acked-by: Julia Lawall > --- > drivers/staging/xgifb/vb_init.h | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/staging/xgifb/vb_init.h b/drivers/staging/xgifb/vb_init.h > index 500cabe41a3c..e835054b87bf 100644 > --- a/drivers/staging/xgifb/vb_init.h > +++ b/drivers/staging/xgifb/vb_init.h > @@ -1,6 +1,5 @@ > #ifndef _VBINIT_ > #define _VBINIT_ > unsigned char XGIInitNew(struct pci_dev *pdev); > -void XGIRegInit(struct vb_device_info *, unsigned long); > +void XGIRegInit(struct vb_device_info *XGI_Pr, unsigned long BaseAddr); > #endif > - > -- > 2.11.0 > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20170218134004.GA5075%40arushi-HP-Pavilion-Notebook. > For more options, visit https://groups.google.com/d/optout. >
Re: [PATCH 4/4] ARM: davinci: add pdata-quirks for da850-evm vpif display
Hi Bartosz,
[auto build test ERROR on arm-soc/for-next]
[also build test ERROR on next-20170217]
[cannot apply to v4.10-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Bartosz-Golaszewski/ARM-davinci-vpif-capture-display-support/20170217-044437
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
config: arm-davinci_all_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/mach-davinci/pdata-quirks.c: In function 'da850_vpif_legacy_init':
>> arch/arm/mach-davinci/pdata-quirks.c:184:38: error:
>> 'da850_vpif_display_config' undeclared (first use in this function)
ret = da850_register_vpif_display(&da850_vpif_display_config);
^
arch/arm/mach-davinci/pdata-quirks.c:184:38: note: each undeclared
identifier is reported only once for each function it appears in
vim +/da850_vpif_display_config +184 arch/arm/mach-davinci/pdata-quirks.c
178 if (ret)
179 pr_warn("%s: VPIF capture setup failed: %d\n",
180 __func__, ret);
181
182 /* LCDK doesn't support VPIF display */
183 if (of_machine_is_compatible("ti,da850-evm")) {
> 184 ret =
> da850_register_vpif_display(&da850_vpif_display_config);
185 if (ret)
186 pr_warn("%s: VPIF display setup failed: %d\n",
187 __func__, ret);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] DTS: Linksys Board: Add default trigger for sata led
Hi Ansuel,
On Fri, Feb 17, 2017 at 09:42:17PM +0100, Ansuel Smith wrote:
> In others board we have the sata led set to funcion with the sata led trigger
> by default.
> This patch makes the same for these board that have sata led but disabled by
> not associating it to any trigger
Please line wrap the commit message. Other than that,
>
> Signed-off-by: Ansuel Smith
Acked-by: Jason Cooper
thx,
Jason.
> ---
> arch/arm/boot/dts/armada-385-linksys-caiman.dts | 1 +
> arch/arm/boot/dts/armada-385-linksys-cobra.dts | 1 +
> arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 1 +
> 3 files changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-385-linksys-caiman.dts
> b/arch/arm/boot/dts/armada-385-linksys-caiman.dts
> index f3cee91..a1b6e68 100644
> --- a/arch/arm/boot/dts/armada-385-linksys-caiman.dts
> +++ b/arch/arm/boot/dts/armada-385-linksys-caiman.dts
> @@ -109,6 +109,7 @@
>
> sata {
> label = "caiman:white:sata";
> + linux,default-trigger = "disk-activity";
> };
> };
> };
> diff --git a/arch/arm/boot/dts/armada-385-linksys-cobra.dts
> b/arch/arm/boot/dts/armada-385-linksys-cobra.dts
> index 1110718..a1a75af 100644
> --- a/arch/arm/boot/dts/armada-385-linksys-cobra.dts
> +++ b/arch/arm/boot/dts/armada-385-linksys-cobra.dts
> @@ -109,6 +109,7 @@
>
> sata {
> label = "cobra:white:sata";
> + linux,default-trigger = "disk-activity";
> };
> };
> };
> diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> index 83ac884..dcd73ab 100644
> --- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> +++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> @@ -156,6 +156,7 @@
> esata@4 {
> label = "mamba:white:esata";
> reg = <0x4>;
> + linux,default-trigger =
> "disk-activity";
> };
>
> usb2@5 {
> --
> 1.9.1
>
Re: next_tick hang was Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot
On Sat, Feb 18, 2017 at 10:39:17AM +0100, Pavel Machek wrote: > Hi! > > [I droped some CCs here, you may want to check the CC list]. Good! > > > > These are different bugs. > > > > > > On x60, I see failures doing hotplug/unplug in a loop, or lot of > > > suspends. Someone seen it in v4.8-stable etc. Old bug. Rare to hit. > > > > > > Desktop machine was failing to boot, and had some fun with > > > suspend/resume too. Boot hang was reproducible with right > > > procedure. (Hard poweroff, cold boot.). That one was introduced in > > > 4.10-rc cycle. > > > > Pavel, is there any chance you could apply this patch on top of latest > > linus tree > > and send me your resulting dmesg log? This has the two reverted patches > > plus some > > debugging code. The amount of printk shouldn't be too big, I tested it home > > without > > issue. > > > > If you can't manage to dump the dmesg, please try to take a picture of your > > screen > > so that I can see the last messages starting with "NEXT_TICK_READ". > > > > Thanks! > > I guess I can. But I'll only have one 80x25 screen to look at... > > .config is attached. Ah this is x86-32, interesting! I'm going to try to boot that, we never know. Thanks a lot!
Re: [PATCH] Input: tsc2007 - switch to using input_set_capability()
Hi Dmitry, > Am 17.02.2017 um 23:56 schrieb Dmitry Torokhov : > > Do not manipulate evbit/keybit directly, use helper for that. > > Signed-off-by: Dmitry Torokhov > --- > drivers/input/touchscreen/tsc2007_core.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/input/touchscreen/tsc2007_core.c > b/drivers/input/touchscreen/tsc2007_core.c > index fdf81a2b989a..98dbefc3357d 100644 > --- a/drivers/input/touchscreen/tsc2007_core.c > +++ b/drivers/input/touchscreen/tsc2007_core.c > @@ -364,8 +364,7 @@ static int tsc2007_probe(struct i2c_client *client, > > input_set_drvdata(input_dev, ts); > > - input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS); > - input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH); > + input_set_capability(input_dev, EV_KEY, BTN_TOUCH); basically a good improvement, but removing the BIT_MASK(EV_ABS) makes problems when replacing the next lines > > input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, ts->fuzzx, 0); > input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, ts->fuzzy, 0); by touchscreen_parse_properties() as done by my patch set. The problem is that touchscreen_parse_properties() does not call input_set_abs_params() but touchscreen_set_params(). This does not call some input_set_capability(dev, EV_ABS, axis) but rather checks that it has been set before! Hence we only see warnings in the log and no input event properties (BTN_TOUCH works but without position information). So we either must explicitly input_set_capability(dev, EV_ABS, axis) for all three axises or remove the test in touchscreen_set_params and call input_set_capability(dev, EV_ABS, axis); in the end. This patch improves the existing driver but breaks my tsc2007 patch set in a location that my patch set does not even touch (touchscreen_set_params). Scratching my head how to come out of this... BR and thanks, Nikolaus
Re: RFC: Getting rid of LTR in VMX
On 18/02/2017 04:29, Andy Lutomirski wrote: > There's no code here because the patch is trivial, but I want to run > the idea by you all first to see if there are any issues. > > VMX is silly and forces the TSS limit to the minimum on VM exits. KVM > wastes lots of cycles bumping it back up to accomodate the io bitmap. > > I propose that we rework this. Add a percpu variable that indicates > whether the TSS limit needs to be refreshed. On task switch, if the > new task has TIF_IO_BITMAP set, then check that flag and, if set, > refresh TR and clear the flag. On VMX exit, set the flag. That's nice. An alternative is to just use the user return notifier, which does not need any global change. This is even simpler and can be used to benchmark. > The TSS limit is (phew!) invisible to userspace, so we don't have ABI > issues to worry about here. We also shouldn't have security issues > because a too-low TSS limit just results in unprivileged IO operations > generating #GP, which is exactly what we want. > > What do you all think? I expect a speedup of a couple hundred cycles > on each VM exit. >
Re: [PATCH] mtd: spi-nor: hisi: do not ignore clk_prepare_enable() failure
On 02/17/2017 11:08 PM, Alexey Khoroshilov wrote: > hisi_spi_nor_probe() ignores clk_prepare_enable() error code. > The patch fixes that. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Acked-by: Marek Vasut > --- > drivers/mtd/spi-nor/hisi-sfc.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/spi-nor/hisi-sfc.c > index 20378b0d55e9..a286350627a6 100644 > --- a/drivers/mtd/spi-nor/hisi-sfc.c > +++ b/drivers/mtd/spi-nor/hisi-sfc.c > @@ -448,8 +448,11 @@ static int hisi_spi_nor_probe(struct platform_device > *pdev) > if (!host->buffer) > return -ENOMEM; > > + ret = clk_prepare_enable(host->clk); > + if (ret) > + return ret; > + > mutex_init(&host->lock); > - clk_prepare_enable(host->clk); > hisi_spi_nor_init(host); > ret = hisi_spi_nor_register_all(host); > if (ret) > -- Best regards, Marek Vasut
Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
Guys, please fix the 0day bot reporting. See below for more info. On Sat, Feb 18, 2017 at 01:01:53PM +0800, Fengguang Wu wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://github.com/0day-ci/linux > Borislav-Petkov/x86-Optimize-clear_page/20170210-053052 Can you make this point to the actual commit on github? Your tree there has currently 47K branches and navigating through the web interface takes forever. > commit 0ad07c8104eb5c12dfcb86581c1cc657183496cc > Author: Borislav Petkov > AuthorDate: Thu Feb 9 20:51:25 2017 +0100 > Commit: 0day robot > CommitDate: Fri Feb 10 05:30:58 2017 +0800 > > x86: Optimize clear_page() > > Currently, we CALL clear_page() which then JMPs to the proper function > chosen by the alternatives. > > What we should do instead is CALL the proper function directly. (This > was something Ingo suggested a while ago). So let's do that. > > Measuring our favourite kernel build workload shows that there are no > significant changes in performance. > > ... > > Signed-off-by: Borislav Petkov Then, this is an old patch. You already sent me a bug report, I replied with a fix but you didn't test the fix. Instead you're sending the same old report. Here's the fix: https://lists.01.org/pipermail/lkp/2017-February/005573.html And the upstream submission of the new version: https://lkml.kernel.org/r/20170215111927.emdgxf2pide3k...@pd.tnic Please fix the bot to pay attention to replies. If there is a special way I should reply with a fix so that the bot retests with the same config, please let me know. In general, I think it would be a very cool idea to be able to reply to the bot and say, "Dear bot, can you test this fix ontop with the exact same guest, vm, kernel .config etc. That would be lovely. Thanks and keep up the good work! -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
[PATCH 3/6] staging: rtl8192e: Fix block comments warning
Align * on a line, to conform to the kernal coding style for block comments. Signed-off-by: simran singhal --- drivers/staging/rtl8192e/rtl819x_HT.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192e/rtl819x_HT.h b/drivers/staging/rtl8192e/rtl819x_HT.h index 6eb018f..48d101a 100644 --- a/drivers/staging/rtl8192e/rtl819x_HT.h +++ b/drivers/staging/rtl8192e/rtl819x_HT.h @@ -11,7 +11,7 @@ * * Contact Information: * wlanfae -**/ + **/ #ifndef _RTL819XU_HTTYPE_H_ #define _RTL819XU_HTTYPE_H_ -- 2.7.4
Re: [Outreachy kernel] [PATCH 3/6] staging: rtl8192e: Fix block comments warning
On Sat, 18 Feb 2017, simran singhal wrote: > Align * on a line, to conform to the kernal coding > style for block comments. It is not clear what is means to align * on a line. What line? What has been done is to add a space at the beginning of the line. But then the line goes over 80 characters and doesn't line up any more on the right side. I would guess that you should have gotten a new warning by having gone over 80 characters. Fixing one warning should not introduce a new one, especially for something purely decorative, like this. julia > > Signed-off-by: simran singhal > --- > drivers/staging/rtl8192e/rtl819x_HT.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/rtl8192e/rtl819x_HT.h > b/drivers/staging/rtl8192e/rtl819x_HT.h > index 6eb018f..48d101a 100644 > --- a/drivers/staging/rtl8192e/rtl819x_HT.h > +++ b/drivers/staging/rtl8192e/rtl819x_HT.h > @@ -11,7 +11,7 @@ > * > * Contact Information: > * wlanfae > -**/ > + > **/ > #ifndef _RTL819XU_HTTYPE_H_ > #define _RTL819XU_HTTYPE_H_ > > -- > 2.7.4 > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20170218152351.GA28908%40singhal-Inspiron-5558. > For more options, visit https://groups.google.com/d/optout. >
[PATCH] staging: ks7010: Block comments use * on subsequent lines
Some of the block comments styles are not encouraged:
for example:
/*
block comment without introductory *
*/
and
/*
* block comment with line terminating */
Signed-off-by: Arushi Singhal
---
drivers/staging/ks7010/ks7010_sdio.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ks7010/ks7010_sdio.c
b/drivers/staging/ks7010/ks7010_sdio.c
index a604c83c957e..2c263f98bdbb 100644
--- a/drivers/staging/ks7010/ks7010_sdio.c
+++ b/drivers/staging/ks7010/ks7010_sdio.c
@@ -495,8 +495,10 @@ static void ks7010_rw_function(struct work_struct *work)
/* wiat after WAKEUP */
while (time_after(priv->last_wakeup + ((30 * HZ) / 1000), jiffies)) {
DPRINTK(4, "wait after WAKEUP\n");
-/*
queue_delayed_work(priv->ks_wlan_hw.ks7010sdio_wq,&priv->ks_wlan_hw.rw_wq,
- (priv->last_wakeup + ((30*HZ)/1000) - jiffies));*/
+/*
+ * queue_delayed_work(priv->ks_wlan_hw.ks7010sdio_wq,&priv->ks_wlan_hw.rw_wq,
+ * (priv->last_wakeup + ((30*HZ)/1000) - jiffies));
+ */
dev_info(&priv->ks_wlan_hw.sdio_card->func->dev,
"wake: %lu %lu\n",
priv->last_wakeup + (30 * HZ) / 1000,
--
2.11.0
[PATCH 4/6] staging: rtl8192e: Remove blank line after '{'
Remove blank line after opening brace to fix the
checkpatch issue blank lines aren't necessary after
a open brace '{'.
Signed-off-by: simran singhal
---
drivers/staging/rtl8192e/rtl819x_HT.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_HT.h
b/drivers/staging/rtl8192e/rtl819x_HT.h
index 48d101a..f53903e 100644
--- a/drivers/staging/rtl8192e/rtl819x_HT.h
+++ b/drivers/staging/rtl8192e/rtl819x_HT.h
@@ -32,7 +32,6 @@ enum ht_extchnl_offset {
};
struct ht_capab_ele {
-
u8 AdvCoding:1;
u8 ChlWidth:1;
u8 MimoPwrSave:2;
@@ -187,7 +186,6 @@ struct rt_hi_throughput {
} __packed;
struct bss_ht {
-
u8 bdSupportHT;
u8 bdHTCapBuf[32];
--
2.7.4
Re: [RESEND 2] [PATCH] rlimits: Print more information when limits are exceeded
On Sat, 18 Feb 2017, at 02:07 PM, Arun Raghavan wrote: > This dumps some information in logs when a process exceeds its CPU or RT > limits (soft and hard). Makes debugging easier when userspace triggers > these limits. > > Signed-off-by: Arun Raghavan > --- > kernel/time/posix-cpu-timers.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > Hello, > This has come up a couple of times in the past, but we haven't been able > to > resolve whatever issues were pointed out. > > In the mean time, we have frustrated users who don't know where they're > getting > a SIGKILL from, and I'd really like to have a way for people to not have > to go > through this. > > The issues that came up the last time were: > > 1. SIGXCPU messages shouldn't be needed since they can be caught: it's > still > useful to have the log because it isn't always possible to pin down > the > thread causing the problem in userspace. > > 2. SIGKILL logging should be centralised: there seem to be multiple > paths that > trigger a SIGKILL -- and it seemed a bit ugly to try to add a reason > parameter on all of them for the KILL case. Any other suggestions on > how to > deal with this? > > I'm happy to fix this up to actually make it this time, but if there > aren't > none, just pushing this out will make our lives a little less painful. That was meant to read -- "... if there aren't blocking objections to this, just pushing this out will make our lives a little less painful." -- Arun
Linux 4.9.11
I'm announcing the release of the 4.9.11 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/x86/kernel/fpu/core.c |3 drivers/net/ethernet/mellanox/mlx4/en_rx.c |5 drivers/net/ethernet/mellanox/mlx5/core/en.h |3 drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 13 - drivers/net/ethernet/mellanox/mlx5/core/en_main.c| 198 +-- drivers/net/ethernet/mellanox/mlx5/core/fs_core.c|6 drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c |4 drivers/net/loopback.c |1 drivers/net/macvtap.c|4 drivers/net/tun.c| 10 drivers/net/usb/catc.c | 56 +++-- drivers/net/usb/pegasus.c| 29 ++ drivers/net/usb/rtl8150.c| 34 ++- include/linux/can/core.h |7 include/linux/netdevice.h|4 include/net/cipso_ipv4.h |4 include/net/ipv6.h |2 include/net/lwtunnel.h |5 net/can/af_can.c | 12 - net/can/af_can.h |3 net/can/bcm.c|4 net/can/gw.c |2 net/can/raw.c|4 net/core/dev.c | 31 +- net/dccp/ipv6.c |4 net/dsa/dsa2.c |1 net/ethernet/eth.c |1 net/ipv4/cipso_ipv4.c|4 net/ipv4/igmp.c |1 net/ipv4/ip_output.c |1 net/ipv4/ip_sockglue.c |9 net/ipv4/ping.c |2 net/ipv4/tcp.c |6 net/ipv4/tcp_output.c|6 net/ipv6/inet6_connection_sock.c |2 net/ipv6/ip6_gre.c | 40 ++- net/ipv6/ip6_output.c|4 net/ipv6/ip6_tunnel.c| 34 ++- net/ipv6/mcast.c | 50 ++-- net/ipv6/sit.c |1 net/ipv6/tcp_ipv6.c | 28 +- net/l2tp/l2tp_core.h |1 net/l2tp/l2tp_ip.c | 27 ++ net/l2tp/l2tp_ip6.c |2 net/packet/af_packet.c |7 net/sched/cls_matchall.c | 127 net/sctp/ipv6.c |3 net/sctp/socket.c|3 49 files changed, 468 insertions(+), 342 deletions(-) Alexey Brodkin (1): stmmac: Discard masked flags in interrupt status register Ben Hutchings (4): pegasus: Use heap buffers for all register access rtl8150: Use heap buffers for all register access catc: Combine failure cleanup code in catc_probe() catc: Use heap buffer for memory size test Benjamin Poirier (1): mlx4: Invoke softirqs after napi_reschedule Dan Carpenter (1): ipv6: pointer math error in ip6_tnl_parse_tlv_enc_lim() David Ahern (1): lwtunnel: valid encap attr check should return 0 when lwtunnel is disabled Eric Dumazet (10): can: Fix kernel panic at security_sock_rcv_skb ipv6: fix ip6_tnl_parse_tlv_enc_lim() tcp: fix 0 divide in __tcp_select_window() net: use a work queue to defer net_disable_timestamp() work ipv4: keep skb->dst around in presence of IP options netlabel: out of bound access in cipso_v4_validate() ip6_gre: fix ip6gre_err() invalid reads ipv6: tcp: add a missing tcp_v6_restore_cb() tcp: avoid infinite loop in tcp_splice_read() l2tp: do not use udp_ioctl() Florian Fainelli (1): net: dsa: Do not destroy invalid network devices Gal Pressman (1): net/mlx5e: Fix update of hash function/key via ethtool Greg Kroah-Hartman (1): Linux 4.9.11 Hangbin Liu (2): mld: do not remove mld souce list info when set link down igmp, mld: Fix memory leak in i
Re: Linux 4.4.50
diff --git a/Makefile b/Makefile
index 5fab6d4068b5..10993715abb8 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 49
+SUBLEVEL = 50
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index bbff8ec6713e..28a4b34310b2 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -502,8 +502,11 @@ void mlx4_en_recover_from_oom(struct mlx4_en_priv *priv)
return;
for (ring = 0; ring < priv->rx_ring_num; ring++) {
- if (mlx4_en_is_ring_empty(priv->rx_ring[ring]))
+ if (mlx4_en_is_ring_empty(priv->rx_ring[ring])) {
+ local_bh_disable();
napi_reschedule(&priv->rx_cq[ring]->napi);
+ local_bh_enable();
+ }
}
}
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index dc7d970bd1c0..effcdbfb06e9 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -164,6 +164,7 @@ static void loopback_setup(struct net_device *dev)
{
dev->mtu= 64 * 1024;
dev->hard_header_len= ETH_HLEN; /* 14 */
+ dev->min_header_len = ETH_HLEN; /* 14 */
dev->addr_len = ETH_ALEN; /* 6*/
dev->type = ARPHRD_LOOPBACK; /* 0x0001*/
dev->flags = IFF_LOOPBACK;
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 159a68782bec..79de9608ac48 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -725,7 +725,7 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q,
struct msghdr *m,
ssize_t n;
if (q->flags & IFF_VNET_HDR) {
- vnet_hdr_len = q->vnet_hdr_sz;
+ vnet_hdr_len = READ_ONCE(q->vnet_hdr_sz);
err = -EINVAL;
if (len < vnet_hdr_len)
@@ -865,7 +865,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
if (q->flags & IFF_VNET_HDR) {
struct virtio_net_hdr vnet_hdr;
- vnet_hdr_len = q->vnet_hdr_sz;
+ vnet_hdr_len = READ_ONCE(q->vnet_hdr_sz);
if (iov_iter_count(iter) < vnet_hdr_len)
return -EINVAL;
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 111b972e3053..c31d8e74f131 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1108,9 +1108,11 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
}
if (tun->flags & IFF_VNET_HDR) {
- if (len < tun->vnet_hdr_sz)
+ int vnet_hdr_sz = READ_ONCE(tun->vnet_hdr_sz);
+
+ if (len < vnet_hdr_sz)
return -EINVAL;
- len -= tun->vnet_hdr_sz;
+ len -= vnet_hdr_sz;
n = copy_from_iter(&gso, sizeof(gso), from);
if (n != sizeof(gso))
@@ -1122,7 +1124,7 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
if (tun16_to_cpu(tun, gso.hdr_len) > len)
return -EINVAL;
- iov_iter_advance(from, tun->vnet_hdr_sz - sizeof(gso));
+ iov_iter_advance(from, vnet_hdr_sz - sizeof(gso));
}
if ((tun->flags & TUN_TYPE_MASK) == IFF_TAP) {
@@ -1301,7 +1303,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
vlan_hlen = VLAN_HLEN;
if (tun->flags & IFF_VNET_HDR)
- vnet_hdr_sz = tun->vnet_hdr_sz;
+ vnet_hdr_sz = READ_ONCE(tun->vnet_hdr_sz);
total = skb->len + vlan_hlen + vnet_hdr_sz;
diff --git a/include/linux/can/core.h b/include/linux/can/core.h
index a0875001b13c..df08a41d5be5 100644
--- a/include/linux/can/core.h
+++ b/include/linux/can/core.h
@@ -45,10 +45,9 @@ struct can_proto {
extern int can_proto_register(const struct can_proto *cp);
extern void can_proto_unregister(const struct can_proto *cp);
-extern int can_rx_register(struct net_device *dev, canid_t can_id,
- canid_t mask,
- void (*func)(struct sk_buff *, void *),
- void *data, char *ident);
+int can_rx_register(struct net_device *dev, canid_t can_id, canid_t mask,
+ void (*func)(struct sk_buff *, void *),
+ void *data, char *ident, struct sock *sk);
extern void can_rx_unregister(struct net_device *dev, canid_t can_id,
canid_t mask,
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 93a6a2c66d15..4035bbe40971 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1399,6 +1399,7 @@ enum netdev_priv_flags {
* @mtu: Interface MTU value
* @type: Interface hardware type
* @hard_header_len: Maximum hardware header length.
+
Re: Linux 4.9.11
diff --git a/Makefile b/Makefile
index d2fe757a979d..18b0c5adad3b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 10
+SUBLEVEL = 11
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index ebb4e95fbd74..96d80dfac383 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -236,7 +236,8 @@ void fpstate_init(union fpregs_state *state)
* it will #GP. Make sure it is replaced after the memset().
*/
if (static_cpu_has(X86_FEATURE_XSAVES))
- state->xsave.header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT;
+ state->xsave.header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT |
+ xfeatures_mask;
if (static_cpu_has(X86_FEATURE_FXSR))
fpstate_init_fxstate(&state->fxsave);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index f2e8beddcf44..4d3ddc2f7e43 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -507,8 +507,11 @@ void mlx4_en_recover_from_oom(struct mlx4_en_priv *priv)
return;
for (ring = 0; ring < priv->rx_ring_num; ring++) {
- if (mlx4_en_is_ring_empty(priv->rx_ring[ring]))
+ if (mlx4_en_is_ring_empty(priv->rx_ring[ring])) {
+ local_bh_disable();
napi_reschedule(&priv->rx_cq[ring]->napi);
+ local_bh_enable();
+ }
}
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h
b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index 71382df59fc0..81d8e3bd01b6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -765,7 +765,8 @@ void mlx5e_disable_vlan_filter(struct mlx5e_priv *priv);
int mlx5e_modify_rqs_vsd(struct mlx5e_priv *priv, bool vsd);
int mlx5e_redirect_rqt(struct mlx5e_priv *priv, u32 rqtn, int sz, int ix);
-void mlx5e_build_tir_ctx_hash(void *tirc, struct mlx5e_priv *priv);
+void mlx5e_build_indir_tir_ctx_hash(struct mlx5e_priv *priv, void *tirc,
+ enum mlx5e_traffic_types tt);
int mlx5e_open_locked(struct net_device *netdev);
int mlx5e_close_locked(struct net_device *netdev);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index 51c6a57ca873..126cfeb7e0ec 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -975,15 +975,18 @@ static int mlx5e_get_rxfh(struct net_device *netdev, u32
*indir, u8 *key,
static void mlx5e_modify_tirs_hash(struct mlx5e_priv *priv, void *in, int
inlen)
{
- struct mlx5_core_dev *mdev = priv->mdev;
void *tirc = MLX5_ADDR_OF(modify_tir_in, in, ctx);
- int i;
+ struct mlx5_core_dev *mdev = priv->mdev;
+ int ctxlen = MLX5_ST_SZ_BYTES(tirc);
+ int tt;
MLX5_SET(modify_tir_in, in, bitmask.hash, 1);
- mlx5e_build_tir_ctx_hash(tirc, priv);
- for (i = 0; i < MLX5E_NUM_INDIR_TIRS; i++)
- mlx5_core_modify_tir(mdev, priv->indir_tir[i].tirn, in, inlen);
+ for (tt = 0; tt < MLX5E_NUM_INDIR_TIRS; tt++) {
+ memset(tirc, 0, ctxlen);
+ mlx5e_build_indir_tir_ctx_hash(priv, tirc, tt);
+ mlx5_core_modify_tir(mdev, priv->indir_tir[tt].tirn, in, inlen);
+ }
}
static int mlx5e_set_rxfh(struct net_device *dev, const u32 *indir,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 5dc3e2453ff5..b30671376a3d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -1978,8 +1978,23 @@ static void mlx5e_build_tir_ctx_lro(void *tirc, struct
mlx5e_priv *priv)
MLX5_SET(tirc, tirc, lro_timeout_period_usecs,
priv->params.lro_timeout);
}
-void mlx5e_build_tir_ctx_hash(void *tirc, struct mlx5e_priv *priv)
+void mlx5e_build_indir_tir_ctx_hash(struct mlx5e_priv *priv, void *tirc,
+ enum mlx5e_traffic_types tt)
{
+ void *hfso = MLX5_ADDR_OF(tirc, tirc, rx_hash_field_selector_outer);
+
+#define MLX5_HASH_IP(MLX5_HASH_FIELD_SEL_SRC_IP |\
+MLX5_HASH_FIELD_SEL_DST_IP)
+
+#define MLX5_HASH_IP_L4PORTS(MLX5_HASH_FIELD_SEL_SRC_IP |\
+MLX5_HASH_FIELD_SEL_DST_IP |\
+MLX5_HASH_FIELD_SEL_L4_SPORT |\
+MLX5_HASH_FIELD_SEL_L4_DPORT)
+
+#define MLX5_HASH_IP_IPSEC_SPI (MLX5_HASH_FIELD_SEL_SRC_IP |\
+MLX5_HASH_FIELD_SEL_DST_IP |\
+MLX5_HASH_FIELD_SEL_IPSEC_SPI)
+
ML
Linux 4.4.50
I'm announcing the release of the 4.4.50 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 - drivers/net/ethernet/mellanox/mlx4/en_rx.c |5 ++- drivers/net/loopback.c |1 drivers/net/macvtap.c |4 +- drivers/net/tun.c | 10 --- include/linux/can/core.h |7 ++-- include/linux/netdevice.h |4 ++ include/net/cipso_ipv4.h |4 ++ net/can/af_can.c | 12 +++- net/can/af_can.h |3 +- net/can/bcm.c |4 +- net/can/gw.c |2 - net/can/raw.c |4 +- net/core/dev.c | 31 + net/ethernet/eth.c |1 net/ipv4/cipso_ipv4.c |4 ++ net/ipv4/ip_sockglue.c |9 +- net/ipv4/ping.c|2 + net/ipv4/tcp.c |6 net/ipv4/tcp_output.c |6 ++-- net/ipv6/ip6_gre.c | 41 +++-- net/ipv6/ip6_tunnel.c | 34 +++- net/ipv6/sit.c |1 net/ipv6/tcp_ipv6.c| 24 +--- net/l2tp/l2tp_core.h |1 net/l2tp/l2tp_ip.c | 27 ++- net/l2tp/l2tp_ip6.c|2 - net/packet/af_packet.c |7 ++-- net/sctp/socket.c |3 +- 29 files changed, 172 insertions(+), 89 deletions(-) Benjamin Poirier (1): mlx4: Invoke softirqs after napi_reschedule Dan Carpenter (1): ipv6: pointer math error in ip6_tnl_parse_tlv_enc_lim() Eric Dumazet (10): can: Fix kernel panic at security_sock_rcv_skb ipv6: fix ip6_tnl_parse_tlv_enc_lim() tcp: fix 0 divide in __tcp_select_window() net: use a work queue to defer net_disable_timestamp() work ipv4: keep skb->dst around in presence of IP options netlabel: out of bound access in cipso_v4_validate() ip6_gre: fix ip6gre_err() invalid reads ipv6: tcp: add a missing tcp_v6_restore_cb() tcp: avoid infinite loop in tcp_splice_read() l2tp: do not use udp_ioctl() Greg Kroah-Hartman (1): Linux 4.4.50 Marcelo Ricardo Leitner (1): sctp: avoid BUG_ON on sctp_wait_for_sndbuf WANG Cong (2): sit: fix a double free on error path ping: fix a null pointer dereference Willem de Bruijn (4): tun: read vnet_hdr_sz once macvtap: read vnet_hdr_size once net: introduce device min_header_len packet: round up linear to header len signature.asc Description: PGP signature
[PATCH] staging: ks7010: Unnecessary parentheses should be avoided
Unnecessary parentheses as reported by checkpatch.pl
Signed-off-by: Arushi Singhal
---
drivers/staging/ks7010/ks_hostif.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.c
b/drivers/staging/ks7010/ks_hostif.c
index 1fbd495e5e63..819e08b5fa91 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -113,7 +113,7 @@ int get_current_ap(struct ks_wlan_private *priv, struct
link_ap_info_t *ap_info)
int rc = 0;
DPRINTK(3, "\n");
- ap = &(priv->current_ap);
+ ap = &priv->current_ap;
if ((priv->connect_status & CONNECT_STATUS_MASK) == DISCONNECT_STATUS) {
memset(ap, 0, sizeof(struct local_ap_t));
@@ -121,19 +121,19 @@ int get_current_ap(struct ks_wlan_private *priv, struct
link_ap_info_t *ap_info)
}
/* bssid */
- memcpy(&(ap->bssid[0]), &(ap_info->bssid[0]), ETH_ALEN);
+ memcpy(&ap->bssid[0], &ap_info->bssid[0], ETH_ALEN);
/* essid */
- memcpy(&(ap->ssid.body[0]), &(priv->reg.ssid.body[0]),
+ memcpy(&ap->ssid.body[0], &priv->reg.ssid.body[0],
priv->reg.ssid.size);
ap->ssid.size = priv->reg.ssid.size;
/* rate_set */
- memcpy(&(ap->rate_set.body[0]), &(ap_info->rate_set.body[0]),
+ memcpy(&ap->rate_set.body[0], &ap_info->rate_set.body[0],
ap_info->rate_set.size);
ap->rate_set.size = ap_info->rate_set.size;
if (ap_info->ext_rate_set.size) {
/* rate_set */
- memcpy(&(ap->rate_set.body[ap->rate_set.size]),
- &(ap_info->ext_rate_set.body[0]),
+ memcpy(&ap->rate_set.body[ap->rate_set.size],
+ &ap_info->ext_rate_set.body[0],
ap_info->ext_rate_set.size);
ap->rate_set.size += ap_info->ext_rate_set.size;
}
@@ -153,11 +153,11 @@ int get_current_ap(struct ks_wlan_private *priv, struct
link_ap_info_t *ap_info)
ap->rsn_ie.id = 0x30;
if (ap_info->rsn.size <= RSN_IE_BODY_MAX) {
ap->rsn_ie.size = ap_info->rsn.size;
- memcpy(&(ap->rsn_ie.body[0]), &(ap_info->rsn.body[0]),
+ memcpy(&ap->rsn_ie.body[0], &ap_info->rsn.body[0],
ap_info->rsn.size);
} else {
ap->rsn_ie.size = RSN_IE_BODY_MAX;
- memcpy(&(ap->rsn_ie.body[0]), &(ap_info->rsn.body[0]),
+ memcpy(&ap->rsn_ie.body[0], &ap_info->rsn.body[0],
RSN_IE_BODY_MAX);
}
} else if ((ap_info->rsn_mode & RSN_MODE_WPA)
@@ -165,11 +165,11 @@ int get_current_ap(struct ks_wlan_private *priv, struct
link_ap_info_t *ap_info)
ap->wpa_ie.id = 0xdd;
if (ap_info->rsn.size <= RSN_IE_BODY_MAX) {
ap->wpa_ie.size = ap_info->rsn.size;
- memcpy(&(ap->wpa_ie.body[0]), &(ap_info->rsn.body[0]),
+ memcpy(&ap->wpa_ie.body[0], &ap_info->rsn.body[0],
ap_info->rsn.size);
} else {
ap->wpa_ie.size = RSN_IE_BODY_MAX;
- memcpy(&(ap->wpa_ie.body[0]), &(ap_info->rsn.body[0]),
+ memcpy(&ap->wpa_ie.body[0], &ap_info->rsn.body[0],
RSN_IE_BODY_MAX);
}
} else {
--
2.11.0
[PATCH 5/6] staging: rtl8192e: Fixes multiple blank lines issue
This patch fixes the checkpatch.pl issue:
Please don't use multiple blank lines
Signed-off-by: simran singhal
---
drivers/staging/rtl8192e/rtl819x_HT.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_HT.h
b/drivers/staging/rtl8192e/rtl819x_HT.h
index f53903e..eceb548 100644
--- a/drivers/staging/rtl8192e/rtl819x_HT.h
+++ b/drivers/staging/rtl8192e/rtl819x_HT.h
@@ -53,7 +53,6 @@ struct ht_capab_ele {
u8 MCS[16];
-
u16 ExtHTCapInfo;
u8 TxBFCap[4];
@@ -62,7 +61,6 @@ struct ht_capab_ele {
} __packed;
-
struct ht_info_ele {
u8 ControlChl;
@@ -101,7 +99,6 @@ enum ht_aggre_mode {
HT_AGG_FORCE_DISABLE = 2,
};
-
struct rt_hi_throughput {
u8 bEnableHT;
u8 bCurrentHTSupport;
@@ -120,14 +117,12 @@ struct rt_hi_throughput {
enum ht_spec_ver ePeerHTSpecVer;
-
struct ht_capab_ele SelfHTCap;
struct ht_info_ele SelfHTInfo;
u8 PeerHTCapBuf[32];
u8 PeerHTInfoBuf[32];
-
u8 bAMSDU_Support;
u16 nAMSDU_MaxSize;
u8 bCurrent_AMSDU_Support;
--
2.7.4
Re: [Outreachy kernel] [PATCH 4/6] staging: rtl8192e: Remove blank line after '{'
On Sat, 18 Feb 2017, simran singhal wrote:
> Remove blank line after opening brace to fix the
> checkpatch issue blank lines aren't necessary after
> a open brace '{'.
>
> Signed-off-by: simran singhal
Acked-by: Julia Lawall
> ---
> drivers/staging/rtl8192e/rtl819x_HT.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl819x_HT.h
> b/drivers/staging/rtl8192e/rtl819x_HT.h
> index 48d101a..f53903e 100644
> --- a/drivers/staging/rtl8192e/rtl819x_HT.h
> +++ b/drivers/staging/rtl8192e/rtl819x_HT.h
> @@ -32,7 +32,6 @@ enum ht_extchnl_offset {
> };
>
> struct ht_capab_ele {
> -
> u8 AdvCoding:1;
> u8 ChlWidth:1;
> u8 MimoPwrSave:2;
> @@ -187,7 +186,6 @@ struct rt_hi_throughput {
> } __packed;
>
> struct bss_ht {
> -
> u8 bdSupportHT;
>
> u8 bdHTCapBuf[32];
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20170218154254.GA16661%40singhal-Inspiron-5558.
> For more options, visit https://groups.google.com/d/optout.
>
Re: [PATCH] eeepc-laptop: Skip unknown key messages 0x50 0x51
On Fri, Feb 10, 2017 at 7:48 PM, Pau Espin Pedrol wrote: > Otherwise those are printed several times when (un)plugging the AC > connector. If we have a user space tool that supports them better not to ignore. -- With Best Regards, Andy Shevchenko
Re: [Outreachy kernel] [PATCH 3/6] staging: rtl8192e: Fix block comments warning
On Sat, 18 Feb 2017, SIMRAN SINGHAL wrote: > > > On Saturday, February 18, 2017 at 9:00:51 PM UTC+5:30, Julia Lawall wrote: > > > On Sat, 18 Feb 2017, simran singhal wrote: > > > Align * on a line, to conform to the kernal coding > > style for block comments. > > It is not clear what is means to align * on a line. What line? > > What has been done is to add a space at the beginning of the > line. But > then the line goes over 80 characters and doesn't line up any > more on the > right side. I would guess that you should have gotten a new > warning by > having gone over 80 characters. Fixing one warning should not > introduce a > new one, especially for something purely decorative, like this. > > julia > > Julia, I am not getting any new warning. It's not gone over 80 characters. OK, it looked like it would be too long on my screen. Are the right sides of the * lines lined up after the change? julia > > > > > Signed-off-by: simran singhal > > --- > > drivers/staging/rtl8192e/rtl819x_HT.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/rtl8192e/rtl819x_HT.h > b/drivers/staging/rtl8192e/rtl819x_HT.h > > index 6eb018f..48d101a 100644 > > --- a/drivers/staging/rtl8192e/rtl819x_HT.h > > +++ b/drivers/staging/rtl8192e/rtl819x_HT.h > > @@ -11,7 +11,7 @@ > > * > > * Contact Information: > > * wlanfae > > >-** > / > > > +*** > ***/ > > #ifndef _RTL819XU_HTTYPE_H_ > > #define _RTL819XU_HTTYPE_H_ > > > > -- > > 2.7.4 > > > > -- > > You received this message because you are subscribed to the > Google Groups "outreachy-kernel" group. > > To unsubscribe from this group and stop receiving emails from > it, send an email to outreachy-kern...@googlegroups.com. > > To post to this group, send email to > outreach...@googlegroups.com. > > To view this discussion on the web > visithttps://groups.google.com/d/msgid/outreachy-kernel/20170218152351.GA28908%4 > 0singhal-Inspiron-5558. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web > visithttps://groups.google.com/d/msgid/outreachy-kernel/5192275f-5b36-4e1d-8d66- > afc735f3a8f6%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > >
Re: [PATCH] backlight: report error on failure
On Monday 30 January 2017 11:04 PM, Sudip Mukherjee wrote:
On Wednesday 18 January 2017 09:23 PM, Sudip Mukherjee wrote:
It is possible to update the backlight power and the brightness using
the sysfs and on writing it either returns the count or if the callback
function does not exist then returns the error code 'ENXIO'.
We have a situation where the userspace client is writing to the sysfs
to update the power and since the callback function exists the client
receives the return value as count and considers the operation to be
successful. That is correct as the write to the sysfs was successful.
But there is no way to know if the actual operation was done or not.
backlight_update_status() returns the error code if it fails. Pass that
to the userspace client who is trying to update the power so that the
client knows that the operation failed.
Signed-off-by: Sudip Mukherjee
---
A gentle ping.
Hi Andrew,
Its more than one month now that this patch was submitted. Can you
please take it through your tree... else it will miss the merge window.
Regards
Sudip
drivers/video/backlight/backlight.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 288318a..74b72b5 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -146,9 +146,9 @@ static ssize_t bl_power_store(struct device *dev,
struct device_attribute *attr,
pr_debug("set power to %lu\n", power);
if (bd->props.power != power) {
bd->props.power = power;
-backlight_update_status(bd);
+rc = backlight_update_status(bd);
}
-rc = count;
+rc = rc ? rc : count;
}
mutex_unlock(&bd->ops_lock);
@@ -176,8 +176,7 @@ int backlight_device_set_brightness(struct
backlight_device *bd,
else {
pr_debug("set brightness to %lu\n", brightness);
bd->props.brightness = brightness;
-backlight_update_status(bd);
-rc = 0;
+rc = backlight_update_status(bd);
}
}
mutex_unlock(&bd->ops_lock);
[PATCH] Staging: ks7010: There should be no spaces at the start of a line
The following patch the checkpatch.pl warning: drivers/staging/ks7010/ks_hostif.c warning: please, no spaces at the start of a line Signed-off-by: Arushi Singhal --- drivers/staging/ks7010/ks_hostif.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/ks7010/ks_hostif.c b/drivers/staging/ks7010/ks_hostif.c index 819e08b5fa91..3b2e28749b63 100644 --- a/drivers/staging/ks7010/ks_hostif.c +++ b/drivers/staging/ks7010/ks_hostif.c @@ -191,8 +191,8 @@ int get_current_ap(struct ks_wlan_private *priv, struct link_ap_info_t *ap_info) } DPRINTK(4, "\nLink AP\n"); DPRINTK(4, "bssid=%02X:%02X:%02X:%02X:%02X:%02X\n \ - essid=%s\nrate_set=%02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n channel=%d\n \ - rssi=%d\nsq=%d\ncapability=%04X\n", ap->bssid[0], ap->bssid[1], ap->bssid[2], ap->bssid[3], ap->bssid[4], ap->bssid[5], &(ap->ssid.body[0]), ap->rate_set.body[0], ap->rate_set.body[1], ap->rate_set.body[2], ap->rate_set.body[3], ap->rate_set.body[4], ap->rate_set.body[5], ap->rate_set.body[6], ap->rate_set.body[7], ap->channel, ap->rssi, ap->sq, ap->capability); +essid=%s\nrate_set=%02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n channel=%d\n \ +rssi=%d\nsq=%d\ncapability=%04X\n", ap->bssid[0], ap->bssid[1], ap->bssid[2], ap->bssid[3], ap->bssid[4], ap->bssid[5], &(ap->ssid.body[0]), ap->rate_set.body[0], ap->rate_set.body[1], ap->rate_set.body[2], ap->rate_set.body[3], ap->rate_set.body[4], ap->rate_set.body[5], ap->rate_set.body[6], ap->rate_set.body[7], ap->channel, ap->rssi, ap->sq, ap->capability); DPRINTK(4, "\nLink AP\nrsn.mode=%d\nrsn.size=%d\n", ap_info->rsn_mode, ap_info->rsn.size); DPRINTK(4, "\next_rate_set_size=%d\nrate_set_size=%d\n", -- 2.11.0
Re: [PATCH] Staging: ks7010: There should be no spaces at the start of a line
On Sat, Feb 18, 2017 at 10:10:02PM +0530, Arushi Singhal wrote: > The following patch the checkpatch.pl warning: > drivers/staging/ks7010/ks_hostif.c warning: please, no spaces at the > start of a line > > Signed-off-by: Arushi Singhal > --- > drivers/staging/ks7010/ks_hostif.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/ks7010/ks_hostif.c > b/drivers/staging/ks7010/ks_hostif.c > index 819e08b5fa91..3b2e28749b63 100644 > --- a/drivers/staging/ks7010/ks_hostif.c > +++ b/drivers/staging/ks7010/ks_hostif.c > @@ -191,8 +191,8 @@ int get_current_ap(struct ks_wlan_private *priv, struct > link_ap_info_t *ap_info) > } > DPRINTK(4, "\nLink AP\n"); > DPRINTK(4, "bssid=%02X:%02X:%02X:%02X:%02X:%02X\n \ > - essid=%s\nrate_set=%02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n > channel=%d\n \ > - rssi=%d\nsq=%d\ncapability=%04X\n", ap->bssid[0], ap->bssid[1], > ap->bssid[2], ap->bssid[3], ap->bssid[4], ap->bssid[5], &(ap->ssid.body[0]), > ap->rate_set.body[0], ap->rate_set.body[1], ap->rate_set.body[2], > ap->rate_set.body[3], ap->rate_set.body[4], ap->rate_set.body[5], > ap->rate_set.body[6], ap->rate_set.body[7], ap->channel, ap->rssi, ap->sq, > ap->capability); > +essid=%s\nrate_set=%02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n > channel=%d\n \ > +rssi=%d\nsq=%d\ncapability=%04X\n", ap->bssid[0], ap->bssid[1], > ap->bssid[2], ap->bssid[3], ap->bssid[4], ap->bssid[5], &(ap->ssid.body[0]), > ap->rate_set.body[0], ap->rate_set.body[1], ap->rate_set.body[2], > ap->rate_set.body[3], ap->rate_set.body[4], ap->rate_set.body[5], > ap->rate_set.body[6], ap->rate_set.body[7], ap->channel, ap->rssi, ap->sq, > ap->capability); So don't just remove the spaces, fix it correctly with the proper indentation please. thanks, greg k-h
[PATCH] staging: ks7010: Unnecessary parentheses should be avoided
Unnecessary parentheses should be avoided as reported by checkpatch.pl
Signed-off-by: Arushi Singhal
---
drivers/staging/ks7010/ks_hostif.c | 24
drivers/staging/ks7010/ks_wlan_net.c | 20 ++--
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.c
b/drivers/staging/ks7010/ks_hostif.c
index 3b2e28749b63..bbc39cbabdc1 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -212,7 +212,7 @@ int get_ap_information(struct ks_wlan_private *priv, struct
ap_info_t *ap_info,
memset(ap, 0, sizeof(struct local_ap_t));
/* bssid */
- memcpy(&(ap->bssid[0]), &(ap_info->bssid[0]), ETH_ALEN);
+ memcpy(&ap->bssid[0], &ap_info->bssid[0], ETH_ALEN);
/* rssi */
ap->rssi = ap_info->rssi;
/* sq */
@@ -224,7 +224,7 @@ int get_ap_information(struct ks_wlan_private *priv, struct
ap_info_t *ap_info,
/* channel */
ap->channel = ap_info->ch_info;
- bp = &(ap_info->body[0]);
+ bp = &ap_info->body[0];
bsize = ap_info->body_size;
offset = 0;
@@ -239,19 +239,19 @@ int get_ap_information(struct ks_wlan_private *priv,
struct ap_info_t *ap_info,
*(bp + 1));
ap->ssid.size = SSID_MAX_SIZE;
}
- memcpy(&(ap->ssid.body[0]), bp + 2, ap->ssid.size);
+ memcpy(&ap->ssid.body[0], bp + 2, ap->ssid.size);
break;
case 1: /* rate */
case 50:/* ext rate */
if ((*(bp + 1) + ap->rate_set.size) <=
RATE_SET_MAX_SIZE) {
- memcpy(&(ap->rate_set.body[ap->rate_set.size]),
+ memcpy(&ap->rate_set.body[ap->rate_set.size],
bp + 2, *(bp + 1));
ap->rate_set.size += *(bp + 1);
} else {
DPRINTK(1, "size over :: rate size=%d\n",
(*(bp + 1) + ap->rate_set.size));
- memcpy(&(ap->rate_set.body[ap->rate_set.size]),
+ memcpy(&ap->rate_set.body[ap->rate_set.size],
bp + 2,
RATE_SET_MAX_SIZE - ap->rate_set.size);
ap->rate_set.size +=
@@ -269,7 +269,7 @@ int get_ap_information(struct ks_wlan_private *priv, struct
ap_info_t *ap_info,
*(bp + 1));
ap->rsn_ie.size = RSN_IE_BODY_MAX;
}
- memcpy(&(ap->rsn_ie.body[0]), bp + 2, ap->rsn_ie.size);
+ memcpy(&ap->rsn_ie.body[0], bp + 2, ap->rsn_ie.size);
break;
case 221: /* WPA */
if (!memcmp(bp + 2, "\x00\x50\xf2\x01", 4)) { /* WPA
OUI check */
@@ -282,7 +282,7 @@ int get_ap_information(struct ks_wlan_private *priv, struct
ap_info_t *ap_info,
*(bp + 1));
ap->wpa_ie.size = RSN_IE_BODY_MAX;
}
- memcpy(&(ap->wpa_ie.body[0]), bp + 2,
+ memcpy(&ap->wpa_ie.body[0], bp + 2,
ap->wpa_ie.size);
}
break;
@@ -832,8 +832,8 @@ void hostif_scan_indication(struct ks_wlan_private *priv)
if (priv->scan_ind_count != 0) {
for (i = 0; i < priv->aplist.size; i++) { /* bssid check
*/
if (!memcmp
- (&(ap_info->bssid[0]),
-&(priv->aplist.ap[i].bssid[0]), ETH_ALEN)) {
+ (&ap_info->bssid[0],
+&priv->aplist.ap[i].bssid[0], ETH_ALEN)) {
if (ap_info->frame_type ==
FRAME_TYPE_PROBE_RESP)
get_ap_information(priv, ap_info,
@@ -2652,7 +2652,7 @@ int hostif_init(struct ks_wlan_private *priv)
priv->aplist.size = 0;
for (i = 0; i < LOCAL_APLIST_MAX; i++)
- memset(&(priv->aplist.ap[i]), 0, sizeof(struct local_ap_t));
+ memset(&priv->aplist.ap[i], 0, sizeof(struct local_ap_t));
priv->infra_status = 0;
priv->current_rate = 4;
priv->connect_status = DISCONNECT_STATUS;
@@ -2675,12 +2675,12 @@ int hostif_init(struct ks_wlan_private *priv)
INIT_WORK(&priv->ks_wlan_wakeup_task, ks_wlan_hw_wakeup_task);
/* WPA */
- memset(&(priv->wpa), 0, sizeof(priv->wpa));
+ memset(&priv->wpa, 0
Re: [Outreachy kernel] [PATCH] Staging: ks7010: There should be no spaces at the start of a line
On Sat, 18 Feb 2017, Arushi Singhal wrote: > The following patch the checkpatch.pl warning: > drivers/staging/ks7010/ks_hostif.c warning: please, no spaces at the > start of a line > > Signed-off-by: Arushi Singhal > --- > drivers/staging/ks7010/ks_hostif.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/ks7010/ks_hostif.c > b/drivers/staging/ks7010/ks_hostif.c > index 819e08b5fa91..3b2e28749b63 100644 > --- a/drivers/staging/ks7010/ks_hostif.c > +++ b/drivers/staging/ks7010/ks_hostif.c > @@ -191,8 +191,8 @@ int get_current_ap(struct ks_wlan_private *priv, struct > link_ap_info_t *ap_info) > } > DPRINTK(4, "\nLink AP\n"); > DPRINTK(4, "bssid=%02X:%02X:%02X:%02X:%02X:%02X\n \ > - essid=%s\nrate_set=%02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n > channel=%d\n \ > - rssi=%d\nsq=%d\ncapability=%04X\n", ap->bssid[0], ap->bssid[1], > ap->bssid[2], ap->bssid[3], ap->bssid[4], ap->bssid[5], &(ap->ssid.body[0]), > ap->rate_set.body[0], ap->rate_set.body[1], ap->rate_set.body[2], > ap->rate_set.body[3], ap->rate_set.body[4], ap->rate_set.body[5], > ap->rate_set.body[6], ap->rate_set.body[7], ap->channel, ap->rssi, ap->sq, > ap->capability); > +essid=%s\nrate_set=%02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n > channel=%d\n \ > +rssi=%d\nsq=%d\ncapability=%04X\n", ap->bssid[0], ap->bssid[1], > ap->bssid[2], ap->bssid[3], ap->bssid[4], ap->bssid[5], &(ap->ssid.body[0]), > ap->rate_set.body[0], ap->rate_set.body[1], ap->rate_set.body[2], > ap->rate_set.body[3], ap->rate_set.body[4], ap->rate_set.body[5], > ap->rate_set.body[6], ap->rate_set.body[7], ap->channel, ap->rssi, ap->sq, > ap->capability); The code looks like a mess. How about breaking up the call at the newlines, and then propagating the arguments to the appropriate calls. There is also a checkpatch error about strings on more than one line, that this also violates. julia > DPRINTK(4, "\nLink AP\nrsn.mode=%d\nrsn.size=%d\n", > ap_info->rsn_mode, ap_info->rsn.size); > DPRINTK(4, "\next_rate_set_size=%d\nrate_set_size=%d\n", > -- > 2.11.0 > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20170218164002.GA7269%40arushi-HP-Pavilion-Notebook. > For more options, visit https://groups.google.com/d/optout. >
[PATCH v2] mmc: meson-gx: remove mmc host on device removal
The mmc host was added in meson_mmc_probe, but never removed in
meson_mmc_remove.
Fix that by removing the host before deallocating other resources.
Signed-off-by: Michał Zegan
Tested-by: Michał Zegan
---
changes since v1:
rebased on top of patchset at
https://patchwork.kernel.org/patch/9581057/
This is in turn based on patchset at
https://patchwork.kernel.org/patch/9561215/
drivers/mmc/host/meson-gx-mmc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index e759e4c2e4a0..336b6a2e94c6 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -791,6 +791,8 @@ static int meson_mmc_remove(struct platform_device *pdev)
{
struct meson_host *host = dev_get_drvdata(&pdev->dev);
+ mmc_remove_host(host->mmc);
+
/* disable interrupts */
writel(0, host->regs + SD_EMMC_IRQ_EN);
--
2.11.0
[PATCH] mmc: meson-gx: fix error path when driver initialization fails before enabling clocks
This patch fixes the case where meson_mmc_probe function fails before core_clk is enabled. Originally, that would result in a try to disable the core clock, and if it was not already enabled, it would result in a kernel warning. This issue is similar to the one with div_clk. Fix it by introducing another error path used only between successfully enabling the core clock, and successfully enabling the div clock. That would ensure that core clock is disabled only if it was enabled before. Signed-off-by: Michał Zegan --- applies on top of Heiner's patchset v3 https://patchwork.kernel.org/patch/9581057/ That in turn applies on top of https://patchwork.kernel.org/patch/9561215/ drivers/mmc/host/meson-gx-mmc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c index 336b6a2e94c6..7917a3fe51ad 100644 --- a/drivers/mmc/host/meson-gx-mmc.c +++ b/drivers/mmc/host/meson-gx-mmc.c @@ -752,7 +752,7 @@ static int meson_mmc_probe(struct platform_device *pdev) ret = meson_mmc_clk_init(host); if (ret) - goto free_host; + goto err_core_clk; ret = devm_request_threaded_irq(&pdev->dev, irq, meson_mmc_irq, meson_mmc_irq_thread, IRQF_SHARED, @@ -781,8 +781,9 @@ static int meson_mmc_probe(struct platform_device *pdev) err_div_clk: clk_disable_unprepare(host->cfg_div_clk); -free_host: +err_core_clk: clk_disable_unprepare(host->core_clk); +free_host: mmc_free_host(mmc); return ret; } -- 2.11.0
Re: [Outreachy kernel] [PATCH 3/6] staging: rtl8192e: Fix block comments warning
On Sat, 18 Feb 2017, SIMRAN SINGHAL wrote: > > > On Saturday, February 18, 2017 at 9:46:48 PM UTC+5:30, Julia Lawall wrote: > > > On Sat, 18 Feb 2017, SIMRAN SINGHAL wrote: > > > > > > > On Saturday, February 18, 2017 at 9:00:51 PM UTC+5:30, Julia > Lawall wrote: > > > > > > On Sat, 18 Feb 2017, simran singhal wrote: > > > > > Align * on a line, to conform to the kernal coding > > > style for block comments. > > > > It is not clear what is means to align * on a line. > What line? > > > > What has been done is to add a space at the beginning of > the > > line. But > > then the line goes over 80 characters and doesn't line > up any > > more on the > > right side. I would guess that you should have gotten a > new > > warning by > > having gone over 80 characters. Fixing one warning > should not > > introduce a > > new one, especially for something purely decorative, > like this. > > > > julia > > > > Julia, I am not getting any new warning. It's not gone over > 80 characters. > > OK, it looked like it would be too long on my screen. > > Are the right sides of the * lines lined up after the change? > > julia > > In the right sides of the * lines, stars are lined up. OK, thanks. julia > > > > > > > > Signed-off-by: simran singhal > > > --- > > > drivers/staging/rtl8192e/rtl819x_HT.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/staging/rtl8192e/rtl819x_HT.h > > b/drivers/staging/rtl8192e/rtl819x_HT.h > > > index 6eb018f..48d101a 100644 > > > --- a/drivers/staging/rtl8192e/rtl819x_HT.h > > > +++ b/drivers/staging/rtl8192e/rtl819x_HT.h > > > @@ -11,7 +11,7 @@ > > > * > > > * Contact Information: > > > * wlanfae > > > >-* > * > > / > > > >+** > * > > ***/ > > > #ifndef _RTL819XU_HTTYPE_H_ > > > #define _RTL819XU_HTTYPE_H_ > > > > > > -- > > > 2.7.4 > > > > > > -- > > > You received this message because you are subscribed > to the > > Google Groups "outreachy-kernel" group. > > > To unsubscribe from this group and stop receiving > emails from > > it, send an email to outreachy-kern...@googlegroups.com. > > > To post to this group, send email to > > outreach...@googlegroups.com. > > > To view this discussion on the > webvisithttps://groups.google.com/d/msgid/outreachy-kernel/20170218152351.GA28 > 908%4 > > 0singhal-Inspiron-5558. > > > For more options, visit > https://groups.google.com/d/optout. > > > > > > > -- > > You received this message because you are subscribed to the > Google Groups > > "outreachy-kernel" group. > > To unsubscribe from this group and stop receiving emails from > it, send an > > email to outreachy-kern...@googlegroups.com. > > To post to this group, send email to > outreach...@googlegroups.com. > > To view this discussion on the > webvisithttps://groups.google.com/d/msgid/outreachy-kernel/5192275f-5b36-4e1d- > 8d66- > > afc735f3a8f6%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web > visithttps://groups.google.com/d/msgid/outreachy-kernel/da5a9bc2-9a49-4fac-b7e8- > eb686d14ad1e%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > >
Re: net: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected in skb_array_produce
On Fri, Feb 10, 2017 at 6:17 AM, Jason Wang wrote: > > > On 2017年02月10日 02:10, Michael S. Tsirkin wrote: >> >> On Thu, Feb 09, 2017 at 05:02:31AM -0500, Jason Wang wrote: >>> >>> - Original Message - Hello, I've got the following report while running syzkaller fuzzer on mmotm (git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git) remotes/mmotm/auto-latest ee4ba7533626ba7bf2f8b992266467ac9fdc045e: >>> [...] >>> other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0CPU1 lock(&(&r->consumer_lock)->rlock); local_irq_disable(); lock(&(&r->producer_lock)->rlock); lock(&(&r->consumer_lock)->rlock); lock(&(&r->producer_lock)->rlock); >>> Thanks a lot for the testing. >>> >>> Looks like we could address this by using skb_array_consume_bh() instead. >>> >>> Could you pls verify if the following patch works? >> >> I think we should use _bh for the produce call as well, >> since resizing takes the producer lock. > > Looks not since irq was disabled during resizing? Hello, Is there a fix for this that we can pick up? This killed 10'000 VMs on our testing infra over the last day. Still happening on linux-next. Thanks
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates
On 02/18/2017 01:23 AM, Russell King - ARM Linux wrote: On Fri, Feb 17, 2017 at 05:12:44PM -0800, Steve Longerbeam wrote: Hi Russell, I signed-off on this but after more review I'm not sure this is right. The CSI-2 receiver really has no control over frame rate. It's output frame rate is the same as the rate that is delivered to it. So this subdev should either not implement these ops, or it should refer them to the attached source subdev. Where in the V4L2 documentation does it say that is permissible? https://www.linuxtv.org/downloads/v4l-dvb-apis-old/vidioc-subdev-g-frame-interval.html "The frame interval only makes sense for sub-devices that can control the frame period on their own. This includes, for instance, image sensors and TV tuners. Sub-devices that don't support frame intervals must not implement these ioctls." If you don't implement these, media-ctl fails to propagate _anything_ to the next sink pad if you specify a frame rate, because media-ctl throws an error and exits immediately. But I agree with you here. I think our only option is to ignore that quoted requirement above and propagate [gs]_frame_interval all the way to the CSI (which can control the frame rate via frame skipping). Steve
Re: [PATCH v4 00/36] i.MX Media Driver
On 02/16/2017 02:57 PM, Russell King - ARM Linux wrote: On Thu, Feb 16, 2017 at 02:27:41PM -0800, Steve Longerbeam wrote: On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote: On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote: In version 4: With this version, I get: [28762.892053] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x [28762.899409] ipu1_csi0: pipeline_set_stream failed with -110 Right, in the imx219, on exit from s_power(), the clock and data lanes must be placed in the LP-11 state. This has been done in the ov5640 and tc358743 subdevs. The only way to do that is to enable streaming from the sensor, wait an initialisation time, and then disable streaming, and wait for the current line to finish. There is _no_ other way to get the sensor to place its clock and data lines into LP-11 state. For that to happen, we need to program the sensor a bit more than we currently do at power on (to a minimal resolution, and setting up the PLLs), and introduce another 4ms on top of the 8ms or so that the runtime resume function already takes. This is basically the same procedure that was necessary to get the OV5640 to enter LP-11 on all its lanes. Power-on procedure writes an initial register set that gets the sensor to a default resolution, turn on streaming briefly (I wait 1msec which is probably too long, but it's not clear to me how to determine that wait time), and then disable streaming. All lanes are then in LP-11 state. Steve
Re: net: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected in skb_array_produce
On Sat, Feb 18, 2017 at 6:28 PM, Dmitry Vyukov wrote: > On Fri, Feb 10, 2017 at 6:17 AM, Jason Wang wrote: >> >> >> On 2017年02月10日 02:10, Michael S. Tsirkin wrote: >>> >>> On Thu, Feb 09, 2017 at 05:02:31AM -0500, Jason Wang wrote: - Original Message - > > Hello, > > I've got the following report while running syzkaller fuzzer on mmotm > (git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git) > remotes/mmotm/auto-latest ee4ba7533626ba7bf2f8b992266467ac9fdc045e: > [...] > other info that might help us debug this: > > Possible interrupt unsafe locking scenario: > > CPU0CPU1 > >lock(&(&r->consumer_lock)->rlock); > local_irq_disable(); > lock(&(&r->producer_lock)->rlock); > lock(&(&r->consumer_lock)->rlock); > > lock(&(&r->producer_lock)->rlock); > Thanks a lot for the testing. Looks like we could address this by using skb_array_consume_bh() instead. Could you pls verify if the following patch works? >>> >>> I think we should use _bh for the produce call as well, >>> since resizing takes the producer lock. >> >> Looks not since irq was disabled during resizing? > > > Hello, > > Is there a fix for this that we can pick up? > This killed 10'000 VMs on our testing infra over the last day. Still > happening on linux-next. Ah, sorry, I see the patch above with skb_array_consume_bh. It's just that it's not in linux-next. Will manually apply it now then. Should we also do something with produce_skb?
Re: [PATCHv2 4/5] perf stat: Add -a as a default target
On Fri, Feb 17, 2017 at 06:48:13PM +0100, Boris Petkov wrote:
> LGTM.
>
> Acked-by: me
Well, it looks good but actually trying it is a different story. For
example:
$ ./perf stat -e amd_nb/event=0xe0,umask=0x1f/ sleep 1
still says because argc is not 0.
So how about the below diff instead?
$ ./perf stat -e amd_nb/event=0xe0,umask=0x1f/
without args dumps the usage message and
$ ./perf stat -e amd_nb/event=0xe0,umask=0x1f/ sleep 1
actually does the system-wide thing:
Performance counter stats for 'system wide':
196,469 amd_nb/event=0xe0,umask=0x1f/
1.001815180 seconds time elapsed
Hmmm?
tools/perf/Documentation/perf-stat.txt | 2 +-
tools/perf/builtin-stat.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
Index: linux/tools/perf/Documentation/perf-stat.txt
===
--- linux.orig/tools/perf/Documentation/perf-stat.txt 2017-02-18
18:38:23.751960730 +0100
+++ linux/tools/perf/Documentation/perf-stat.txt2017-02-18
18:38:23.743960730 +0100
@@ -63,7 +63,7 @@ report::
-a::
--all-cpus::
-system-wide collection from all CPUs
+system-wide collection from all CPUs (default if no target is
specified)
-c::
--scale::
Index: linux/tools/perf/builtin-stat.c
===
--- linux.orig/tools/perf/builtin-stat.c2017-02-18 18:38:23.751960730
+0100
+++ linux/tools/perf/builtin-stat.c 2017-02-18 18:48:33.531959828 +0100
@@ -2445,8 +2445,12 @@ int cmd_stat(int argc, const char **argv
} else if (big_num_opt == 0) /* User passed --no-big-num */
big_num = false;
- if (!argc && target__none(&target))
- usage_with_options(stat_usage, stat_options);
+ /* Make system wide (-a) the default target. */
+ if (target__none(&target)) {
+ if (!argc)
+ usage_with_options(stat_usage, stat_options);
+ target.system_wide = true;
+ }
if (run_count < 0) {
pr_err("Run count must be a positive number\n");
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [RFC v2 00/20] Replace PCI pool by DMA pool API
Le 18/02/2017 à 14:06, Greg Kroah-Hartman a écrit : > On Sat, Feb 18, 2017 at 09:35:36AM +0100, Romain Perier wrote: >> The current PCI pool API are simple macro functions direct expanded to >> the appropriated dma pool functions. The prototypes are almost the same >> and semantically, they are very similar. I propose to use the DMA pool >> API directly and get rid of the old API. >> >> This set of patches, replaces the old API by the dma pool API, adds >> support to warn about this old API in checkpath.pl and remove the >> defines. > Why is this a "RFC" series? Personally, I never apply those as it > implies that the author doesn't think they are ready to be merged :) > > thanks, > > greg k-h Hi, I was not sure about this. I have noticed that most of the API changes are tagged as RFC. I can re-send a v3 without the prefix RFC if you prefer. Thanks, Romain
Re: next_tick hang was Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot
Hi! > > I guess I can. But I'll only have one 80x25 screen to look at... > > > > .config is attached. > > Ah this is x86-32, interesting! I'm going to try to boot that, we never know. > > Thanks a lot! Happens on x86-64, too; I'm running that normally, but for testing, 32-bit kernel is easier. thinkpad x60 works fine for me, so it is unlikely that .config is all it takes... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
> > And I agree that kernel should _not_ attempt rescaling itself, as it > > would lose precision. > > With an almost 1:1 mapping you won't loose precision. How do you propose to do that? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates
On Sat, Feb 18, 2017 at 09:29:17AM -0800, Steve Longerbeam wrote: > On 02/18/2017 01:23 AM, Russell King - ARM Linux wrote: > >On Fri, Feb 17, 2017 at 05:12:44PM -0800, Steve Longerbeam wrote: > >>Hi Russell, > >> > >>I signed-off on this but after more review I'm not sure this is right. > >> > >>The CSI-2 receiver really has no control over frame rate. It's output > >>frame rate is the same as the rate that is delivered to it. > >> > >>So this subdev should either not implement these ops, or it should > >>refer them to the attached source subdev. > > > >Where in the V4L2 documentation does it say that is permissible? > > > > https://www.linuxtv.org/downloads/v4l-dvb-apis-old/vidioc-subdev-g-frame-interval.html > > "The frame interval only makes sense for sub-devices that can control the > frame period on their own. This includes, for instance, image sensors and TV > tuners. Sub-devices that don't support frame intervals must not implement > these ioctls." That sounds clear - but the TV tuner example seems odd - the frame rate is determined at transmission time, not reception time. Yes, it's possible to skip frames (which would be scaling) but you can't _control_ the frame rate per se. > >If you don't implement these, media-ctl fails to propagate _anything_ > >to the next sink pad if you specify a frame rate, because media-ctl > >throws an error and exits immediately. > > > > But I agree with you here. I think our only option is to ignore that > quoted requirement above and propagate [gs]_frame_interval all the way > to the CSI (which can control the frame rate via frame skipping). Sounds like something to tackle the media maintainers over - the documentation vs media-ctl seem to have different ideas on this point. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)
On Thu, Feb 16, 2017 at 09:41:59AM -0600, Tom Lendacky wrote: > create mode 100644 Documentation/x86/amd-memory-encryption.txt > create mode 100644 arch/x86/include/asm/mem_encrypt.h > create mode 100644 arch/x86/kernel/mem_encrypt_boot.S > create mode 100644 arch/x86/kernel/mem_encrypt_init.c > create mode 100644 arch/x86/mm/mem_encrypt.c I don't see anything standing in the way of merging those last two and having a single: arch/x86/kernel/mem_encrypt.c with all functionality in there with ifdeffery around it so that sme_encrypt_kernel() et all are still visible in the !CONFIG_AMD_MEM_ENCRYPT case. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH] staging: lustre: ko2iblnd: Adapt to the removal of ib_get_dma_mr()
In Linux kernel 4.9-rc1, the function ib_get_dma_mr()
was removed and a second parameter was added to ib_alloc_pd().
As this broke the building of the ko2iblnd module in
staging, the Kconfig for LNet has marked ko2iblnd as broken
and stopped building it.
This patch fixes this breakage by:
- Removing the BROKEN tag from lnet/Kconfig.
- Make it so the module parameter map_on_demand can no longer be
zero (we have to configure FMR/FastReg pools; it can no longer be
off).
- No longer try to use the global DMA memory region, but make use
of the FMR/FastReg pool for all RDMA Tx operations.
- Everywhere we are using the device DMA mr to derive the
L-key for non-registered memory regions, use the
pd->local_dma_lkey value instead.
- Make the default map_on_demand = 256. This will allow nodes with
this patch to still connected to older nodes without this patch
and FMR/FastReg turned off. When FMR/FastReg is turned off, we
use 256 as the max frags so the two sides will still be able to
communicate and work.
- Fix a mistake with BUILD_BUG_ON calls in o2iblnd.c which caused
compiling to fail.
Signed-off-by: Doug Oucharek
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-9026
Reviewed-on: https://review.whamcloud.com/#/c/24931/
Reviewed-by: James Simmons
Changelog:
v1) Initial patch
v2) Rebased and handle a fix to BUILD_BUG_ON
---
drivers/staging/lustre/lnet/Kconfig| 1 -
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c| 77 ++
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h| 3 -
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 17 +
.../lustre/lnet/klnds/o2iblnd/o2iblnd_modparams.c | 12 ++--
5 files changed, 16 insertions(+), 94 deletions(-)
diff --git a/drivers/staging/lustre/lnet/Kconfig
b/drivers/staging/lustre/lnet/Kconfig
index 13b4327..2b59301 100644
--- a/drivers/staging/lustre/lnet/Kconfig
+++ b/drivers/staging/lustre/lnet/Kconfig
@@ -35,7 +35,6 @@ config LNET_SELFTEST
config LNET_XPRT_IB
tristate "LNET infiniband support"
depends on LNET && INFINIBAND && INFINIBAND_ADDR_TRANS
- depends on BROKEN
default LNET && INFINIBAND
help
This option allows the LNET users to use infiniband as an
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index b1e8508..0618b79 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -1281,27 +1281,6 @@ static void kiblnd_map_tx_pool(struct kib_tx_pool *tpo)
}
}
-struct ib_mr *kiblnd_find_rd_dma_mr(struct lnet_ni *ni, struct kib_rdma_desc
*rd,
- int negotiated_nfrags)
-{
- struct kib_net *net = ni->ni_data;
- struct kib_hca_dev *hdev = net->ibn_dev->ibd_hdev;
- struct lnet_ioctl_config_o2iblnd_tunables *tunables;
- __u16 nfrags;
- int mod;
-
- tunables = &ni->ni_lnd_tunables->lt_tun_u.lt_o2ib;
- mod = tunables->lnd_map_on_demand;
- nfrags = (negotiated_nfrags != -1) ? negotiated_nfrags : mod;
-
- LASSERT(hdev->ibh_mrs);
-
- if (mod > 0 && nfrags <= rd->rd_nfrags)
- return NULL;
-
- return hdev->ibh_mrs;
-}
-
static void kiblnd_destroy_fmr_pool(struct kib_fmr_pool *fpo)
{
LASSERT(!fpo->fpo_map_count);
@@ -2168,21 +2147,12 @@ static int kiblnd_net_init_pools(struct kib_net *net,
lnet_ni_t *ni, __u32 *cpts
int ncpts)
{
struct lnet_ioctl_config_o2iblnd_tunables *tunables;
- unsigned long flags;
int cpt;
int rc;
int i;
tunables = &ni->ni_lnd_tunables->lt_tun_u.lt_o2ib;
- read_lock_irqsave(&kiblnd_data.kib_global_lock, flags);
- if (!tunables->lnd_map_on_demand) {
- read_unlock_irqrestore(&kiblnd_data.kib_global_lock, flags);
- goto create_tx_pool;
- }
-
- read_unlock_irqrestore(&kiblnd_data.kib_global_lock, flags);
-
if (tunables->lnd_fmr_pool_size < *kiblnd_tunables.kib_ntx / 4) {
CERROR("Can't set fmr pool size (%d) < ntx / 4(%d)\n",
tunables->lnd_fmr_pool_size,
@@ -2227,7 +2197,6 @@ static int kiblnd_net_init_pools(struct kib_net *net,
lnet_ni_t *ni, __u32 *cpts
if (i > 0)
LASSERT(i == ncpts);
- create_tx_pool:
/*
* cfs_precpt_alloc is creating an array of struct kib_tx_poolset
* The number of struct kib_tx_poolsets create is equal to the
@@ -2283,20 +2252,8 @@ static int kiblnd_hdev_get_attr(struct kib_hca_dev *hdev)
return -EINVAL;
}
-static void kiblnd_hdev_cleanup_mrs(struct kib_hca_dev *hdev)
-{
- if (!hdev->ibh_mrs)
- return;
-
- ib_dereg_mr(hdev->ibh_mrs);
-
- hdev->ibh_mrs = NULL;
-}
-
void kiblnd_hdev_destroy(struct kib_hca_dev *hdev)
{
- kiblnd_hdev_cleanup_mrs(hdev);
-
if (hdev->i
[PATCH v2] staging: lustre: ko2iblnd: Adapt to the removal of ib_get_dma_mr()
I tried to send this patch yesterday and it appeared to work. However, I did not see an email from the list. Assuming it failed and trying again. I apologize if this is a repeat.
[PATCH 6/6] staging: rtl8192e: Removed unnecessary parentheses
Extra parentheses were causing checkpatch issues
and were removed.
Signed-off-by: simran singhal
---
drivers/staging/rtl8192e/rtl819x_HTProc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c
b/drivers/staging/rtl8192e/rtl819x_HTProc.c
index cded0f4..1391c91 100644
--- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
@@ -297,7 +297,7 @@ void HTConstructCapabilityElement(struct rtllib_device
*ieee, u8 *posHTCap,
u8 EWC11NHTCap[] = {0x00, 0x90, 0x4c, 0x33};
memcpy(posHTCap, EWC11NHTCap, sizeof(EWC11NHTCap));
- pCapELE = (struct ht_capab_ele *)&(posHTCap[4]);
+ pCapELE = (struct ht_capab_ele *)&posHTCap[4];
*len = 30 + 2;
} else {
pCapELE = (struct ht_capab_ele *)posHTCap;
@@ -663,13 +663,13 @@ void HTInitializeHTInfo(struct rtllib_device *ieee)
pHTInfo->CurrentMPDUDensity = pHTInfo->MPDU_Density;
pHTInfo->CurrentAMPDUFactor = pHTInfo->AMPDU_Factor;
- memset((void *)(&(pHTInfo->SelfHTCap)), 0,
+ memset((void *)(&pHTInfo->SelfHTCap), 0,
sizeof(pHTInfo->SelfHTCap));
- memset((void *)(&(pHTInfo->SelfHTInfo)), 0,
+ memset((void *)(&pHTInfo->SelfHTInfo), 0,
sizeof(pHTInfo->SelfHTInfo));
- memset((void *)(&(pHTInfo->PeerHTCapBuf)), 0,
+ memset((void *)(&pHTInfo->PeerHTCapBuf), 0,
sizeof(pHTInfo->PeerHTCapBuf));
- memset((void *)(&(pHTInfo->PeerHTInfoBuf)), 0,
+ memset((void *)(&pHTInfo->PeerHTInfoBuf), 0,
sizeof(pHTInfo->PeerHTInfoBuf));
pHTInfo->bSwBwInProgress = false;
@@ -685,7 +685,7 @@ void HTInitializeHTInfo(struct rtllib_device *ieee)
pHTInfo->IOTRaFunc = 0;
{
- u8 *RegHTSuppRateSets = &(ieee->RegHTSuppRateSet[0]);
+ u8 *RegHTSuppRateSets = &ieee->RegHTSuppRateSet[0];
RegHTSuppRateSets[0] = 0xFF;
RegHTSuppRateSets[1] = 0xFF;
--
2.7.4
Re: [RFC v2 11/20] scsi: megaraid: Replace PCI pool old API
On Sat, Feb 18, 2017 at 09:35:47AM +0100, Romain Perier wrote:
Hi Romain,
Checkpatch gives some warnings you can fix related to NULL tests before
dma_pool_destroy(), and you changed indentation style in some of your
changes. Some times it is important to keep consistency within a file
even if the style is not the default. Please fix and resend.
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API.
>
> Signed-off-by: Romain Perier
> ---
> drivers/scsi/megaraid/megaraid_mbox.c | 30 -
> drivers/scsi/megaraid/megaraid_mm.c | 29
> drivers/scsi/megaraid/megaraid_sas_base.c | 25 +++---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 51
> +++--
> 4 files changed, 70 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_mbox.c
> b/drivers/scsi/megaraid/megaraid_mbox.c
> index f0987f2..6d0bd3a 100644
> --- a/drivers/scsi/megaraid/megaraid_mbox.c
> +++ b/drivers/scsi/megaraid/megaraid_mbox.c
> @@ -1153,8 +1153,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>
>
> // Allocate memory for 16-bytes aligned mailboxes
> - raid_dev->mbox_pool_handle = pci_pool_create("megaraid mbox pool",
> - adapter->pdev,
> + raid_dev->mbox_pool_handle = dma_pool_create("megaraid mbox pool",
> + &adapter->pdev->dev,
> sizeof(mbox64_t) + 16,
> 16, 0);
>
> @@ -1164,7 +1164,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>
> mbox_pci_blk = raid_dev->mbox_pool;
> for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
> - mbox_pci_blk[i].vaddr = pci_pool_alloc(
> + mbox_pci_blk[i].vaddr = dma_pool_alloc(
> raid_dev->mbox_pool_handle,
> GFP_KERNEL,
> &mbox_pci_blk[i].dma_addr);
> @@ -1181,8 +1181,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>* share common memory pool. Passthru structures piggyback on memory
>* allocted to extended passthru since passthru is smaller of the two
>*/
> - raid_dev->epthru_pool_handle = pci_pool_create("megaraid mbox pthru",
> - adapter->pdev, sizeof(mraid_epassthru_t), 128, 0);
> + raid_dev->epthru_pool_handle = dma_pool_create("megaraid mbox pthru",
> + &adapter->pdev->dev, sizeof(mraid_epassthru_t), 128, 0);
>
> if (raid_dev->epthru_pool_handle == NULL) {
> goto fail_setup_dma_pool;
> @@ -1190,7 +1190,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>
> epthru_pci_blk = raid_dev->epthru_pool;
> for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
> - epthru_pci_blk[i].vaddr = pci_pool_alloc(
> + epthru_pci_blk[i].vaddr = dma_pool_alloc(
> raid_dev->epthru_pool_handle,
> GFP_KERNEL,
> &epthru_pci_blk[i].dma_addr);
> @@ -1202,8 +1202,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>
> // Allocate memory for each scatter-gather list. Request for 512 bytes
> // alignment for each sg list
> - raid_dev->sg_pool_handle = pci_pool_create("megaraid mbox sg",
> - adapter->pdev,
> + raid_dev->sg_pool_handle = dma_pool_create("megaraid mbox sg",
> + &adapter->pdev->dev,
> sizeof(mbox_sgl64) * MBOX_MAX_SG_SIZE,
> 512, 0);
>
> @@ -1213,7 +1213,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
>
> sg_pci_blk = raid_dev->sg_pool;
> for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
> - sg_pci_blk[i].vaddr = pci_pool_alloc(
> + sg_pci_blk[i].vaddr = dma_pool_alloc(
> raid_dev->sg_pool_handle,
> GFP_KERNEL,
> &sg_pci_blk[i].dma_addr);
> @@ -1249,29 +1249,29 @@ megaraid_mbox_teardown_dma_pools(adapter_t *adapter)
>
> sg_pci_blk = raid_dev->sg_pool;
> for (i = 0; i < MBOX_MAX_SCSI_CMDS && sg_pci_blk[i].vaddr; i++) {
> - pci_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
> + dma_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
> sg_pci_blk[i].dma_addr);
> }
> if (raid_dev->sg_pool_handle)
> - pci_pool_destroy(raid_dev->sg_pool_handle);
> + dma_pool_destroy(raid_dev->sg_pool_handle);
>
>
> epthru_pci_blk = raid_dev->epthru_pool;
>
Re: [RFC v2 12/20] scsi: mpt3sas: Replace PCI pool old API
On Sat, Feb 18, 2017 at 09:35:48AM +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commits replaces the PCI pool old
> API by the appropriated function with the DMA pool API.
Please run checkpatch, fix the style issue and resend.
>
> Signed-off-by: Romain Perier
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 73
> +
> 1 file changed, 34 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index a3fe1fb..3c2206d 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -3210,9 +3210,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
> }
>
> if (ioc->sense) {
> - pci_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
> - if (ioc->sense_dma_pool)
> - pci_pool_destroy(ioc->sense_dma_pool);
> + dma_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
> + dma_pool_destroy(ioc->sense_dma_pool);
> dexitprintk(ioc, pr_info(MPT3SAS_FMT
> "sense_pool(0x%p): free\n",
> ioc->name, ioc->sense));
> @@ -3220,9 +3219,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
> }
>
> if (ioc->reply) {
> - pci_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
> - if (ioc->reply_dma_pool)
> - pci_pool_destroy(ioc->reply_dma_pool);
> + dma_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
> + dma_pool_destroy(ioc->reply_dma_pool);
> dexitprintk(ioc, pr_info(MPT3SAS_FMT
> "reply_pool(0x%p): free\n",
> ioc->name, ioc->reply));
> @@ -3230,10 +3228,9 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
> }
>
> if (ioc->reply_free) {
> - pci_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
> + dma_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
> ioc->reply_free_dma);
> - if (ioc->reply_free_dma_pool)
> - pci_pool_destroy(ioc->reply_free_dma_pool);
> + dma_pool_destroy(ioc->reply_free_dma_pool);
> dexitprintk(ioc, pr_info(MPT3SAS_FMT
> "reply_free_pool(0x%p): free\n",
> ioc->name, ioc->reply_free));
> @@ -3244,7 +3241,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
> do {
> rps = &ioc->reply_post[i];
> if (rps->reply_post_free) {
> - pci_pool_free(
> + dma_pool_free(
> ioc->reply_post_free_dma_pool,
> rps->reply_post_free,
> rps->reply_post_free_dma);
> @@ -3256,8 +3253,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
> } while (ioc->rdpq_array_enable &&
> (++i < ioc->reply_queue_count));
>
> - if (ioc->reply_post_free_dma_pool)
> - pci_pool_destroy(ioc->reply_post_free_dma_pool);
> + dma_pool_destroy(ioc->reply_post_free_dma_pool);
> kfree(ioc->reply_post);
> }
>
> @@ -3278,12 +3274,11 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER
> *ioc)
> if (ioc->chain_lookup) {
> for (i = 0; i < ioc->chain_depth; i++) {
> if (ioc->chain_lookup[i].chain_buffer)
> - pci_pool_free(ioc->chain_dma_pool,
> + dma_pool_free(ioc->chain_dma_pool,
> ioc->chain_lookup[i].chain_buffer,
> ioc->chain_lookup[i].chain_buffer_dma);
> }
> - if (ioc->chain_dma_pool)
> - pci_pool_destroy(ioc->chain_dma_pool);
> + dma_pool_destroy(ioc->chain_dma_pool);
> free_pages((ulong)ioc->chain_lookup, ioc->chain_pages);
> ioc->chain_lookup = NULL;
> }
> @@ -3458,23 +3453,23 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER
> *ioc)
> ioc->name);
> goto out;
> }
> - ioc->reply_post_free_dma_pool = pci_pool_create("reply_post_free pool",
> - ioc->pdev, sz, 16, 0);
> + ioc->reply_post_free_dma_pool = dma_pool_create("reply_post_free pool",
> + &ioc->pdev->dev, sz, 16, 0);
> if (!ioc->reply_post_free_dma_pool) {
> pr_err(MPT3SAS_FMT
> - "reply_post_free pool: pci_pool_create failed\n",
> + "reply_post_free pool: dma_pool_create failed\n",
>ioc->name);
> goto out;
> }
> i = 0;
> do {
> ioc->reply_post[i].reply_post_free =
> -
[PATCH v2 3/6] staging: rtl8192e: Fix block comments warning
Align * on last line, to conform to the kernal coding style for block comments. Signed-off-by: simran singhal --- v2: -Modified commit message drivers/staging/rtl8192e/rtl819x_HT.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192e/rtl819x_HT.h b/drivers/staging/rtl8192e/rtl819x_HT.h index 6eb018f..48d101a 100644 --- a/drivers/staging/rtl8192e/rtl819x_HT.h +++ b/drivers/staging/rtl8192e/rtl819x_HT.h @@ -11,7 +11,7 @@ * * Contact Information: * wlanfae -**/ + **/ #ifndef _RTL819XU_HTTYPE_H_ #define _RTL819XU_HTTYPE_H_ -- 2.7.4
Re: [RFC v2 00/20] Replace PCI pool by DMA pool API
On Sat, Feb 18, 2017 at 09:35:36AM +0100, Romain Perier wrote: Tested all patches by compilation and checkpatch. All of them compile fine, but patches 11 and 12 need some fixes. You can resend as PATCH instead of RFC. > The current PCI pool API are simple macro functions direct expanded to > the appropriated dma pool functions. The prototypes are almost the same > and semantically, they are very similar. I propose to use the DMA pool > API directly and get rid of the old API. > > This set of patches, replaces the old API by the dma pool API, adds > support to warn about this old API in checkpath.pl and remove the > defines. > > Changes in v2: > - Introduced patch 18/20 > - Fixed cosmetic changes: spaces before brace, live over 80 characters > - Removed some of the check for NULL pointers before calling dma_pool_destroy > - Improved the regexp in checkpatch for pci_pool, thanks to Joe Perches > - Added Tested-by and Acked-by tags > > Romain Perier (20): > block: DAC960: Replace PCI pool old API > dmaengine: pch_dma: Replace PCI pool old API > IB/mthca: Replace PCI pool old API > net: e100: Replace PCI pool old API > mlx4: Replace PCI pool old API > mlx5: Replace PCI pool old API > wireless: ipw2200: Replace PCI pool old API > scsi: be2iscsi: Replace PCI pool old API > scsi: csiostor: Replace PCI pool old API > scsi: lpfc: Replace PCI pool old API > scsi: megaraid: Replace PCI pool old API > scsi: mpt3sas: Replace PCI pool old API > scsi: mvsas: Replace PCI pool old API > scsi: pmcraid: Replace PCI pool old API > usb: gadget: amd5536udc: Replace PCI pool old API > usb: gadget: net2280: Replace PCI pool old API > usb: gadget: pch_udc: Replace PCI pool old API > usb: host: Remove remaining pci_pool in comments > PCI: Remove PCI pool macro functions > checkpatch: warn for use of old PCI pool API > > drivers/block/DAC960.c| 36 ++--- > drivers/block/DAC960.h| 4 +- > drivers/dma/pch_dma.c | 12 ++--- > drivers/infiniband/hw/mthca/mthca_av.c| 10 ++-- > drivers/infiniband/hw/mthca/mthca_cmd.c | 8 +-- > drivers/infiniband/hw/mthca/mthca_dev.h | 4 +- > drivers/net/ethernet/intel/e100.c | 12 ++--- > drivers/net/ethernet/mellanox/mlx4/cmd.c | 10 ++-- > drivers/net/ethernet/mellanox/mlx4/mlx4.h | 2 +- > drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++-- > drivers/net/wireless/intel/ipw2x00/ipw2200.c | 13 ++--- > drivers/scsi/be2iscsi/be_iscsi.c | 6 +-- > drivers/scsi/be2iscsi/be_main.c | 6 +-- > drivers/scsi/be2iscsi/be_main.h | 2 +- > drivers/scsi/csiostor/csio_hw.h | 2 +- > drivers/scsi/csiostor/csio_init.c | 11 ++-- > drivers/scsi/csiostor/csio_scsi.c | 6 +-- > drivers/scsi/lpfc/lpfc.h | 10 ++-- > drivers/scsi/lpfc/lpfc_init.c | 6 +-- > drivers/scsi/lpfc/lpfc_mem.c | 73 > +-- > drivers/scsi/lpfc/lpfc_scsi.c | 12 ++--- > drivers/scsi/megaraid/megaraid_mbox.c | 30 +-- > drivers/scsi/megaraid/megaraid_mm.c | 29 ++- > drivers/scsi/megaraid/megaraid_sas_base.c | 25 - > drivers/scsi/megaraid/megaraid_sas_fusion.c | 51 ++- > drivers/scsi/mpt3sas/mpt3sas_base.c | 73 > +-- > drivers/scsi/mvsas/mv_init.c | 6 +-- > drivers/scsi/mvsas/mv_sas.c | 6 +-- > drivers/scsi/pmcraid.c| 10 ++-- > drivers/scsi/pmcraid.h| 2 +- > drivers/usb/gadget/udc/amd5536udc.c | 8 +-- > drivers/usb/gadget/udc/amd5536udc.h | 4 +- > drivers/usb/gadget/udc/net2280.c | 12 ++--- > drivers/usb/gadget/udc/net2280.h | 2 +- > drivers/usb/gadget/udc/pch_udc.c | 31 ++-- > drivers/usb/host/ehci-hcd.c | 2 +- > drivers/usb/host/fotg210-hcd.c| 2 +- > drivers/usb/host/oxu210hp-hcd.c | 2 +- > include/linux/mlx5/driver.h | 2 +- > include/linux/pci.h | 9 > scripts/checkpatch.pl | 9 +++- > 41 files changed, 284 insertions(+), 287 deletions(-) > > -- > 2.9.3 >
Re: [PATCH] proc/sysctl: prune stale dentries during unregistering
This patch has locking problem. I've got lockdep splat under LTP.
[ 6633.115456] ==
[ 6633.115502] [ INFO: possible circular locking dependency detected ]
[ 6633.115553] 4.9.10-debug+ #9 Tainted: G L
[ 6633.115584] ---
[ 6633.115627] ksm02/284980 is trying to acquire lock:
[ 6633.115659] (&sb->s_type->i_lock_key#4){+.+...}, at: []
igrab+0x1e/0x80
[ 6633.115834] but task is already holding lock:
[ 6633.115882] (sysctl_lock){+.+...}, at: []
unregister_sysctl_table+0x6b/0x110
[ 6633.116026] which lock already depends on the new lock.
[ 6633.116026]
[ 6633.116080]
[ 6633.116080] the existing dependency chain (in reverse order) is:
[ 6633.116117]
-> #2 (sysctl_lock){+.+...}:
-> #1 (&(&dentry->d_lockref.lock)->rlock){+.+...}:
-> #0 (&sb->s_type->i_lock_key#4){+.+...}:
d_lock nests inside i_lock
sysctl_lock nests inside d_lock in d_compare
This patch adds i_lock nesting inside sysctl_lock.
On 10.02.2017 10:35, Konstantin Khlebnikov wrote:
Currently unregistering sysctl table does not prune its dentries.
Stale dentries could slowdown sysctl operations significantly.
For example, command:
# for i in {1..10} ; do unshare -n -- sysctl -a &> /dev/null ; done
creates a millions of stale denties around sysctls of loopback interface:
# sysctl fs.dentry-state
fs.dentry-state = 25812579 2472413545 0 0 0
All of them have matching names thus lookup have to scan though whole
hash chain and call d_compare (proc_sys_compare) which checks them
under system-wide spinlock (sysctl_lock).
# time sysctl -a > /dev/null
real1m12.806s
user0m0.016s
sys 1m12.400s
Currently only memory reclaimer could remove this garbage.
But without significant memory pressure this never happens.
This patch collects sysctl inodes into list on sysctl table header and
prunes all their dentries once that table unregisters.
Signed-off-by: Konstantin Khlebnikov
Suggested-by: Al Viro
---
fs/proc/inode.c|3 ++
fs/proc/internal.h |7 --
fs/proc/proc_sysctl.c | 59 +++-
include/linux/sysctl.h |1 +
4 files changed, 51 insertions(+), 19 deletions(-)
diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 842a5ff5b85c..7ad9ed7958af 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -43,10 +43,11 @@ static void proc_evict_inode(struct inode *inode)
de = PDE(inode);
if (de)
pde_put(de);
+
head = PROC_I(inode)->sysctl;
if (head) {
RCU_INIT_POINTER(PROC_I(inode)->sysctl, NULL);
- sysctl_head_put(head);
+ proc_sys_evict_inode(inode, head);
}
}
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 2de5194ba378..ed1d762160e6 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -65,6 +65,7 @@ struct proc_inode {
struct proc_dir_entry *pde;
struct ctl_table_header *sysctl;
struct ctl_table *sysctl_entry;
+ struct list_head sysctl_inodes;
const struct proc_ns_operations *ns_ops;
struct inode vfs_inode;
};
@@ -249,10 +250,12 @@ extern void proc_thread_self_init(void);
*/
#ifdef CONFIG_PROC_SYSCTL
extern int proc_sys_init(void);
-extern void sysctl_head_put(struct ctl_table_header *);
+extern void proc_sys_evict_inode(struct inode *inode,
+struct ctl_table_header *head);
#else
static inline void proc_sys_init(void) { }
-static inline void sysctl_head_put(struct ctl_table_header *head) { }
+static inline void proc_sys_evict_inode(struct inode *inode,
+ struct ctl_table_header *head) { }
#endif
/*
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index d4e37acd4821..8efb1e10b025 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -190,6 +190,7 @@ static void init_header(struct ctl_table_header *head,
head->set = set;
head->parent = NULL;
head->node = node;
+ INIT_LIST_HEAD(&head->inodes);
if (node) {
struct ctl_table *entry;
for (entry = table; entry->procname; entry++, node++)
@@ -259,6 +260,29 @@ static void unuse_table(struct ctl_table_header *p)
complete(p->unregistering);
}
+/* called under sysctl_lock */
+static void proc_sys_prune_dcache(struct ctl_table_header *head)
+{
+ struct inode *inode, *prev = NULL;
+ struct proc_inode *ei;
+
+ list_for_each_entry(ei, &head->inodes, sysctl_inodes) {
+ inode = igrab(&ei->vfs_inode);
+ if (inode) {
+ spin_unlock(&sysctl_lock);
+ iput(prev);
+ prev = inode;
+ d_prune_aliases(inode);
+ spin_lock(&sysctl_lock);
+ }
+ }
+ if (prev) {
+ spin_
