On 08/08/19 12:31, Peter Zijlstra wrote:
> On Thu, Aug 08, 2019 at 10:46:52AM +0200, Juri Lelli wrote:
> > On 08/08/19 10:11, Dietmar Eggemann wrote:
>
> > > What about the fast path in pick_next_task()?
> > >
> > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > > index
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix()
to substitute such strncmp to make code better.
Signed-off-by: Chuhong Yuan
---
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix()
to substitute such strncmp to make code better.
Signed-off-by: Chuhong Yuan
---
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix()
to substitute such strncmp to make code better.
Signed-off-by: Chuhong Yuan
---
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix()
to substitute such strncmp to make code better.
Signed-off-by: Chuhong Yuan
---
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix()
to substitute such strncmp to make code better.
Signed-off-by: Chuhong Yuan
---
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix()
to substitute such strncmp to make code better.
Signed-off-by: Chuhong Yuan
---
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix()
to substitute such strncmp to make code better.
Signed-off-by: Chuhong Yuan
---
The commit 72921427d46b
("string.h: Add str_has_prefix() helper function")
introduced str_has_prefix() to substitute error-prone
strncmp(str, const, len).
strncmp(str, const, len) is easy to have error in len
because of counting error or sizeof(const) without - 1.
These patches replace such
On 2019-08-09, Peter Zijlstra wrote:
>> End result: a DRAM buffer can work, but is not "reliable".
>> Particularly if you turn power on and off, data retention of DRAM is
>> iffy. But it's possible, at least in theory.
>>
>> So I have a patch that implements a "stupid ring buffer" for thisa
>>
>
> BIOS has marked the 32K MCHBAR window as reserved, so when dnv_rd_reg()
> tries to ioremap() a 64KB region you get warnings like:
>
> resource sanity check: requesting [mem 0xfed1-0xfed1], which spans
> more than reserved [mem 0xfed1-0xfed17fff] caller
> dnv_rd_reg+0xc8/0x240
On Thu, Aug 08, 2019 at 08:54:17PM -0700, Isaku Yamahata wrote:
> Make PAT(Page Attribute Table) independent from
> MTRR(Memory Type Range Register).
> Some environments (mainly virtual ones) support only PAT, but not MTRR
> because PAT replaces MTRR.
> It's tricky and no gain to support both MTRR
On 08/08/2019 23:22, Arnd Bergmann wrote:
> As a preparation for future omap1 multiplatform support, stop
> using mach/hardware.h and instead include the omap1-io.h
> for low-level register access to MOD_CONF_CTRL_1.
>
> Signed-off-by: Arnd Bergmann
> ---
Do you want me to apply it through me
Hi,
Looks like commit 4a81e8f30d0b ("ASoC: soc-component: add
snd_soc_component_get/put()") causes a regression where trying
to rmmod a codec driver fails with module is in use error after
rmmod of snd-soc-audio-graph-card for example.
Any ideas what goes wrong there?
BTW, looks like the
On 30/07/2019 20:15, Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
>
> //
> @@
> expression ret;
> struct
On 08-08-19, 23:35, Doug Smythies wrote:
> O.K. While I understand the explanations, I still struggle with
> this scenario:
>
> doug@s15:~/temp$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
> 50<<< Note: 50% = 1.9 GHz in my system)
> doug@s15:~/temp$ grep .
>
This patch decrements 'next_avail_idx' count when detaching a buffer
from vq for packed ring code. Split ring code already does this in
virtqueue_detach_unused_buf_split function. This updates the
'next_avail_idx' to the previous correct index after an unused buffer
is detatched from the vq.
The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset")
deferred detaching of unused buffer to virtio device unplug time.
This causes unplug/replug of single port in virtio device with an
error "Error allocating inbufs\n". As we don't free the unused buffers
attached with the port.
This patch series fixes the issue with unplug/replug of a port in virtio
console driver which fails with an error "Error allocating inbufs\n".
Patch 1 makes use of 'virtqueue_detach_unused_buf' function to detach
the unused buffers during port hotunplug time.
Patch 2 updates the next avail index
On Thu 08-08-19 16:39:28, Andrew Morton wrote:
> On Thu, 8 Aug 2019 20:53:13 +0200 Michal Hocko wrote:
>
> > > https://lkml.org/lkml/2019/6/1/165
> > >
> > > Ironic to find that commit message in a stable backport.
> > >
> > > I'm happy to drop the Fixes tag.
> >
> > No, please do not drop
[Again, please do not top post - it makes a mess of any longer
discussion]
On Thu 08-08-19 15:15:12, Edward Chron wrote:
> In our experience far more (99.9%+) OOM events are not kernel issues,
> they're user task memory issues.
> Properly maintained Linux kernel only rarely have issues.
> So
On 2019.08.08 19:16 Viresh Kumar wrote:
> On 08-08-19, 09:25, Doug Smythies wrote:
>> On 2019.08.07 00:06 Viresh Kumar wrote:
>> Tested by: Doug Smythies
>> Thermald seems to now be working O.K. for all the governors.
>
> Thanks for testing Doug.
>
>> I do note that if one sets
>>
Hello everyone,
Friendly reminder that the TAB elections are coming soon:
The Linux Foundation Technical Advisory Board (TAB) serves as the
interface between the kernel development community and the Linux
Foundation. The TAB advises the Foundation on kernel-related matters,
helps member
On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote:
> On 8/08/19 3:42 PM, Ludovic Desroches wrote:
> > On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
> >> From: Eugen Hristev
> >>
> >> Add mmc capabilities for SDMMC0 for this board.
> >> With this enabled, eMMC
Hi Shawn/Leo,
Removing the "big-endian" property has caused problems in our UEFI firmware.
In UEFI, we use the device tree to detect and use the qspi controller and
flashes attached to it.
We don't maintain a list of platforms like linux driver.
Can you please revert the endianness change from
On Tue, Jul 30, 2019 at 11:15:03AM -0700, Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
>
> //
> @@
>
On 2019/8/9 12:00, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/lightnvm/pblk-read.c: In function 'pblk_submit_read_gc':
> drivers/lightnvm/pblk-read.c:421:18: warning: unused variable
On Thu, Aug 08, 2019 at 12:07:28PM -0700, Linus Torvalds wrote:
> End result: a DRAM buffer can work, but is not "reliable".
> Particularly if you turn power on and off, data retention of DRAM is
> iffy. But it's possible, at least in theory.
>
> So I have a patch that implements a "stupid ring
On 2019/8/9 5:00, Jeremy Linton wrote:
> Hi,
>
> First thanks for posting this!
>
> I ran this on our DAWN platform and it does what it says. Its a pretty
> reasonable start, but I get -1's in the command row rather than "dd" (or
> similar) and this also results in [unknown] for the shared
Dear Friend,
I came across your e-mail contact prior a private search whilst in
need of your partnership for investment assistance in your country. I
am opportune to use this medium to exhibit my legal intentions towards
investing to your country under your management. I am fully convinced
that
901 - 930 of 930 matches
Mail list logo
