Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates:
Two bug fixes for 4.17
* A missing -msoft-float for the compile of the kexec purgatory
* A fix for the dasd driver to avoid
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates:
Two bug fixes for 4.17
* A missing -msoft-float for the compile of the kexec purgatory
* A fix for the dasd driver to avoid
2018-05-25 5:09 GMT+09:00 Martin Blumenstingl
:
> Hi Philipp,
>
> On Tue, May 22, 2018 at 4:04 PM, Philipp Zabel wrote:
>> Hi Martin,
>>
>> On Mon, 2018-05-21 at 12:40 +0200, Martin Blumenstingl wrote:
>>> Hello,
>>>
>>> On Mon, May 21, 2018 at 3:27 AM, Masahiro Yamada
>>> wrote:
>>> > Hi.
>>> >
2018-05-25 5:09 GMT+09:00 Martin Blumenstingl
:
> Hi Philipp,
>
> On Tue, May 22, 2018 at 4:04 PM, Philipp Zabel wrote:
>> Hi Martin,
>>
>> On Mon, 2018-05-21 at 12:40 +0200, Martin Blumenstingl wrote:
>>> Hello,
>>>
>>> On Mon, May 21, 2018 at 3:27 AM, Masahiro Yamada
>>> wrote:
>>> > Hi.
>>> >
* nixiaoming wrote:
> mark_rodata_ro is only called by the function mark_readonly
> when CONFIG_STRICT_KERNEL_RWX=y
>
> if CONFIG_STRICT_KERNEL_RWX is not set
> a compile warning may be triggered: unused function
>
> Signed-off-by: nixiaoming
> ---
> arch/x86/mm/init_32.c | 2 ++
>
* nixiaoming wrote:
> mark_rodata_ro is only called by the function mark_readonly
> when CONFIG_STRICT_KERNEL_RWX=y
>
> if CONFIG_STRICT_KERNEL_RWX is not set
> a compile warning may be triggered: unused function
>
> Signed-off-by: nixiaoming
> ---
> arch/x86/mm/init_32.c | 2 ++
>
* Paul E. McKenney wrote:
> Hello, Ingo,
>
> This additional v4.18 pull request contains a single commit that fell
> through the cracks:
>
> 1.Provide early rcu_cpu_starting() callback for the benefit of the
> x86/mtrr code, which needs RCU to be available on incoming CPUs
>
* Paul E. McKenney wrote:
> Hello, Ingo,
>
> This additional v4.18 pull request contains a single commit that fell
> through the cracks:
>
> 1.Provide early rcu_cpu_starting() callback for the benefit of the
> x86/mtrr code, which needs RCU to be available on incoming CPUs
>
On 29.5.2018 16:34, Rob Herring wrote:
> On Mon, May 28, 2018 at 5:02 AM, Greg Kroah-Hartman
> wrote:
>> 3.18-stable review patch. If anyone has any objections, please let me know.
>>
>> --
>>
>> From: Rob Herring
>>
>> [ Upstream commit 101646a24a2f9cdb61d7732459fbf068a7bbb542
On 29.5.2018 16:34, Rob Herring wrote:
> On Mon, May 28, 2018 at 5:02 AM, Greg Kroah-Hartman
> wrote:
>> 3.18-stable review patch. If anyone has any objections, please let me know.
>>
>> --
>>
>> From: Rob Herring
>>
>> [ Upstream commit 101646a24a2f9cdb61d7732459fbf068a7bbb542
On Tue, May 29, 2018 at 10:14:35PM -0700, John Stultz wrote:
> On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
> > On 2018년 05월 09일 08:17, John Stultz wrote:
> >> Hey folks,
> >> I wanted to bring up an issue we've recently tripped over, which was
> >> caused by 4585fbcb5331f ("PM /
On Tue, May 29, 2018 at 10:14:35PM -0700, John Stultz wrote:
> On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
> > On 2018년 05월 09일 08:17, John Stultz wrote:
> >> Hey folks,
> >> I wanted to bring up an issue we've recently tripped over, which was
> >> caused by 4585fbcb5331f ("PM /
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins wrote:
> + * @ever_enabled: Boolean indicating that the regulator has been
> + * explicitly enabled at least once. Voltage
> + * requests should be cached when this flag is
>
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins wrote:
> + * @ever_enabled: Boolean indicating that the regulator has been
> + * explicitly enabled at least once. Voltage
> + * requests should be cached when this flag is
>
Hi,
On Wed, May 23, 2018 at 8:56 AM, Mark Brown wrote:
> On Wed, May 23, 2018 at 08:50:22AM -0700, Doug Anderson wrote:
>> On Wed, May 23, 2018 at 8:40 AM, Mark Brown wrote:
>
>> > It's got to be valid to think about the voltage of a disabled regulator
>> > since drivers want to be able make
Hi,
On Wed, May 23, 2018 at 8:56 AM, Mark Brown wrote:
> On Wed, May 23, 2018 at 08:50:22AM -0700, Doug Anderson wrote:
>> On Wed, May 23, 2018 at 8:40 AM, Mark Brown wrote:
>
>> > It's got to be valid to think about the voltage of a disabled regulator
>> > since drivers want to be able make
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins wrote:
> +
> +Examples
> +
> +
> +#include
> +
> +_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> +
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins wrote:
> +
> +Examples
> +
> +
> +#include
> +
> +_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> +
During development, number of reserved memory region could be increased
and a new region could be unwantedly overlapped. In that case the new
region may work well but one of exisiting region could be affected so
that it would not be defined properly. It may require time consuming
work to find
During development, number of reserved memory region could be increased
and a new region could be unwantedly overlapped. In that case the new
region may work well but one of exisiting region could be affected so
that it would not be defined properly. It may require time consuming
work to find
On Mon, May 28, 2018 at 11:21:53PM -0700, Nick Desaulniers wrote:
> Fixes a stringop-truncation warning from gcc-8.
>
> Signed-off-by: Nick Desaulniers
I'll note that the ext4 superblock fields are *not* guaranteed to be
NULL terminated. Code that references them must, and do, deal with
this
On Mon, May 28, 2018 at 11:21:53PM -0700, Nick Desaulniers wrote:
> Fixes a stringop-truncation warning from gcc-8.
>
> Signed-off-by: Nick Desaulniers
I'll note that the ext4 superblock fields are *not* guaranteed to be
NULL terminated. Code that references them must, and do, deal with
this
On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
> On 2018년 05월 09일 08:17, John Stultz wrote:
>> Hey folks,
>> I wanted to bring up an issue we've recently tripped over, which was
>> caused by 4585fbcb5331f ("PM / devfreq: Modify the device name as
>> devfreq(X) for sysfs").
>>
>>
On Tue, May 8, 2018 at 7:28 PM, Chanwoo Choi wrote:
> On 2018년 05월 09일 08:17, John Stultz wrote:
>> Hey folks,
>> I wanted to bring up an issue we've recently tripped over, which was
>> caused by 4585fbcb5331f ("PM / devfreq: Modify the device name as
>> devfreq(X) for sysfs").
>>
>>
Hi,
On Tue, May 29, 2018 at 5:20 AM, Ludovic BARRE wrote:
>
>
> On 05/29/2018 10:55 AM, Alexandre Torgue wrote:
>>
>>
>>
>> On 05/29/2018 10:39 AM, Marc Zyngier wrote:
>>>
>>> On 29/05/18 09:16, Alexandre Torgue wrote:
Hi Marc
On 05/29/2018 09:47 AM, Marc Zyngier wrote:
Hi,
On Tue, May 29, 2018 at 5:20 AM, Ludovic BARRE wrote:
>
>
> On 05/29/2018 10:55 AM, Alexandre Torgue wrote:
>>
>>
>>
>> On 05/29/2018 10:39 AM, Marc Zyngier wrote:
>>>
>>> On 29/05/18 09:16, Alexandre Torgue wrote:
Hi Marc
On 05/29/2018 09:47 AM, Marc Zyngier wrote:
Hi all,
Today's linux-next merge of the regulator tree got a conflict in:
arch/arm/mach-omap1/board-ams-delta.c
between commit:
0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
from the arm-soc tree and commit:
6059577cb28d ("regulator: fixed: Convert to use GPIO
Hi all,
Today's linux-next merge of the regulator tree got a conflict in:
arch/arm/mach-omap1/board-ams-delta.c
between commit:
0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
from the arm-soc tree and commit:
6059577cb28d ("regulator: fixed: Convert to use GPIO
From: Kuang Rufan
both bind.c & binder_alloc.c define the same kernel parameter 'debug_mask',
rename the one in binder_alloc.c to 'alloc_debug_mask'.
Signed-off-by: Kuang Rufan
---
drivers/android/binder_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Kuang Rufan
both bind.c & binder_alloc.c define the same kernel parameter 'debug_mask',
rename the one in binder_alloc.c to 'alloc_debug_mask'.
Signed-off-by: Kuang Rufan
---
drivers/android/binder_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, May 29, 2018 at 04:10:24PM +, Kani, Toshi wrote:
> Can you explain why you think allocating a page here is a major problem?
Because a larger allocation is more likely to fail. And if you fail the
allocation, you also fail to free more pages, which _is_ a problem. So
better avoid any
On Tue, May 29, 2018 at 04:10:24PM +, Kani, Toshi wrote:
> Can you explain why you think allocating a page here is a major problem?
Because a larger allocation is more likely to fail. And if you fail the
allocation, you also fail to free more pages, which _is_ a problem. So
better avoid any
On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote:
> On 5/29/2018 9:31 PM, Greg Kroah-Hartman wrote:
> > On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
> >> Adding pci=safemode kernel command line parameter to turn off all PCI
> >> Express service driver as well as all
On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote:
> On 5/29/2018 9:31 PM, Greg Kroah-Hartman wrote:
> > On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
> >> Adding pci=safemode kernel command line parameter to turn off all PCI
> >> Express service driver as well as all
>
> Hi Al,
>
> FYI, the error/warning still remains.
hi AI, kindly ignore this, the warning below may be caused by gcc-8.1 upgrade.
we will double check to reduce noises.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head:
>
> Hi Al,
>
> FYI, the error/warning still remains.
hi AI, kindly ignore this, the warning below may be caused by gcc-8.1 upgrade.
we will double check to reduce noises.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head:
Hi Arnaldo,
On Wed, May 30, 2018 at 12:49:27PM +0800, Leo Yan wrote:
> Since commit 464fb4fd6af7 ("perf hists browser: Pass annotation_options
> from tool to browser") has added extra parameter for functions, but it
> missed to update hist_entry__tui_annotate() declaration for
>
Hi Arnaldo,
On Wed, May 30, 2018 at 12:49:27PM +0800, Leo Yan wrote:
> Since commit 464fb4fd6af7 ("perf hists browser: Pass annotation_options
> from tool to browser") has added extra parameter for functions, but it
> missed to update hist_entry__tui_annotate() declaration for
>
On 25-05-18, 12:19, Sebastian Andrzej Siewior wrote:
> Use the static SRCU initializer for `cpufreq_transition_notifier_list'.
> This avoids the init_cpufreq_transition_notifier_list() initcall. Its
> only purpose is to initialize the SRCU notifier once during boot and set
> another variable which
On 25-05-18, 12:19, Sebastian Andrzej Siewior wrote:
> Use the static SRCU initializer for `cpufreq_transition_notifier_list'.
> This avoids the init_cpufreq_transition_notifier_list() initcall. Its
> only purpose is to initialize the SRCU notifier once during boot and set
> another variable which
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0044cdeb731313f20b63cb5644de7588731de32b
commit: a0d32ad366bb4235267380b341fcae8307f51044 switch
sparc_remap_file_pages() to SYSCALL_DEFINE
date: 2 months
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0044cdeb731313f20b63cb5644de7588731de32b
commit: a0d32ad366bb4235267380b341fcae8307f51044 switch
sparc_remap_file_pages() to SYSCALL_DEFINE
date: 2 months
Since commit 464fb4fd6af7 ("perf hists browser: Pass annotation_options
from tool to browser") has added extra parameter for functions, but it
missed to update hist_entry__tui_annotate() declaration for
!HAVE_SLANG_SUPPORT configuration so this results in regression for perf
tool building failure.
Since commit 464fb4fd6af7 ("perf hists browser: Pass annotation_options
from tool to browser") has added extra parameter for functions, but it
missed to update hist_entry__tui_annotate() declaration for
!HAVE_SLANG_SUPPORT configuration so this results in regression for perf
tool building failure.
To protect against KSMA(Kernel Space Mirroring Attack), make
tramp_pg_dir read-only. The principle of KSMA is to insert a
carefully constructed PGD entry into the translation table.
The type of this entry is block, which maps the kernel text
and its access permissions bits are 01. The user process
To protect against KSMA(Kernel Space Mirroring Attack), make
tramp_pg_dir read-only. The principle of KSMA is to insert a
carefully constructed PGD entry into the translation table.
The type of this entry is block, which maps the kernel text
and its access permissions bits are 01. The user process
On 29-05-18, 15:18, Krzysztof Kozlowski wrote:
> Thanks for the patch.
>
> In case of Exynos, the booting CPU always has these information in DT
> and the booting CPU cannot be changed (chosen by firmware/hardware
> configuration).
But can the booting CPU be offlined ?
If yes, then this is how
On 29-05-18, 15:18, Krzysztof Kozlowski wrote:
> Thanks for the patch.
>
> In case of Exynos, the booting CPU always has these information in DT
> and the booting CPU cannot be changed (chosen by firmware/hardware
> configuration).
But can the booting CPU be offlined ?
If yes, then this is how
On 5/29/2018 9:34 PM, Sinan Kaya wrote:
> -int early_pci_allowed(void)
> -{
> - return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
> - PCI_PROBE_CONF1;
> -}
I should have kept this. I'll wait for more feedback before posting the
next rev.
--
Sinan Kaya
Qualcomm
On 5/29/2018 9:34 PM, Sinan Kaya wrote:
> -int early_pci_allowed(void)
> -{
> - return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
> - PCI_PROBE_CONF1;
> -}
I should have kept this. I'll wait for more feedback before posting the
next rev.
--
Sinan Kaya
Qualcomm
On Tue, May 29, 2018 at 09:34:35PM -0500, Eric W. Biederman wrote:
> Dave Chinner writes:
>
> > Yeah, the are some fairly big process and policy things that
> > need to be decided here. Not just at the kernel level, but at
> > distro and app infrastructure level too.
> >
> > I was originally
On Tue, May 29, 2018 at 09:34:35PM -0500, Eric W. Biederman wrote:
> Dave Chinner writes:
>
> > Yeah, the are some fairly big process and policy things that
> > need to be decided here. Not just at the kernel level, but at
> > distro and app infrastructure level too.
> >
> > I was originally
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya
---
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya
---
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Memory {increase|decrease}_reservation and VA mappings update/reset
> code used in balloon driver can be made common, so other drivers can
> also re-use the same functionality without open-coding.
> Create a
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Memory {increase|decrease}_reservation and VA mappings update/reset
> code used in balloon driver can be made common, so other drivers can
> also re-use the same functionality without open-coding.
> Create a
On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
> Adding pci=safemode kernel command line parameter to turn off all PCI
> Express service driver as well as all optional PCIe features such as LTR,
> Extended tags, Relaxed Ordering etc.
>
> Also setting MPS configuration to
On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
> Adding pci=safemode kernel command line parameter to turn off all PCI
> Express service driver as well as all optional PCIe features such as LTR,
> Extended tags, Relaxed Ordering etc.
>
> Also setting MPS configuration to
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0044cdeb731313f20b63cb5644de7588731de32b
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 2
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0044cdeb731313f20b63cb5644de7588731de32b
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 2
On Mon, May 28, 2018 at 10:40:43AM -0700, Randy Dunlap wrote:
> On 05/27/2018 06:46 PM, Tobin C. Harding wrote:
> > Currently printing [hashed] pointers requires enough entropy to be
> > available. Early in the boot sequence this may not be the case
> > resulting in a dummy string
On Mon, May 28, 2018 at 10:40:43AM -0700, Randy Dunlap wrote:
> On 05/27/2018 06:46 PM, Tobin C. Harding wrote:
> > Currently printing [hashed] pointers requires enough entropy to be
> > available. Early in the boot sequence this may not be the case
> > resulting in a dummy string
On Tue, May 29, 2018 at 01:52:12PM -0600, Shuah Khan wrote:
> On 05/28/2018 04:00 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.16.13 release.
> > There are 272 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Tue, May 29, 2018 at 01:52:12PM -0600, Shuah Khan wrote:
> On 05/28/2018 04:00 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.16.13 release.
> > There are 272 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make set/clear page private code shared and accessible to
> other kernel modules which can re-use these instead of open-coding.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c |
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make set/clear page private code shared and accessible to
> other kernel modules which can re-use these instead of open-coding.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c |
Hi Chao,
Thank you for the work.
I resolved some conflicts and modified some function names.
Please take a look at this.
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev-test
---
fs/f2fs/checkpoint.c | 8
fs/f2fs/dir.c| 6 +++---
fs/f2fs/f2fs.h
Hi Chao,
Thank you for the work.
I resolved some conflicts and modified some function names.
Please take a look at this.
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev-test
---
fs/f2fs/checkpoint.c | 8
fs/f2fs/dir.c| 6 +++---
fs/f2fs/f2fs.h
Hi Paul,
On Wed, 30 May 2018, at 00:23, Paul Menzel wrote:
> Dear Joel, dear Linux folks,
>
>
> We have an IBM S822LC system (Firestone(?)). Building of OpenBMC
> currently fails, as the not everything was ported from dev-4.10 to
> dev-4.13 [1], and therefore a file cannot be found.
>
>
Hi Paul,
On Wed, 30 May 2018, at 00:23, Paul Menzel wrote:
> Dear Joel, dear Linux folks,
>
>
> We have an IBM S822LC system (Firestone(?)). Building of OpenBMC
> currently fails, as the not everything was ported from dev-4.10 to
> dev-4.13 [1], and therefore a file cannot be found.
>
>
If it's the first request to queue, and we are using descriptor dma mode
for isoc transfer, we only need to add the request to the queue, and it
will be processed in the future nak interrupt handler.
Signed-off-by: Zeng Tao
---
drivers/usb/dwc2/gadget.c | 3 +++
1 file changed, 3 insertions(+)
If it's the first request to queue, and we are using descriptor dma mode
for isoc transfer, we only need to add the request to the queue, and it
will be processed in the future nak interrupt handler.
Signed-off-by: Zeng Tao
---
drivers/usb/dwc2/gadget.c | 3 +++
1 file changed, 3 insertions(+)
On 05/29/2018 11:44 PM, Eric Dumazet wrote:
>
> And I will add this simple fix, this really should address your initial
> concern much better.
>
> @@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem,
> int order,
> {
> struct page *page;
>
> + if
On 05/29/2018 11:44 PM, Eric Dumazet wrote:
>
> And I will add this simple fix, this really should address your initial
> concern much better.
>
> @@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem,
> int order,
> {
> struct page *page;
>
> + if
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, May 30, 2018 11:18 AM
>
> On Wed, 30 May 2018 01:41:43 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday, May 30, 2018 4:09 AM
> > >
> > > On Fri, 20
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, May 30, 2018 11:18 AM
>
> On Wed, 30 May 2018 01:41:43 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday, May 30, 2018 4:09 AM
> > >
> > > On Fri, 20
On 05/29/2018 11:34 PM, Eric Dumazet wrote:
> I will test :
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c
> b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index
> 685337d58276fc91baeeb64387c52985e1bc6dda..4d2a71381acb739585d662175e86caef72338097
> 100644
> ---
On 05/29/2018 11:34 PM, Eric Dumazet wrote:
> I will test :
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/icm.c
> b/drivers/net/ethernet/mellanox/mlx4/icm.c
> index
> 685337d58276fc91baeeb64387c52985e1bc6dda..4d2a71381acb739585d662175e86caef72338097
> 100644
> ---
On 05/29/2018 08:01 PM, Michael S. Tsirkin wrote:
On Tue, May 29, 2018 at 03:19:08PM -0700, Guenter Roeck wrote:
On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
The struct vhost_msg within struct vhost_msg_node is copied to userspace,
so it should be allocated with kzalloc() to
On 05/29/2018 08:01 PM, Michael S. Tsirkin wrote:
On Tue, May 29, 2018 at 03:19:08PM -0700, Guenter Roeck wrote:
On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
The struct vhost_msg within struct vhost_msg_node is copied to userspace,
so it should be allocated with kzalloc() to
On Tue, May 29, 2018 at 11:04 PM, Matthew Wilcox wrote:
> On Tue, May 29, 2018 at 09:25:05PM +0530, Souptick Joarder wrote:
>> On Tue, May 29, 2018 at 8:20 PM, Matthew Wilcox wrote:
>> > On Tue, May 29, 2018 at 08:01:26PM +0530, Souptick Joarder wrote:
>> >> Use new return type vm_fault_t for
On Tue, May 29, 2018 at 11:04 PM, Matthew Wilcox wrote:
> On Tue, May 29, 2018 at 09:25:05PM +0530, Souptick Joarder wrote:
>> On Tue, May 29, 2018 at 8:20 PM, Matthew Wilcox wrote:
>> > On Tue, May 29, 2018 at 08:01:26PM +0530, Souptick Joarder wrote:
>> >> Use new return type vm_fault_t for
On 05/25/2018 10:23 AM, David Miller wrote:
> From: Qing Huang
> Date: Wed, 23 May 2018 16:22:46 -0700
>
>> When a system is under memory presure (high usage with fragments),
>> the original 256KB ICM chunk allocations will likely trigger kernel
>> memory management to enter slow path doing
On 05/25/2018 10:23 AM, David Miller wrote:
> From: Qing Huang
> Date: Wed, 23 May 2018 16:22:46 -0700
>
>> When a system is under memory presure (high usage with fragments),
>> the original 256KB ICM chunk allocations will likely trigger kernel
>> memory management to enter slow path doing
Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=arm64
When reading the code, I feel it is more appropriate to add macro control here.
-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com]
Sent: Tuesday, May 29, 2018 11:45 PM
To: Nixiaoming
Cc:
Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=arm64
When reading the code, I feel it is more appropriate to add macro control here.
-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com]
Sent: Tuesday, May 29, 2018 11:45 PM
To: Nixiaoming
Cc:
Hi Himanshu
Thanks for your kindly response.
On 05/30/2018 01:44 AM, Madhani, Himanshu wrote:
> Thanks for the information. I was out for couple days. Still working through
> my emails.
>
> Without core dump shared with us, things become hard to debug. We'll take a
> look at this data.
>
>
Hi Himanshu
Thanks for your kindly response.
On 05/30/2018 01:44 AM, Madhani, Himanshu wrote:
> Thanks for the information. I was out for couple days. Still working through
> my emails.
>
> Without core dump shared with us, things become hard to debug. We'll take a
> look at this data.
>
>
On Tue, May 29, 2018 at 6:38 PM Dmitry Torokhov
wrote:
> We are switching a bunch of
> Lenovo devices with Synaptics touchpads from PS/2 emulation over to
> native RMI/SMbus.
> Given that all commits are marked for stable there is no point delaying
> them till next release.
Hmm. The elan
On Tue, May 29, 2018 at 6:38 PM Dmitry Torokhov
wrote:
> We are switching a bunch of
> Lenovo devices with Synaptics touchpads from PS/2 emulation over to
> native RMI/SMbus.
> Given that all commits are marked for stable there is no point delaying
> them till next release.
Hmm. The elan
Adding pci=safemode kernel command line parameter to turn off all PCI
Express service driver as well as all optional PCIe features such as LTR,
Extended tags, Relaxed Ordering etc.
Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
reconfigured with by the kernel in case
Adding pci=safemode kernel command line parameter to turn off all PCI
Express service driver as well as all optional PCIe features such as LTR,
Extended tags, Relaxed Ordering etc.
Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
reconfigured with by the kernel in case
A new more command has been added to the ChromeOS embedded controller
that allows to get the number of charger port count. Unlike
EC_CMD_USB_PD_PORTS, this new command also includes the dedicated
port if present.
This command will be used to expose the dedicated charger port
in the ChromeOS
ChromeOS devices can have one optional dedicated port.
The Dedicated port is unique and similar to the USB PD ports
except that it doesn't support as many properties.
The presence of a dedicated port is determined from whether the
EC's charger port count is equal to 'number of USB PD port' + 1.
A new more command has been added to the ChromeOS embedded controller
that allows to get the number of charger port count. Unlike
EC_CMD_USB_PD_PORTS, this new command also includes the dedicated
port if present.
This command will be used to expose the dedicated charger port
in the ChromeOS
ChromeOS devices can have one optional dedicated port.
The Dedicated port is unique and similar to the USB PD ports
except that it doesn't support as many properties.
The presence of a dedicated port is determined from whether the
EC's charger port count is equal to 'number of USB PD port' + 1.
On Wed, 30 May 2018 01:41:43 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, May 30, 2018 4:09 AM
> >
> > On Fri, 20 Apr 2018 16:42:51 -0700
> > Jacob Pan wrote:
> >
> > > On Fri, 20 Apr 2018 19:25:34 +0100
> > > Jean-Philippe
When a port is connected but acting as a source, its 'online' and
'status' properties are identical to a port that is not connected. This
makes it tedious for userspace to know for sure whether a port is
connected or not.
This commit adds a new property 'present' to reflect whether a port
is
On Wed, 30 May 2018 01:41:43 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, May 30, 2018 4:09 AM
> >
> > On Fri, 20 Apr 2018 16:42:51 -0700
> > Jacob Pan wrote:
> >
> > > On Fri, 20 Apr 2018 19:25:34 +0100
> > > Jean-Philippe
When a port is connected but acting as a source, its 'online' and
'status' properties are identical to a port that is not connected. This
makes it tedious for userspace to know for sure whether a port is
connected or not.
This commit adds a new property 'present' to reflect whether a port
is
1 - 100 of 1872 matches
Mail list logo
