On Fri, Jul 20, 2018 at 03:36:41PM -0700, Nick Desaulniers wrote:
> native_save_fl() is marked static inline, but by using it as
> a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.
>
> paravirt's use of native_save_fl() also requires that no GPRs other than
> %rax are
On Fri, Jul 20, 2018 at 03:36:41PM -0700, Nick Desaulniers wrote:
> native_save_fl() is marked static inline, but by using it as
> a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.
>
> paravirt's use of native_save_fl() also requires that no GPRs other than
> %rax are
On Fri, Jul 20, 2018 at 05:06:07PM -0700, Nick Desaulniers wrote:
> On Fri, Jul 20, 2018 at 5:04 PM kbuild test robot wrote:
> >
> > Hi Nick,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on tip/x86/core]
>
On Fri, Jul 20, 2018 at 05:06:07PM -0700, Nick Desaulniers wrote:
> On Fri, Jul 20, 2018 at 5:04 PM kbuild test robot wrote:
> >
> > Hi Nick,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on tip/x86/core]
>
Good morning from Singapore,
Does Linux kernel 4.18-rc5 have drivers for IEEE 802.11AC Wave 2 USB Wireless
Adapters?
I noted that Linux usually has poor support for USB Wireless AC Adapters.
Thank you.
===BEGIN SIGNATURE===
Turritopsis Dohrnii Teo En Ming's Academic Qualifications as
Good morning from Singapore,
Does Linux kernel 4.18-rc5 have drivers for IEEE 802.11AC Wave 2 USB Wireless
Adapters?
I noted that Linux usually has poor support for USB Wireless AC Adapters.
Thank you.
===BEGIN SIGNATURE===
Turritopsis Dohrnii Teo En Ming's Academic Qualifications as
Hi Daniel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[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
Hi Daniel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[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
From: Randy Dunlap
Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
printk format build warning. This is due to hexagon's ffs() being
coded as returning long instead of int.
Fix the printk format warning by changing all of hexagon's ffx() and
flx() functions to return int
From: Randy Dunlap
Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
printk format build warning. This is due to hexagon's ffs() being
coded as returning long instead of int.
Fix the printk format warning by changing all of hexagon's ffx() and
flx() functions to return int
Hi Daniel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[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
Hi Daniel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[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
From: Randy Dunlap
Fix build warning in arch/hexagon/kernel/dma.c by casting a void *
to unsigned long to match the function parameter type.
../arch/hexagon/kernel/dma.c: In function 'arch_dma_alloc':
../arch/hexagon/kernel/dma.c:51:5: warning: passing argument 2 of
'gen_pool_add' makes
From: Randy Dunlap
Fix build warning in arch/hexagon/kernel/dma.c by casting a void *
to unsigned long to match the function parameter type.
../arch/hexagon/kernel/dma.c: In function 'arch_dma_alloc':
../arch/hexagon/kernel/dma.c:51:5: warning: passing argument 2 of
'gen_pool_add' makes
On Fri, Jul 20, 2018 at 7:37 PM, Suren Baghdasaryan wrote:
> On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
> wrote:
>> The cgroup's CPU controller allows to assign a specified (maximum)
>> bandwidth to the tasks of a group. However this bandwidth is defined and
>> enforced only on a temporal
On Fri, Jul 20, 2018 at 7:37 PM, Suren Baghdasaryan wrote:
> On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
> wrote:
>> The cgroup's CPU controller allows to assign a specified (maximum)
>> bandwidth to the tasks of a group. However this bandwidth is defined and
>> enforced only on a temporal
On 7/20/2018 1:01 PM, Bjorn Helgaas wrote:
On Tue, Jul 10, 2018 at 02:30:11PM -0400, Sinan Kaya wrote:
On Mon, Jul 9, 2018 at 12:00 PM, Lukas Wunner wrote:
On Mon, Jul 09, 2018 at 08:48:44AM -0600, Sinan Kaya wrote:
On 7/8/18, Lukas Wunner wrote:
On Tue, Jul 03, 2018 at 11:43:26AM -0400,
On 7/20/2018 1:01 PM, Bjorn Helgaas wrote:
On Tue, Jul 10, 2018 at 02:30:11PM -0400, Sinan Kaya wrote:
On Mon, Jul 9, 2018 at 12:00 PM, Lukas Wunner wrote:
On Mon, Jul 09, 2018 at 08:48:44AM -0600, Sinan Kaya wrote:
On 7/8/18, Lukas Wunner wrote:
On Tue, Jul 03, 2018 at 11:43:26AM -0400,
On 2018/07/21 7:13, David Rientjes wrote:
>>> mutex_lock(_lock);
>>> __oom_reap_task_mm(mm);
>>> mutex_unlock(_lock);
>>
>> I don't like holding oom_lock for full teardown of an mm, for an OOM
>> victim's mm
>> might have multiple TB memory which could take
On 2018/07/21 7:13, David Rientjes wrote:
>>> mutex_lock(_lock);
>>> __oom_reap_task_mm(mm);
>>> mutex_unlock(_lock);
>>
>> I don't like holding oom_lock for full teardown of an mm, for an OOM
>> victim's mm
>> might have multiple TB memory which could take
Hi Krzysztof,
2018年7月20日(金) 1:01 Krzysztof Kozlowski :
>
> Hi All,
>
> Tests
> =
> This is both request for comments and requests for tests. Only basic
> tests were done, including suspend to RAM on Odroid U3 (Exynos4412)
> with max7768 RTC wakeup. Please kindly test it with devices capable
Hi Krzysztof,
2018年7月20日(金) 1:01 Krzysztof Kozlowski :
>
> Hi All,
>
> Tests
> =
> This is both request for comments and requests for tests. Only basic
> tests were done, including suspend to RAM on Odroid U3 (Exynos4412)
> with max7768 RTC wakeup. Please kindly test it with devices capable
On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
wrote:
> The cgroup's CPU controller allows to assign a specified (maximum)
> bandwidth to the tasks of a group. However this bandwidth is defined and
> enforced only on a temporal base, without considering the actual
> frequency a CPU is running
On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
wrote:
> The cgroup's CPU controller allows to assign a specified (maximum)
> bandwidth to the tasks of a group. However this bandwidth is defined and
> enforced only on a temporal base, without considering the actual
> frequency a CPU is running
for-current' of
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
e181ae0c5d mm: zero unavailable pages before memmap init
28c20cc73b Merge tag 'drm-fixes-2018-07-20' of
git://anongit.freedesktop.org/drm/drm
89cf553533 Add linux-next specifi
for-current' of
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
e181ae0c5d mm: zero unavailable pages before memmap init
28c20cc73b Merge tag 'drm-fixes-2018-07-20' of
git://anongit.freedesktop.org/drm/drm
89cf553533 Add linux-next specifi
gcc 8 reports:
In function 'fs__env_override',
inlined from 'fs__get_mountpoint' at fs/fs.c:228:6:
fs/fs.c:222:2: error: 'strncpy' specified bound 4096 equals destination size
[-Werror=stringop-truncation]
strncpy(fs->path, override_path, sizeof(fs->path));
gcc 8 reports:
In function 'fs__env_override',
inlined from 'fs__get_mountpoint' at fs/fs.c:228:6:
fs/fs.c:222:2: error: 'strncpy' specified bound 4096 equals destination size
[-Werror=stringop-truncation]
strncpy(fs->path, override_path, sizeof(fs->path));
Hi, Paul,
SFB can improve the memory bandwidth as much as 30%, and we are planning to
enable SFB by default. So, we want to control cpu_relax() under
CONFIG_CPU_LOONGSON3, not under CONFIG_LOONGSON3_ENHANCEMENT.
Huacai
-- Original --
From: "Paul Burton";
Hi, Paul,
SFB can improve the memory bandwidth as much as 30%, and we are planning to
enable SFB by default. So, we want to control cpu_relax() under
CONFIG_CPU_LOONGSON3, not under CONFIG_LOONGSON3_ENHANCEMENT.
Huacai
-- Original --
From: "Paul Burton";
Hi Aapo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[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
Hi Aapo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[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
Hi Patrick,
On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
wrote:
> When a util_max clamped task sleeps, its clamp constraints are removed
> from the CPU. However, the blocked utilization on that CPU can still be
> higher than the max clamp value enforced while that task was running.
> This
Hi Patrick,
On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
wrote:
> When a util_max clamped task sleeps, its clamp constraints are removed
> from the CPU. However, the blocked utilization on that CPU can still be
> higher than the max clamp value enforced while that task was running.
> This
Hi Daniel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on asoc/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[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
Hi Daniel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on asoc/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[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
The mm-of-the-moment snapshot 2018-07-20-17-49 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
The mm-of-the-moment snapshot 2018-07-20-17-49 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
Added support for the CPCAP power management regulator functions on
Tegra devices.
Added sw2_sw4 value tables, which provide power to the Tegra core and
aux devices.
Added the Tegra init tables and device tree compatibility match.
Signed-off-by: Peter Geis
---
Added support for the CPCAP power management regulator functions on
Tegra devices.
Added sw2_sw4 value tables, which provide power to the Tegra core and
aux devices.
Added the Tegra init tables and device tree compatibility match.
Signed-off-by: Peter Geis
---
SW2 and SW4 use a shared table to provide voltage to the cpu core and
devices on Tegra hardware.
Added this table to the cpcap regulator driver as the first step to
supporting this device on Tegra.
Signed-off-by: Peter Geis
---
drivers/regulator/cpcap-regulator.c | 23 +++
SW2 and SW4 use a shared table to provide voltage to the cpu core and
devices on Tegra hardware.
Added this table to the cpcap regulator driver as the first step to
supporting this device on Tegra.
Signed-off-by: Peter Geis
---
drivers/regulator/cpcap-regulator.c | 23 +++
Good Evening,
The CPCAP regulator driver can support various devices, but currently
only supports Omap4 devices.
Adds the sw2 and sw4 voltage tables, which power the Tegra core, and a
DT match for the Tegra device.
Tested on the Motorola Xoom MZ602.
Peter Geis (2):
Add sw2_sw4 voltage
Good Evening,
The CPCAP regulator driver can support various devices, but currently
only supports Omap4 devices.
Adds the sw2 and sw4 voltage tables, which power the Tegra core, and a
DT match for the Tegra device.
Tested on the Motorola Xoom MZ602.
Peter Geis (2):
Add sw2_sw4 voltage
Hi Patrick,
On Fri, Jul 20, 2018 at 8:11 AM, Patrick Bellasi
wrote:
> Hi Suren,
> thanks for the review, all good point... some more comments follow
> inline.
>
> On 19-Jul 16:51, Suren Baghdasaryan wrote:
>> On Mon, Jul 16, 2018 at 1:28 AM, Patrick Bellasi
>> wrote:
>
> [...]
>
>> > +/**
>> >
Hi Patrick,
On Fri, Jul 20, 2018 at 8:11 AM, Patrick Bellasi
wrote:
> Hi Suren,
> thanks for the review, all good point... some more comments follow
> inline.
>
> On 19-Jul 16:51, Suren Baghdasaryan wrote:
>> On Mon, Jul 16, 2018 at 1:28 AM, Patrick Bellasi
>> wrote:
>
> [...]
>
>> > +/**
>> >
On Fri, 20 Jul 2018, Andrew Morton wrote:
Did you try measuring it on bare hardware?
I did and wasn't expecting much difference.
For a 2-socket 40-core (ht) IvyBridge on a few workloads, unfortunately
I don't have a xen environment and the results for Xen I do have (which numbers
are in
On Fri, 20 Jul 2018, Andrew Morton wrote:
Did you try measuring it on bare hardware?
I did and wasn't expecting much difference.
For a 2-socket 40-core (ht) IvyBridge on a few workloads, unfortunately
I don't have a xen environment and the results for Xen I do have (which numbers
are in
Hi Aapo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[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
Hi Aapo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[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
Some systems do not have software controllable regulators driving the
DA7219's supplies, nor can they use device tree to create "always-on fixed
regulators" to easily pretend like they do.
On these systems the call to devm_regulator_bulk_get() just creates
a set of dummy registers. Calling
Some systems do not have software controllable regulators driving the
DA7219's supplies, nor can they use device tree to create "always-on fixed
regulators" to easily pretend like they do.
On these systems the call to devm_regulator_bulk_get() just creates
a set of dummy registers. Calling
On Fri, Jul 20, 2018 at 5:04 PM kbuild test robot wrote:
>
> Hi Nick,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on tip/x86/core]
> [cannot apply to v4.18-rc5 next-20180720]
> [if your patch is applied to the wrong git tree, please d
On Fri, Jul 20, 2018 at 5:04 PM kbuild test robot wrote:
>
> Hi Nick,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on tip/x86/core]
> [cannot apply to v4.18-rc5 next-20180720]
> [if your patch is applied to the wrong git tree, please d
Hi Nick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/x86/core]
[cannot apply to v4.18-rc5 next-20180720]
[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
Hi Nick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/x86/core]
[cannot apply to v4.18-rc5 next-20180720]
[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
On 7/20/18 2:06 PM, Kirill A. Shutemov wrote:
On Sat, Jul 21, 2018 at 02:13:50AM +0800, Yang Shi wrote:
By digging into the original review, it looks use_zero_page sysfs knob
was added to help ease-of-testing and give user a way to mitigate
refcounting overhead.
It has been a few years
On 7/20/18 2:06 PM, Kirill A. Shutemov wrote:
On Sat, Jul 21, 2018 at 02:13:50AM +0800, Yang Shi wrote:
By digging into the original review, it looks use_zero_page sysfs knob
was added to help ease-of-testing and give user a way to mitigate
refcounting overhead.
It has been a few years
On 7/20/18 2:05 PM, David Rientjes wrote:
On Fri, 20 Jul 2018, Yang Shi wrote:
We disable the huge zero page through this interface, there were issues
related to the huge zero page shrinker (probably best to never free a
per-node huge zero page after allocated) and CVE-2017-1000405 for huge
On 7/20/18 2:05 PM, David Rientjes wrote:
On Fri, 20 Jul 2018, Yang Shi wrote:
We disable the huge zero page through this interface, there were issues
related to the huge zero page shrinker (probably best to never free a
per-node huge zero page after allocated) and CVE-2017-1000405 for huge
Oleg Nesterov writes:
> On 07/17, Oleg Nesterov wrote:
>>
>> And, I didn't mention this yesterday, but probably the next 08/11 patch can
>> have the same problem. But this is a bit more complicated because
>> send_sigio()
>> uses the same "type" both for do_each_pid_task() and as an argument
Oleg Nesterov writes:
> On 07/17, Oleg Nesterov wrote:
>>
>> And, I didn't mention this yesterday, but probably the next 08/11 patch can
>> have the same problem. But this is a bit more complicated because
>> send_sigio()
>> uses the same "type" both for do_each_pid_task() and as an argument
Hi Girish,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on spi/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[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
Hi Girish,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on spi/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[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
Hi Daniel,
On Tue, Jul 17, 2018 at 6:30 AM Daniel Drake wrote:
>
> On Mon, Jul 16, 2018 at 7:57 PM, Daniel Kurtz wrote:
> > Commit 6afb10267c1692 ("pinctrl/amd: fix masking of GPIO interrupts")
> > changed to the clearing of interrupt status bits to a RMW in a critical
> > section. This works,
Hi Daniel,
On Tue, Jul 17, 2018 at 6:30 AM Daniel Drake wrote:
>
> On Mon, Jul 16, 2018 at 7:57 PM, Daniel Kurtz wrote:
> > Commit 6afb10267c1692 ("pinctrl/amd: fix masking of GPIO interrupts")
> > changed to the clearing of interrupt status bits to a RMW in a critical
> > section. This works,
Hi,
On Fri, Jul 20, 2018 at 3:53 PM, Doug Anderson wrote:
>> + mas->oversampling = 1;
>> + /* Transmit an entire FIFO worth of data per IRQ */
>> + mas->tx_wm = 1;
>> + geni_se_get_wrapper_version(se, major, minor, step);
>
> In v1 Stephen
Hi,
On Fri, Jul 20, 2018 at 3:53 PM, Doug Anderson wrote:
>> + mas->oversampling = 1;
>> + /* Transmit an entire FIFO worth of data per IRQ */
>> + mas->tx_wm = 1;
>> + geni_se_get_wrapper_version(se, major, minor, step);
>
> In v1 Stephen
On Fri, Jul 20, 2018 at 11:05:52PM +, David Chen wrote:
> Hi Paul,
>
> We hit an RCU issue on 4.9.37 kernel. One of the nocb_follower list grows too
> large, and not getting reclaimed, causing the system to OOM.
>
> Printing the culprit rcu_sched_data:
>
> nocb_q_count = {
> counter =
On Fri, Jul 20, 2018 at 11:05:52PM +, David Chen wrote:
> Hi Paul,
>
> We hit an RCU issue on 4.9.37 kernel. One of the nocb_follower list grows too
> large, and not getting reclaimed, causing the system to OOM.
>
> Printing the culprit rcu_sched_data:
>
> nocb_q_count = {
> counter =
Linus Torvalds writes:
> On Mon, Jul 16, 2018 at 7:50 AM Eric W. Biederman
> wrote:
>>
>> In practice since glibc does not make thread id's available I don't
>> expect anyone relies on this behavior. Since no one relies on it we
>> can change it without creating a regression.
>
> Actually,
Linus Torvalds writes:
> On Mon, Jul 16, 2018 at 7:50 AM Eric W. Biederman
> wrote:
>>
>> In practice since glibc does not make thread id's available I don't
>> expect anyone relies on this behavior. Since no one relies on it we
>> can change it without creating a regression.
>
> Actually,
Hi Paul,
We hit an RCU issue on 4.9.37 kernel. One of the nocb_follower list grows too
large, and not getting reclaimed, causing the system to OOM.
Printing the culprit rcu_sched_data:
nocb_q_count = {
counter = 32369635
},
nocb_follower_head = 0x88ae901c0a00,
nocb_follower_tail
Hi Paul,
We hit an RCU issue on 4.9.37 kernel. One of the nocb_follower list grows too
large, and not getting reclaimed, causing the system to OOM.
Printing the culprit rcu_sched_data:
nocb_q_count = {
counter = 32369635
},
nocb_follower_head = 0x88ae901c0a00,
nocb_follower_tail
On Thu, 19 Jul 2018 10:58:12 +0200 Jan Kara wrote:
> On Thu 19-07-18 16:17:26, Chengguang Xu wrote:
> > When we try to truncate read count in generic_file_buffered_read(),
> > should deliver (sb->s_maxbytes - offset) as maximum count not
> > sb->s_maxbytes itself.
> >
> > Signed-off-by:
On Thu, 19 Jul 2018 10:58:12 +0200 Jan Kara wrote:
> On Thu 19-07-18 16:17:26, Chengguang Xu wrote:
> > When we try to truncate read count in generic_file_buffered_read(),
> > should deliver (sb->s_maxbytes - offset) as maximum count not
> > sb->s_maxbytes itself.
> >
> > Signed-off-by:
>Hi,
On Fri, Jul 20, 2018 at 4:50 AM, Dilip Kota wrote:
> From: Girish Mahadevan
>
> This driver supports GENI based SPI Controller in the Qualcomm SOCs. The
> Qualcomm Generic Interface (GENI) is a programmable module supporting a
> wide range of serial interfaces including SPI. This driver
>Hi,
On Fri, Jul 20, 2018 at 4:50 AM, Dilip Kota wrote:
> From: Girish Mahadevan
>
> This driver supports GENI based SPI Controller in the Qualcomm SOCs. The
> Qualcomm Generic Interface (GENI) is a programmable module supporting a
> wide range of serial interfaces including SPI. This driver
Hi Girish,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on spi/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[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
Hi Girish,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on spi/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[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
Hi Serge,
On Fri, Jul 20, 2018 at 11:14:27PM +0300, Serge Semin wrote:
> This macro substitution is the shortcut to map cacheable IO memory
> with coherent and write-back attributes. Since it is entirely unused
> by kernel, lets just remove it.
>
> Signed-off-by: Serge Semin
> Suggested-by:
Hi Serge,
On Fri, Jul 20, 2018 at 11:14:27PM +0300, Serge Semin wrote:
> This macro substitution is the shortcut to map cacheable IO memory
> with coherent and write-back attributes. Since it is entirely unused
> by kernel, lets just remove it.
>
> Signed-off-by: Serge Semin
> Suggested-by:
> [Ludovic Desroches]
> Changes in v3:
> - rebase (cherry-pick was enough)
Thanks for the rebase. I wonder, though, I recall to had more
complicated issues. However...
> - fix checkpatch errors
> - tests:
>- hangs with a SAMA5D4 (master and slave on different busses) after about
>100
> [Ludovic Desroches]
> Changes in v3:
> - rebase (cherry-pick was enough)
Thanks for the rebase. I wonder, though, I recall to had more
complicated issues. However...
> - fix checkpatch errors
> - tests:
>- hangs with a SAMA5D4 (master and slave on different busses) after about
>100
native_save_fl() is marked static inline, but by using it as
a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.
paravirt's use of native_save_fl() also requires that no GPRs other than
%rax are clobbered.
Compilers have different heuristics which they use to emit stack guard
native_save_fl() is marked static inline, but by using it as
a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.
paravirt's use of native_save_fl() also requires that no GPRs other than
%rax are clobbered.
Compilers have different heuristics which they use to emit stack guard
On Mon, Jul 02, 2018 at 02:40:11PM -0700, Jae Hyun Yoo wrote:
> This patch adjusts spinlock scope to make it wrap the whole irq
> handler using a single lock/unlock which covers both master and
> slave handlers.
>
> Signed-off-by: Jae Hyun Yoo
Applied to for-next, thanks!
Not related to these
On Mon, Jul 02, 2018 at 02:40:11PM -0700, Jae Hyun Yoo wrote:
> This patch adjusts spinlock scope to make it wrap the whole irq
> handler using a single lock/unlock which covers both master and
> slave handlers.
>
> Signed-off-by: Jae Hyun Yoo
Applied to for-next, thanks!
Not related to these
Hi,
This device presents itself as an USB CD Drive, and extends that
"metaphor" (kinda) to how it transfers data (= ethernet frames in our
case) between hosts. That is one SCSI vendor command (0xD8) over
bulk-only mass-storage is used to poll whether data is available and
another one (0xD9) is
Hi,
This device presents itself as an USB CD Drive, and extends that
"metaphor" (kinda) to how it transfers data (= ethernet frames in our
case) between hosts. That is one SCSI vendor command (0xD8) over
bulk-only mass-storage is used to poll whether data is available and
another one (0xD9) is
Sorry for the delay. Expect another large delay if you have any questions.
I'm pretty heavily context switching.
I wanted to double check to make sure that I wasn't mis-documenting and
mis-remembering things.
On 07/13/2018 07:40 PM, Brown, Len wrote:
> We disabled CPUID-based TSC calibration
Sorry for the delay. Expect another large delay if you have any questions.
I'm pretty heavily context switching.
I wanted to double check to make sure that I wasn't mis-documenting and
mis-remembering things.
On 07/13/2018 07:40 PM, Brown, Len wrote:
> We disabled CPUID-based TSC calibration
On Mon, Jul 02, 2018 at 02:13:59PM -0700, Jae Hyun Yoo wrote:
> There are some log printing without a newline character. This
> patch adds the missing newline characters.
>
> Signed-off-by: Jae Hyun Yoo
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Mon, Jul 02, 2018 at 02:13:59PM -0700, Jae Hyun Yoo wrote:
> There are some log printing without a newline character. This
> patch adds the missing newline characters.
>
> Signed-off-by: Jae Hyun Yoo
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Mon, Jul 02, 2018 at 02:20:28PM -0700, Jae Hyun Yoo wrote:
> This patch changes the order of enum aspeed_i2c_master_state and
> enum aspeed_i2c_slave_state defines to make their initial value to
> ASPEED_I2C_MASTER_INACTIVE and ASPEED_I2C_SLAVE_STOP respectively.
> In case of multi-master use,
On Mon, Jul 02, 2018 at 02:20:28PM -0700, Jae Hyun Yoo wrote:
> This patch changes the order of enum aspeed_i2c_master_state and
> enum aspeed_i2c_slave_state defines to make their initial value to
> ASPEED_I2C_MASTER_INACTIVE and ASPEED_I2C_SLAVE_STOP respectively.
> In case of multi-master use,
> On Jul 20, 2018, at 11:37 AM, Joerg Roedel wrote:
>
>> On Fri, Jul 20, 2018 at 12:32:10PM -0700, Andy Lutomirski wrote:
>> I'm just reading your changelog, and you said the PMDs are no longer
>> shared between the page tables. So this presumably means that
>> vmalloc_fault() no longer
> On Jul 20, 2018, at 11:37 AM, Joerg Roedel wrote:
>
>> On Fri, Jul 20, 2018 at 12:32:10PM -0700, Andy Lutomirski wrote:
>> I'm just reading your changelog, and you said the PMDs are no longer
>> shared between the page tables. So this presumably means that
>> vmalloc_fault() no longer
On Sat, 21 Jul 2018, Tetsuo Handa wrote:
> Why [PATCH 2/2] in https://marc.info/?l=linux-mm=153119509215026=4 does
> not
> solve your problem?
>
Such an invasive patch, and completely rewrites the oom reaper. I now
fully understand your frustration with the cgroup aware oom killer being
On Sat, 21 Jul 2018, Tetsuo Handa wrote:
> Why [PATCH 2/2] in https://marc.info/?l=linux-mm=153119509215026=4 does
> not
> solve your problem?
>
Such an invasive patch, and completely rewrites the oom reaper. I now
fully understand your frustration with the cgroup aware oom killer being
1 - 100 of 1786 matches
Mail list logo
