On Fri, Sep 06, 2019 at 02:22:43PM +0300, Heikki Krogerus wrote:
> Hi,
>
> On Thu, Sep 05, 2019 at 09:38:08PM -0700, Dmitry Torokhov wrote:
> > Now that static device properties allow defining reference properties
> > together with all other types of properties, instead of managing them
> >
Remove the superfluous NET_DSA_TAG_KSZ_COMMON and just use the existing
NET_DSA_TAG_KSZ. Update the description to mention the three switch
families it supports. No functional change.
Signed-off-by: George McCollister
---
net/dsa/Kconfig | 9 ++---
net/dsa/Makefile | 2 +-
2 files changed,
From: Tristram Ha
Add KSZ9477 I2C driver support. The code ksz9477.c and ksz_common.c are
used together to generate the I2C driver.
Signed-off-by: Tristram Ha
[george.mccollis...@gmail.com: bring up to date, use ksz_common regmap macros]
Signed-off-by: George McCollister
---
Add support for the KSZ9567 7-Port Gigabit Ethernet Switch to the
ksz9477 driver. The KSZ9567 supports both SPI and I2C. Oddly the
ksz9567 is already in the device tree binding documentation.
Signed-off-by: George McCollister
---
drivers/net/dsa/microchip/ksz9477.c | 9 +
Resurrect KSZ9477 I2C driver support patch originally sent to the list
by Tristram Ha and resolve outstanding issues. It now works as similarly to
the ksz9477 SPI driver as possible, using the same regmap macros.
Add support for ksz9567 to the ksz9477 driver (tested on a board with
ksz9567
Our hardware (UV aka Superdome Flex) has address ranges marked
reserved by the BIOS. These ranges can cause the system to halt if
accessed.
During kernel initialization, the processor was speculating into
reserved memory causing system halts. The processor speculation is
enabled because the
Hi,
On Fri, Sep 6, 2019 at 2:20 AM Ulf Hansson wrote:
>
> On Fri, 6 Sep 2019 at 01:47, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Sep 3, 2019 at 7:22 AM Ulf Hansson wrote:
> > >
> > > In the single SDIO IRQ handler case, the sdio_irq_pending flag is used to
> > > avoid reading the
> On Sep 6, 2019, at 1:51 PM, Jeff Layton wrote:
>
> On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
>
>> I’m not at all convinced that the kernel needs to distinguish all these, but
>> at least upgradability should be its own thing IMO.
>
> Good point. Upgradability is definitely
Quoting Fuqian Huang (2019-07-03 09:27:00)
> kmemdup is introduced to duplicate a region of memory in a neat way.
> Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
> write the size twice (sometimes lead to mistakes), kmemdup improves
> readability, leads to smaller code and
On Fri, 2019-09-06 at 13:32 +0900, Sergey Senozhatsky wrote:
> On (09/05/19 12:03), Qian Cai wrote:
> > > ---
> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > index cd51aa7d08a9..89cb47882254 100644
> > > --- a/kernel/printk/printk.c
> > > +++ b/kernel/printk/printk.c
> > >
On Fri, 6 Sep 2019, Johannes Erdfelt wrote:
> On Fri, Sep 06, 2019, Thomas Gleixner wrote:
> > What your customers are asking for is a receipe for disaster. They can
> > check the safety of late loading forever, it will not magically become safe
> > because they do so.
> >
> > If you want late
Quoting p...@codeaurora.org (2019-09-06 05:51:54)
> +Georgi Djakov
>
> On 2019-09-06 18:17, Pradeep P V K wrote:
> > diff --git a/drivers/mmc/host/sdhci-msm.c
> > b/drivers/mmc/host/sdhci-msm.c
> > index b75c82d..71515ca 100644
> > --- a/drivers/mmc/host/sdhci-msm.c
> > +++
FWIW, I found a suitable workaround now to get my use case working
with existing kernels: I can do the mode switch from userspace, then
after the device reenumerates I can manually disable any interfaces I
don't like by writing 0 to their 'authorized' node, and then I write
the VID/PID to
Currently the Linux Kernel Memory Model gives an incorrect response
for the following litmus test:
C plain-WWC
{}
P0(int *x)
{
WRITE_ONCE(*x, 2);
}
P1(int *x, int *y)
{
int r1;
int r2;
int r3;
r1 = READ_ONCE(*x);
if (r1 == 2) {
On Fri, 2019-09-06 at 20:38 +0200, volery wrote:
> There were some parentheses at the end of lines, which I took care of.
Not every instance of this checkpatch warning should be changed.
This specific instance is because it uses very long identifiers
and really maybe should just be left alone.
Use the bark interrupt as the pre-timeout notifier whenever this
interrupt is available.
By default, the pretimeout notification shall occur one second earlier
than the timeout.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/qcom-wdt.c | 70 ++---
1
there is no need to continue keeping the clock in private storage.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/qcom-wdt.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
index
Support pre-timeout when the bark irq is avaible.
This is the fifth version of the patchset addressing all the review
issues to date:
v5:
include linux/bits.h
pretimeout only enables IRQs if value != 0
remove unnecessary subtract operation
add clarity to the conditional in the
> On Sep 6, 2019, at 4:47 PM, Jason L Tibbitts III wrote:
>
>> "JBF" == J Bruce Fields writes:
>
> JBF> Those readdir changes were client-side, right? Based on that I'd
> JBF> been assuming a client bug, but maybe it'd be worth getting a full
> JBF> packet capture of the readdir reply
On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
> > On Sep 6, 2019, at 12:43 PM, Jeff Layton wrote:
> >
> > > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > > On 2019-09-06, Jeff Layton wrote:
> > > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > >
On Thu, 5 Sep 2019, Vlastimil Babka wrote:
> >> - failing order-0 watermark checks in memory compaction does not account
> >>for how far below the watermarks the zone actually is: to enable
> >>migration, there must be *some* free memory available. Per the above,
> >>watermarks are
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, September 6, 2019 3:35 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH v3 08/10] EDAC/amd64: Gather hardware
> "JBF" == J Bruce Fields writes:
JBF> Those readdir changes were client-side, right? Based on that I'd
JBF> been assuming a client bug, but maybe it'd be worth getting a full
JBF> packet capture of the readdir reply to make sure it's legit.
I have been working with bcodding on IRC for the
Hi,
> Am 06.09.2019 um 05:01 schrieb Viresh Kumar :
>
> On 05-09-19, 07:32, Tony Lindgren wrote:
>> * H. Nikolaus Schaller [190904 08:54]:
>>> This adds code and tables to read the silicon revision and
>>> eFuse (speed binned / 720 MHz grade) bits for selecting
>>> opp-v2 table entries.
>>>
Hi, Andrew.
I'm not familiar with generic PHY HW archs but suppose that it is
proprietary to TI.
I'v never seen such feature so moved it in TI dts field.
Vitaly.
06.09.2019 22:29, Andrew Lunn wrote:
On Thu, Sep 05, 2019 at 07:26:00PM +0300, Vitaly Gaiduk wrote:
Add documentation of
This change introduces a new debugfs file 'test_event' that when written
to causes the EC to generate a test event.
Signed-off-by: Daniel Campello
---
drivers/platform/chrome/wilco_ec/debugfs.c | 33 +-
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git
Quoting Bjorn Andersson (2019-09-06 11:25:30)
> On Thu 05 Sep 22:26 PDT 2019, Stephen Boyd wrote:
>
> >
> > Yes this looks like the approach that should be taken. One question
> > though, is this a micro-b connector or a type-c connector on the board?
> > I thought it was a type-c, so then this
Just a single lpfc fix adjusting the number of available queues for
high CPU count systems.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
James Smart (1):
scsi: lpfc: Raise config max for lpfc_fcp_mq_threshold
Quoting Vinod Koul (2019-09-05 21:56:59)
> Update the gcc qcs404 clock driver to use floor ops for sdcc clocks. As
> disuccsed in [1] it is good idea to use floor ops for sdcc clocks as we
> dont want the clock rates to do round up.
>
> [1]:
>
On Fri, Sep 06, 2019 at 07:14:57PM +, Ghannam, Yazen wrote:
> This struct is used per channel, so we may have 2-8 per system.
Ah, true.
> We could fix it at the max (8). What do you think?
Anything in struct amd64_umc that is shared between those channels or
all max 8 of them can be
As per Documentation/process/submit-checklist.rst, when using a
facility #include the file that defines/declares that facility.
Don't depend on other header files pulling in ones that you use.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/pm8916_wdt.c | 1 +
1 file changed, 1
When an IRQ is present in the dts, the probe function shall fail if
the interrupt can not be registered.
The probe function shall also be retried if getting the irq is being
deferred.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/pm8916_wdt.c | 16
1 file changed, 12
On Thu, 5 Sep 2019, Mike Kravetz wrote:
> I don't have a specific test for this. It is somewhat common for people
> to want to allocate "as many hugetlb pages as possible". Therefore, they
> will try to allocate more pages than reasonable for their environment and
> take what they can get. I
On Thu, Sep 5, 2019 at 10:53 PM Linus Torvalds
wrote:
>
> That's probably what we should have done originally, avoiding all the
> issues with "what if we have multi-part strings" etc.
>
> But it's not what we did, probably because it looked slightly simpler
> to do the stringification in the
On Fri, Sep 06, 2019 at 10:24:20AM -0700, lon...@linuxonhyperv.com wrote:
From: Long Li
storvsc doesn't use a dedicated hardware queue for a given CPU queue. When
issuing I/O, it selects returning CPU (hardware queue) dynamically based on
vmbus channel usage across all channels.
This patch
> On Sep 6, 2019, at 12:43 PM, Jeff Layton wrote:
>
>> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
>>> On 2019-09-06, Jeff Layton wrote:
On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> On 06/09/2019 17:56, Florian Weimer wrote:
> Let's assume I want to add
On Thu, Sep 05, 2019 at 11:01:14PM +, Dexuan Cui wrote:
This patchset (consisting of 9 patches) was part of the v4 patchset (consisting
of 12 patches):
https://lkml.org/lkml/2019/9/2/894
The other 3 patches in v4 are posted in another patchset, which will go
through the tip.git tree.
Commit d098913a10f8 ("bus: ti-sysc: Fix clock handling for no-idle
quirks") fixed handling for no-idle quirk modules that are not enabled
by the bootloader.
But it also caused unpaired clockdomain calls that won't allow idling
the system. That's because clkdm_allow_idle_nolock() and
The commit 108c14858b9e ("locking/lockdep: Add support for dynamic
keys") introduced a boot warning on powerpc below, because since the
commit 2d4f567103ff ("KVM: PPC: Introduce kvm_tmp framework") adds
kvm_tmp[] into the .bss section and then free the rest of unused spaces
back to the page
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
tags/libnvdimm-fix-5.3-rc8
...to receive a fix for a regression introduced in v5.3-rc1. The
latest version has shipped in -next with no reported issues.
---
The following changes since commit
The pull request you sent on Fri, 6 Sep 2019 21:48:09 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/36daa831b55538dc2e4a906de20c5d91033ebb21
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Fri, 6 Sep 2019 17:56:50 +0200:
> git://git.infradead.org/users/hch/configfs.git tags/configfs-for-5.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/30d7030b2fb39d9b53270b2fe0caac8e8792890c
Thank you!
--
Deet-doot-dot, I am a bot.
On Thu 05 Sep 21:56 PDT 2019, Vinod Koul wrote:
> Update the gcc qcs404 clock driver to use floor ops for sdcc clocks. As
> disuccsed in [1] it is good idea to use floor ops for sdcc clocks as we
> dont want the clock rates to do round up.
>
> [1]:
>
On (09/06/19 16:01), Peter Zijlstra wrote:
> > 2. The simple approach works only with lockless consoles. We need
> >something else for the rest at least for NMI. Simle offloading
> >to a kthread has been blocked for years. People wanted the
> >trylock-and-flush-immediately approach.
>
Em Fri, 06 Sep 2019 11:12:58 -0700
Joe Perches escreveu:
> On Fri, 2019-09-06 at 08:34 -0300, Mauro Carvalho Chehab wrote:
> > Warning: SPDX header for file tools/thermal/tmon/tmon.8 is at line 2
> []
> > The last one is interesting... what's the "very first line" where a
> > SPDX header tag
On (09/06/19 16:55), Petr Mladek wrote:
> > I think we can queue significantly much less irq_work-s from printk().
> >
> > Petr, Steven, what do you think?
> >
> > Something like this. Call wake_up_interruptible(), switch to
> > wake_up_klogd() only when called from sched code.
>
> Replacing
For controller drivers that use DMA and set NAND_USE_BOUNCE_BUFFER
option use data buffers that are not vmalloced, aligned and have
valid virtual address to be able to do DMA transfers. This change
adds additional check and makes use of data buffer allocated
in nand_base driver when it is passed a
This change adds support for flash dma v0.0.
Signed-off-by: Kamal Dasu
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
On Fri, 6 Sep 2019 at 06:27, Rashmica Gupta wrote:
>
> Use the ngpio property from the device tree if it exists. If it doesn't
> then fallback to the hardcoded value in the config.
>
> This is in preparation for adding ast2600 support. The ast2600 SoC has
> two GPIO controllers and so requires
The following changes since commit 089cf7f6ecb266b6a4164919a2e69bd2f938374a:
Linux 5.3-rc7 (2019-09-02 09:57:40 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes
for you to fetch changes up to
On Fri, 6 Sep 2019 at 06:26, Rashmica Gupta wrote:
>
> This is in preparation for adding ast2600 support. The ast2600 SoC
> requires two instances of the GPIO driver as it has two GPIO
> controllers. Each instance needs it's own irqchip.
>
> Signed-off-by: Rashmica Gupta
Reviewed-by: Joel
On Fri, 6 Sep 2019 at 06:26, Rashmica Gupta wrote:
>
> The current calculation for the number of GPIO banks is only correct if
> the number of GPIOs is a multiple of 32 (if there were 31 GPIOs we would
> currently say there are 0 banks, which is incorrect).
>
> Fixes: 361b79119a4b7 ('gpio: Add
On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> On 2019-09-06, Jeff Layton wrote:
> > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > Let's assume I want to add support for this to the glibc dynamic loader,
> > > > while
On Thu, Sep 05, 2019 at 11:53:48PM +0800, zhong jiang wrote:
> The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d
> but is perhaps more readable.
Hi Zhong
Did you find this by hand, or did you use a tool. If a tool is used,
it is normal to give some credit to the tool.
On Fri, Sep 06, 2019 at 08:50:07PM +0200, Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 6 Sep 2019 20:40:06 +0200
>
> Simplify these function implementations by using a known function.
>
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>
> Signed-off-by: Markus Elfring
Thanks
On Thu, Sep 05, 2019 at 07:26:00PM +0300, Vitaly Gaiduk wrote:
> Add documentation of ti,sgmii-type which can be used to select
> SGMII mode type (4 or 6-wire).
Hi Vitaly
Is 4 vs 6-wire a generic SGMII property? Or is it proprietary to TI?
I did a quick search and i could not find any other
> On Sep 6, 2019, at 12:07 PM, Steve Grubb wrote:
>
>> On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
>> * Steve Grubb:
>>> Now with LD_AUDIT
>>> $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test
>>> 2>&1 | grep passwd openat(3, "passwd", O_RDONLY)
There were some parentheses at the end of lines, which I took care of.
This is my first patch.
Signed-off-by: Sandro Volery
---
drivers/staging/gasket/apex_driver.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/gasket/apex_driver.c
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 ---
2 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index
dpu_kms.dev will never be NULL, so don't bother checking.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 8 -
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 30 +--
3 files changed,
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 4c889aabdaf9..6ceba33a179e 100644
---
msm_drm_private.kms will only be NULL in the dummy headless case, so
there is no need to check it in the dpu display driver.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 23 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 12 +++---
In embedded environments the requirements are to be able to pick and
chose which features one requires built into the kernel. If an
embedded environment wants to supports loading modules that have been
kbuilt out of tree, there is a need to enable hidden configurations
for legacy wireless core
Zdravstvujte! Vas interesujut klientskie bazy dannyh?
On 9/6/19 19:40, Bjorn Andersson wrote:
> On Thu 05 Sep 14:00 PDT 2019, Jorge Ramirez-Ortiz wrote:
>> diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
> [..]
>> +static inline int qcom_get_enable(struct watchdog_device *wdd)
>> +{
>> +int enable = QCOM_WDT_ENABLE;
>> +
>>
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Borislav Petkov
> Sent: Thursday, August 29, 2019 4:23 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH v3 08/10] EDAC/amd64: Gather hardware
Use an explicit "cfs_rq of parent sched_entity" helper in a few
strategic places, where cfs_rq_of(se) may no longer point at the
right runqueue once we flatten the hierarchical cgroup runqueues.
No functional change.
Signed-off-by: Rik van Riel
---
kernel/sched/fair.c | 17 +
1
Refactor enqueue_entity, dequeue_entity, and update_load_avg, in order
to split out the things we still want to happen at every level in the
cgroup hierarchy with a flat runqueue from the things we only need to
happen once.
No functional changes.
Signed-off-by: Rik van Riel
---
Reducing the overhead of the CPU controller is achieved by not walking
all the sched_entities every time a task is enqueued or dequeued.
One of the things being checked every single time is whether the cfs_rq
is on the rq->leaf_cfs_rq_list.
By only removing a cfs_rq from the list once it no
From: Long Li Sent: Friday, September 6, 2019 10:24 AM
>
> storvsc doesn't use a dedicated hardware queue for a given CPU queue. When
> issuing I/O, it selects returning CPU (hardware queue) dynamically based on
> vmbus channel usage across all channels.
>
> This patch advertises
Sometimes the hierarchical load of a sched_entity needs to be calculated.
Rename task_h_load to task_se_h_load, and directly pass a sched_entity to
that function.
Move the function declaration up above where it will be used later.
No functional changes.
Signed-off-by: Rik van Riel
Reviewed-by:
Since only the root cfs_rq runnable_load_avg field is used any more,
we can move the field from struct sched_avg, which every sched_entity
has one of, directly into the struct cfs_rq, of which we have way fewer.
No functional changes.
Suggested-by: Dietmar Eggemann
Signed-off-by: Rik van Riel
The way the time slice length is currently calculated, not only do high
priority tasks get longer time slices than low priority tasks, but due
to fixed point math, low priority tasks could end up with a zero length
time slice. This can lead to cache thrashing and other inefficiencies.
Cap the
When a task wakes back up after having gone to sleep, place_entity
will limit the vruntime difference between min_vruntime and the
woken up task to half of sysctl_sched_latency.
The code in wakeup_preempt_entity calculates how much vruntime a
time slice for the woken up task represents, in
The code in update_cfs_group / calc_group_shares has some logic to
quickly ramp up the load when a task has just started running in a
cgroup, in order to get sane values for the cgroup se->load.weight.
This code adds a similar hack to task_se_h_weight.
However, THIS CODE IS WRONG, since it does
Remove se->depth and the code that touches it, since we no longer need
any of that.
Signed-off-by: Rik van Riel
Suggested-by: Dietmar Eggemann
---
include/linux/sched.h | 1 -
kernel/sched/fair.c | 50 ++-
2 files changed, 2 insertions(+), 49
Now that enqueue_task_fair and dequeue_task_fair no longer iterate up
the hierarchy all the time, a method to lazily propagate sum_exec_runtime
up the hierarchy is necessary.
Once a tick, propagate the newly accumulated exec_runtime up the hierarchy,
and feed it into CFS bandwidth control.
Add helper functions to make the flattened runqueue patch a little smaller.
The task_se_h_weight function is similar to task_se_h_load, but scales the
task weight by the group weight, without taking the task's duty cycle into
account.
The task_se_in_cgroup helper is functionally identical to
Make it clear that update_curr only works on tasks any more.
There is no need for task_tick_fair to call it on every sched entity up
the hierarchy, so move the call out of entity_tick.
Signed-off-by: Rik van Riel `
Signed-off-by: Rik van Riel
---
kernel/sched/fair.c | 24
The runnable_load magic is used to quickly propagate information about
runnable tasks up the hierarchy of runqueues. The runnable_load_avg is
mostly used for the load balancing code, which only examines the value at
the root cfs_rq.
Redefine the root cfs_rq runnable_load_avg to be the sum of
Remove some fields from /proc/sched_debug that are removed from
sched_entity in a subsequent patch, and add h_load, which comes in
very handy to debug CPU controller weight distribution.
Signed-off-by: Rik van Riel
Reviewed-by: Josef Bacik
---
kernel/sched/debug.c | 11 ++-
1 file
The current implementation of the CPU controller uses hierarchical
runqueues, where on wakeup a task is enqueued on its group's runqueue,
the group is enqueued on the runqueue of the group above it, etc.
This increases a fairly large amount of overhead for workloads that
do a lot of wakeups a
Flatten the hierarchical runqueues into just the per CPU rq.cfs runqueue.
Iteration of the sched_entity hierarchy is rate limited to once per jiffy
per sched_entity, which is a smaller change than it seems, because load
average adjustments were already rate limited to once per jiffy before this
On Fri, Sep 06, 2019 at 10:40:09AM -0700, Bjorn Andersson wrote:
> On Thu 05 Sep 14:00 PDT 2019, Jorge Ramirez-Ortiz wrote:
> > diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
> [..]
> > +static inline int qcom_get_enable(struct watchdog_device *wdd)
> > +{
> > + int
On Fri, Sep 06, 2019 at 12:03:34PM -0700, Dmitry Torokhov wrote:
> On Fri, Sep 06, 2019 at 10:59:48AM +0200, Benjamin Tissoires wrote:
> > Looks like the Bios of the Lenovo Legion Y7000 is using ELAN061B
> > when the actual device is supposed to be used with hid-multitouch.
> >
> > Remove it from
On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
> * Steve Grubb:
> > Now with LD_AUDIT
> > $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test
> > 2>&1 | grep passwd openat(3, "passwd", O_RDONLY) = 4
> >
> > No O_CLOEXEC flag.
>
> I think you need to
On Fri, 6 Sep 2019, Jeff Layton wrote:
> The fact that open and openat didn't vet unknown flags is really a bug.
>
> Too late to fix it now, of course, and as Aleksa points out, we've
> worked around that in the past. Now though, we have a new openat2
> syscall on the horizon. There's little
On Fri, Sep 6, 2019 at 11:21 AM James Morse wrote:
>
> Hi Pavel,
>
> On 21/08/2019 19:31, Pavel Tatashin wrote:
> > Thre is PMD_SECT_RDONLY that is used in pud_* function which is confusing.
>
> Nit: There
>
> I bet it was equally confusing before before you moved it! Could you do this
> earlier
On Fri, 6 Sep 2019 11:58:59 +0530
Anshuman Khandual wrote:
> On 09/05/2019 10:36 PM, Gerald Schaefer wrote:
> > On Thu, 5 Sep 2019 14:48:14 +0530
> > Anshuman Khandual wrote:
> >
> >>> [...]
> +
> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
>
> > -int trans_pgd_create_copy(pgd_t **dst_pgdp, unsigned long start,
> > +/*
> > + * Create trans_pgd and copy entries from from_table to trans_pgd in range
> > + * [start, end)
> > + */
> > +int trans_pgd_create_copy(struct trans_pgd_info *info, pgd_t **trans_pgd,
> > +
On Fri, Sep 06, 2019 at 10:59:48AM +0200, Benjamin Tissoires wrote:
> Looks like the Bios of the Lenovo Legion Y7000 is using ELAN061B
> when the actual device is supposed to be used with hid-multitouch.
>
> Remove it from the list of the supported device, hoping that
> no one will complain about
On Fri, Sep 06, 2019 at 11:30:57AM -0700, Sagi Grimberg wrote:
>
> >
> > Ok, so the real problem is per-cpu bounded tasks.
> >
> > I share Thomas opinion about a NAPI like approach.
>
> We already have that, its irq_poll, but it seems that for this
> use-case, we get lower performance for some
On 9/5/2019 3:01 PM, Youri Querry wrote:
> The QBMan frame descriptor enqueuing is changed from array
> mode (a single frame enqueue at a time) to bulk ring mode.
>
> This new mode allows the enqueuing of multiple frames in one operation.
> The original interface is kept but use the bulk enqueue
In ath9k_wmi_cmd, the allocated network buffer needs to be released
if timeout happens. Otherwise memory will be leaked.
Signed-off-by: Navid Emamdoost
---
drivers/net/wireless/ath/ath9k/wmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c
* Steve Grubb:
> Now with LD_AUDIT
> $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test 2>&1 |
> grep passwd
> openat(3, "passwd", O_RDONLY) = 4
>
> No O_CLOEXEC flag.
I think you need to explain in detail why you consider this a problem.
With LD_PRELOAD and
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: e16c2983fba0fa6763e43ad10916be35e3d8dc05
Gitweb:
https://git.kernel.org/tip/e16c2983fba0fa6763e43ad10916be35e3d8dc05
Author:Steve Wahl
AuthorDate:Thu, 05 Sep 2019 15:23:46 -05:00
Committer:
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: e16c2983fba0fa6763e43ad10916be35e3d8dc05
Gitweb:
https://git.kernel.org/tip/e16c2983fba0fa6763e43ad10916be35e3d8dc05
Author:Steve Wahl
AuthorDate:Thu, 05 Sep 2019 15:23:46 -05:00
Committer:
On Fri, Sep 6, 2019 at 6:59 PM Andy Shevchenko
wrote:
>
> On Fri, Sep 06, 2019 at 05:26:01PM +0200, Arnd Bergmann wrote:
> > The intel_pin_to_gpio() function is only called by the
> > PM support functions and causes a warning when those are disabled:
> >
> >
The intel_pin_to_gpio() function is only called by the
PM support functions and causes a warning when those are disabled:
drivers/pinctrl/intel/pinctrl-intel.c:841:12: error: unused function
'intel_pin_to_gpio' [-Werror,-Wunused-function]
Mark it __maybe_unused to suppress the warning.
From: Markus Elfring
Date: Fri, 6 Sep 2019 20:40:06 +0200
Simplify these function implementations by using a known function.
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Signed-off-by: Markus Elfring
---
drivers/pci/controller/dwc/pci-exynos.c | 5 +
101 - 200 of 853 matches
Mail list logo
