Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv() in net/dccp/ipv6.c,
similar
to the handling in net/ipv6/tcp_ipv6.c
Signed-off-by: Andrii Vladyka
---
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 1b58eac..35c2edb 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -16,6 +16,7 @@
#
On 08/28, Arvind Yadav wrote:
> clk_ops are not supposed to change at runtime. All functions
> working with clk_ops provided by work
> with const clk_ops. So mark the non-const clk_ops as const.
>
> Here, Function "clk_reg_prcc" is used to initialized clk_init_data.
> clk_init_data is working wit
On 08/28, Arvind Yadav wrote:
> clk_ops are not supposed to change at runtime. All functions
> working with clk_ops provided by work
> with const clk_ops. So mark the non-const clk_ops as const.
>
> Here, Function "clk_reg_sysctrl" is used to initialized clk_init_data.
> clk_init_data is working
On 08/28, Arvind Yadav wrote:
> clk_ops are not supposed to change at runtime. All functions
> working with clk_ops provided by work
> with const clk_ops. So mark the non-const clk_ops as const.
>
> Here, Function "clk_reg_prcmu" is used to initialized clk_init_data.
> clk_init_data is working wi
On Wed 30-08-17 19:49:04, Andrea Arcangeli wrote:
> Hello Michal,
>
> On Wed, Aug 30, 2017 at 10:46:00AM +0200, Michal Hocko wrote:
> > +* TODO: we really want to get rid of this ugly hack and make sure that
> > +* notifiers cannot block for unbounded amount of time and add
> > +* mmu_
On 08/28, Kunihiko Hayashi wrote:
> Add clock control for ethernet controller on Pro4, PXs2, LD11 and LD20.
>
> Signed-off-by: Kunihiko Hayashi
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
On 08/28, Arvind Yadav wrote:
> clk_div_table are not supposed to change at runtime. All functions
> working with clk_div_table provided by work
> with const clk_div_table. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
> ---
Applied to clk-next
--
Qualcomm Innovation
On 08/28, Arvind Yadav wrote:
> clk_div_table are not supposed to change at runtime. All functions
> working with clk_div_table provided by work
> with const clk_div_table. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
> ---
Applied to clk-next
--
Qualcomm Innovation
On Tue 29-08-17 13:28:23, Michal Hocko wrote:
> On Tue 29-08-17 20:20:39, Tetsuo Handa wrote:
> > On 2017/08/29 7:33, Andrew Morton wrote:
> > > On Mon, 28 Aug 2017 11:33:41 +0200 Michal Hocko wrote:
> > >
> > >> drain_all_pages backs off when called from a kworker context since
> > >> 0ccce3b924
On 08/25, Eugeniy Paltsev wrote:
> HSDK board manages its clocks using various PLLs. These PLL have same
> dividers and corresponding control registers mapped to different addresses.
> So we add one common driver for such PLLs.
>
> Each PLL on HSDK board consists of three dividers: IDIV, FBDIV and
On 08/22, Bhumika Goyal wrote:
> Make this const as it is only stored in the const field of a
> clk_init_data structure.
>
> Signed-off-by: Bhumika Goyal
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Add CPU idle state nodes to enable C1/C2 idle states.
Signed-off-by: James Liao
---
This patch bases on latest Matthias v4.13-next/dts64 branch [1],
add CPU idle states for MT2712.
[1] https://github.com/mbgg/linux-mediatek.git
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 25 +++
On Thu, Aug 31, 2017 at 12:53 AM, Andy Shevchenko
wrote:
> On Sat, Aug 19, 2017 at 11:22 AM, Bhumika Goyal wrote:
>> Make these const as they are only stored in the type field of a device
>> structure, which is const.
>> Done using Coccinelle.
>>
>
> Please, stop spamming so many people and MLs w
On Wed, Aug 30, 2017 at 11:41 PM, Tony Lindgren wrote:
> Hi Timur, Linus & Grygorii,
>
> Looks like commit 108d23e322a2 ("gpiolib: request the gpio before
> querying its direction") caused a regression on at least pandaboard
> es with booting hanging shortly after gpio init.
>
> It seems to be th
Here, prototype of thermal_zone_device_register is not matching
with static inline thermal_zone_device_register. One is using
const thermal_zone_params. Other is using non-const.
Signed-off-by: Arvind Yadav
---
include/linux/thermal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
On Tue, Aug 29, 2017 at 03:07:08PM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Mon, Feb 20, 2017 at 10:48 PM, Linux Kernel Mailing List
> wrote:
> > Web:
> > https://git.kernel.org/torvalds/c/bc88c10d7e6900916f5e1ba3829d66a9de92b633
> > Commit: bc88c10d7e6900916f5e1ba3829d66a9d
On 30/08/17 16:04, Ritesh Harjani wrote:
> Without this patch the CQHCI registers are getting reset
> again.
>
> Signed-off-by: Ritesh Harjani
> ---
> drivers/mmc/host/cqhci.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/
Hi,
while testing the read-write unfairness issues reported by Mel, I
found BFQ failing to guarantee good responsiveness against heavy
random sync writes in the background, i.e., multiple writers doing
random writes and systematic fdatasync [1]. The failure was caused by
three related bugs, because
If the function bfq_update_next_in_service is invoked as a consequence
of the activation or requeueing of an entity, say E, and finds out
that E belongs to a higher-priority class than that of the current
next-in-service entity, then it sets next_in_service directly to
E. But this may lead to anoma
To provide a very smooth service, bfq starts to serve a bfq_queue
only if the queue is 'eligible', i.e., if the same queue would
have started to be served in the ideal, perfectly fair system that
bfq simulates internally. This is obtained by associating each
queue with a virtual start time, and by
If the function bfq_update_next_in_service is invoked as a consequence
of the activation or requeueing of an entity, say E, then it doesn't
invoke bfq_lookup_next_entity to get the next-in-service entity. In
contrast, it follows a shorter path: if E happens to be eligible (see
commit "bfq-sq-mq: ma
On Wed, 2017-08-30 at 17:57 +0300, David Weinehall wrote:
> On Tue, Aug 22, 2017 at 10:37:29AM +0300, Luca Coelho wrote:
> > From: Luca Coelho
> >
> > Work queues cannot be allocated when a mutex is held because the mutex
> > may be in use and that would make it sleep. Doing so generates the
> >
Hi all,
Since this is a blocker bug found on SGI UV system and only happen on
SGI UV system, and expert from HPE SGI UV dev team, Mike Travis sent
private mail to me saying that I can add his Acked-by to this patchset
if repost, I will repost with updated patch log. Currently without this
fix, SGI
Hi,
On Mon, Aug 28, 2017 at 1:41 PM, Andi Kleen wrote:
>> So I think we are good to go. to capture multiplexing scaling factor
>> when sampling simply use the S
>> modifier.
>> But to my surprise, newer kernels are not happy with the cmdline:
>> $ perf record -e cycles:S noploop 1
>> Error:
>>
On 8/31/2017 1:58 AM, Andrew Morton wrote:
On Wed, 30 Aug 2017 13:02:22 +0530 Prakash Gupta wrote:
The stacktraces always begin as follows:
[] save_stack_trace_tsk+0x0/0x98
[] save_stack_trace+0x24/0x28
...
This is because the stack trace code includes the stack frames for itself.
Th
On Wed, 30 Aug 2017, Himanshu Jha wrote:
> kfree on NULL pointer is a no-op and therefore checking is redundant.
IMO the code has more clarity as it is.
BR,
Jani.
>
> Signed-off-by: Himanshu Jha
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 6 ++
> 1 file changed, 2 insertions(+), 4 del
Fixed checkpatch errors, spaces before tabs.
Found using checkpatch.
Signed-off-by: Derek Robson
---
drivers/staging/pi433/rf69.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/pi433/rf69.h b/drivers/staging/pi433/rf69.h
index fbccaae51c61..5c0c95628f2f
'Object code reading' test always fails on powerpc. Two reasons for
the failure are:
1. When elf section is too big (size beyond 'unsigned int' max value).
objdump fails to disassemble from such section. This was fixed with
commit 0f6329bd7fc ("binutils/objdump: Fix disassemble for huge elf
sectio
Tested-by: Oleksander Natalenko
I'm "Oleksandr" :).
31.08.2017 08:10, Paolo Valente wrote:
Hi,
while testing the read-write unfairness issues reported by Mel, I
found BFQ failing to guarantee good responsiveness against heavy
random sync writes in the background, i.e., multiple writers doing
> Il giorno 31 ago 2017, alle ore 08:41, oleksa...@natalenko.name ha scritto:
>
>> Tested-by: Oleksander Natalenko
>
> I'm "Oleksandr" :).
>
Sorry, resending ...
Paolo
> 31.08.2017 08:10, Paolo Valente wrote:
>> Hi,
>> while testing the read-write unfairness issues reported by Mel, I
>> fou
If the function bfq_update_next_in_service is invoked as a consequence
of the activation or requeueing of an entity, say E, then it doesn't
invoke bfq_lookup_next_entity to get the next-in-service entity. In
contrast, it follows a shorter path: if E happens to be eligible (see
commit "bfq-sq-mq: ma
To provide a very smooth service, bfq starts to serve a bfq_queue
only if the queue is 'eligible', i.e., if the same queue would
have started to be served in the ideal, perfectly fair system that
bfq simulates internally. This is obtained by associating each
queue with a virtual start time, and by
[SECOND TAKE, with just the name of one of the tester fixed]
Hi,
while testing the read-write unfairness issues reported by Mel, I
found BFQ failing to guarantee good responsiveness against heavy
random sync writes in the background, i.e., multiple writers doing
random writes and systematic fdatas
If the function bfq_update_next_in_service is invoked as a consequence
of the activation or requeueing of an entity, say E, and finds out
that E belongs to a higher-priority class than that of the current
next-in-service entity, then it sets next_in_service directly to
E. But this may lead to anoma
On 30/08/17 16:04, Ritesh Harjani wrote:
> When CMDQ is halted the HW expects descriptor size to
> be same which is using in CMDQ mode.
> Thus adjust the desc_sz of sdhci accordingly.
>
> Without this patch below command gives ADMA error
> when CQE is enabled.
> cat /sys/kernel/debug/mmc0/mmc0:000
Hi Anthony,
On Tue, Aug 22, 2017 at 06:03:38PM +0900, Anthony Kim wrote:
> The HiDeep touchscreen device is a capacitive multi-touch controller
> mainly for multi-touch supported devices use. It use I2C interface for
> communication to IC and provide axis X, Y, Z locations for ten finger
> touch t
On Thu 2017-08-31 07:44:58, Kalle Valo wrote:
> David Miller writes:
>
> > From: Kalle Valo
> > Date: Wed, 30 Aug 2017 20:31:31 +0300
> >
> >> AFAICS the bug was introduced by 9df86e2e702c6 back in 2010. If the bug
> >> has been there for 7 years so waiting for a few more weeks should not
> >> h
On 30 August 2017 at 19:16, Michael Ellerman wrote:
> Joe Stringer writes:
>
>> On 30 August 2017 at 15:59, Andrew Morton wrote:
>>> On Tue, 29 Aug 2017 16:01:14 -0700 Joe Stringer wrote:
>>>
Recent changes[0] to make use of __compiletime_assert() from
container_of() increased the usa
Hi Bjorn,
After merging the rpmsg tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "qcom_glink_native_probe" [drivers/rpmsg/qcom_glink_rpm.ko] undefined!
ERROR: "qcom_glink_native_remove" [drivers/rpmsg/qcom_glink_rpm.ko] undefined!
Maybe caused by commit
6799c434
On 08/30/2017 03:02 PM, Laurent Dufour wrote:
> On 30/08/2017 07:58, Peter Zijlstra wrote:
>> On Wed, Aug 30, 2017 at 10:33:50AM +0530, Anshuman Khandual wrote:
>>> diff --git a/mm/filemap.c b/mm/filemap.c
>>> index a497024..08f3042 100644
>>> --- a/mm/filemap.c
>>> +++ b/mm/filemap.c
>>> @@ -1181,
On 31/08/17 09:38, Ravi Bangoria wrote:
> 'Object code reading' test always fails on powerpc. Two reasons for
> the failure are:
>
> 1. When elf section is too big (size beyond 'unsigned int' max value).
> objdump fails to disassemble from such section. This was fixed with
> commit 0f6329bd7fc ("b
On Thu, Aug 31, 2017 at 07:52:41AM +0300, Amir Goldstein wrote:
> On Thu, Aug 31, 2017 at 6:51 AM, Xiong Zhou wrote:
> > hi,
> >
> > This happens on 4.13.0-rc7+ to commit 42ff72c
>
> Don't understand. Is this a regression? from which commit?
No. I'm just saying the exact kernel version: Linus tr
Hi Liam,
> Am 30.08.2017 um 13:24 schrieb Liam Breck :
>
> Hi Nikolaus,
>
> On Wed, Aug 30, 2017 at 2:30 AM, H. Nikolaus Schaller
> wrote:
>> Hi Liam and Sebastian,
>>
>>> Am 29.08.2017 um 22:20 schrieb Liam Breck :
>>>
>>> Hi Nikolaus, thanks for the patch...
>>>
>>> On Tue, Aug 29, 2017 a
801 - 843 of 843 matches
Mail list logo
