Re: [RESEND RFC] translate_pid API

On Tue, Mar 13, 2018 at 2:20 PM, Nagarathnam Muthusamy wrote: > On 03/13/2018 01:47 PM, Jann Horn wrote: >> On Mon, Mar 12, 2018 at 10:18 AM, >> wrote: >>> >>> Resending the RFC with participants of previous discussions >>> in the list. >>> >>> Following patch which is a variation of a solution

[pci PATCH v6 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources

From: Alexander Duyck This patch adds a common configuration function called pci_sriov_configure_simple that will allow for managing VFs on devices where the PF is not capable of managing VF resources. Signed-off-by: Alexander Duyck --- v5: New patch replacing pci_sriov_configure_unmanaged

Re: [PATCH v2] mm: make start_isolate_page_range() fail if already isolated

On 03/13/2018 02:14 PM, Andrew Morton wrote: > On Fri, 9 Mar 2018 14:47:31 -0800 Mike Kravetz > wrote: > >> start_isolate_page_range() is used to set the migrate type of a >> set of pageblocks to MIGRATE_ISOLATE while attempting to start >> a migration operation. It

Re: [PATCH v2] mm: make start_isolate_page_range() fail if already isolated

On 03/13/2018 02:14 PM, Andrew Morton wrote: > On Fri, 9 Mar 2018 14:47:31 -0800 Mike Kravetz > wrote: > >> start_isolate_page_range() is used to set the migrate type of a >> set of pageblocks to MIGRATE_ISOLATE while attempting to start >> a migration operation. It assumes that only one

[pci PATCH v6 0/5] Add support for unmanaged SR-IOV

This series is meant to add support for SR-IOV on devices when the VFs are not managed by the kernel. Examples of recent patches attempting to do this include: virto - https://patchwork.kernel.org/patch/10241225/ pci-stub - https://patchwork.kernel.org/patch/10109935/ vfio -

[pci PATCH v6 0/5] Add support for unmanaged SR-IOV

This series is meant to add support for SR-IOV on devices when the VFs are not managed by the kernel. Examples of recent patches attempting to do this include: virto - https://patchwork.kernel.org/patch/10241225/ pci-stub - https://patchwork.kernel.org/patch/10109935/ vfio -

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

Hello! You may be interested in my recent patchset [1], which has known issues but addresses the same problems yours does. It differs in the approach taken here in that, rather than supporting GOT/PLT handling which we can't really take advantage of anyway, we simply build non-PIC modules instead

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

Hello! You may be interested in my recent patchset [1], which has known issues but addresses the same problems yours does. It differs in the approach taken here in that, rather than supporting GOT/PLT handling which we can't really take advantage of anyway, we simply build non-PIC modules instead

Re: [RESEND RFC] translate_pid API

On 03/13/2018 01:47 PM, Jann Horn wrote: On Mon, Mar 12, 2018 at 10:18 AM, wrote: Resending the RFC with participants of previous discussions in the list. Following patch which is a variation of a solution discussed in https://lwn.net/Articles/736330/

Re: [RESEND RFC] translate_pid API

On 03/13/2018 01:47 PM, Jann Horn wrote: On Mon, Mar 12, 2018 at 10:18 AM, wrote: Resending the RFC with participants of previous discussions in the list. Following patch which is a variation of a solution discussed in https://lwn.net/Articles/736330/ provides the users of pid namespace,

Re: [v5 1/2] mm: disable interrupts while initializing deferred pages

On Tue, 13 Mar 2018 16:43:47 -0400 Pavel Tatashin wrote: > > > Soft lockup: kernel has run for too long without rescheduling > > Hard lockup: kernel has run for too long with interrupts disabled > > > > Both of these are detected by the NMI watchdog handler. > > >

Re: [v5 1/2] mm: disable interrupts while initializing deferred pages

On Tue, 13 Mar 2018 16:43:47 -0400 Pavel Tatashin wrote: > > > Soft lockup: kernel has run for too long without rescheduling > > Hard lockup: kernel has run for too long with interrupts disabled > > > > Both of these are detected by the NMI watchdog handler. > > > > 9b6e63cbf85b89b2d fixes a

Re: [PATCH v2] staging: bcm2835-audio: Release resources on module_exit()

On Tue, Mar 13, 2018 at 9:34 PM, Kirill Marinushkin wrote: > In the current implementation, `rmmod snd_bcm2835` does not release > resources properly. It causes an oops when trying to list sound devices. > > This commit fixes it. Nice catch! See my comments below. >

Re: [PATCH v2] staging: bcm2835-audio: Release resources on module_exit()

On Tue, Mar 13, 2018 at 9:34 PM, Kirill Marinushkin wrote: > In the current implementation, `rmmod snd_bcm2835` does not release > resources properly. It causes an oops when trying to list sound devices. > > This commit fixes it. Nice catch! See my comments below. > static void

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 3/13/2018 4:46 PM, Logan Gunthorpe wrote: > > > On 13/03/18 01:53 PM, Sinan Kaya wrote: >> I agree disabling globally would be bad. Somebody can always say I have >> ten switches on my system. I want to do peer-to-peer on one switch only. Now, >> this change weakened security for the other

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 3/13/2018 4:46 PM, Logan Gunthorpe wrote: > > > On 13/03/18 01:53 PM, Sinan Kaya wrote: >> I agree disabling globally would be bad. Somebody can always say I have >> ten switches on my system. I want to do peer-to-peer on one switch only. Now, >> this change weakened security for the other

Re: perf-core build fails on powerpc

John Garry [john.ga...@huawei.com] wrote: > On 13/03/2018 20:10, Sukadev Bhattiprolu wrote: > > > Hi John, > > > > I have an xfs file system which seems to have d_type == DT_UNKNOWN for all > > entries in 'tools/perf/pmu-events/arch/power8'! readdir(3) says ->d_type > > may not be supported by

Re: perf-core build fails on powerpc

John Garry [john.ga...@huawei.com] wrote: > On 13/03/2018 20:10, Sukadev Bhattiprolu wrote: > > > Hi John, > > > > I have an xfs file system which seems to have d_type == DT_UNKNOWN for all > > entries in 'tools/perf/pmu-events/arch/power8'! readdir(3) says ->d_type > > may not be supported by

Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working

On Tue, Mar 13, 2018 at 03:09:00PM -0600, Christ, Austin wrote: > I've tested this v2 series on Centriq 2400. Looks good to me. > > Reviewed-by: Austin Christ I am a little confused. Do you mean Tested-by or Reviewed-by? signature.asc Description: PGP signature

Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working

On Tue, Mar 13, 2018 at 03:09:00PM -0600, Christ, Austin wrote: > I've tested this v2 series on Centriq 2400. Looks good to me. > > Reviewed-by: Austin Christ I am a little confused. Do you mean Tested-by or Reviewed-by? signature.asc Description: PGP signature

Re: [PATCH] x86: always use SYSCALL_DEFINE*

On Sat, Mar 10, 2018 at 12:55 PM, Tautschnig, Michael wrote: > All syscall arguments are passed in as types of the same byte size as > unsigned long (width of full registers). Using a smaller type without a > cast may result in losing bits of information. SYSCALL_DEFINE*

Re: [PATCH] x86: always use SYSCALL_DEFINE*

On Sat, Mar 10, 2018 at 12:55 PM, Tautschnig, Michael wrote: > All syscall arguments are passed in as types of the same byte size as > unsigned long (width of full registers). Using a smaller type without a > cast may result in losing bits of information. SYSCALL_DEFINE* introduce > adequate type

Re: [PATCH v2] mm: make start_isolate_page_range() fail if already isolated

On Fri, 9 Mar 2018 14:47:31 -0800 Mike Kravetz wrote: > start_isolate_page_range() is used to set the migrate type of a > set of pageblocks to MIGRATE_ISOLATE while attempting to start > a migration operation. It assumes that only one thread is > calling it for the

Re: [PATCH v2] mm: make start_isolate_page_range() fail if already isolated

On Fri, 9 Mar 2018 14:47:31 -0800 Mike Kravetz wrote: > start_isolate_page_range() is used to set the migrate type of a > set of pageblocks to MIGRATE_ISOLATE while attempting to start > a migration operation. It assumes that only one thread is > calling it for the specified range. This

Re: [PATCH v2 1/2] hwmon: (ucd9000) Add gpio chip interface

On Tue, Mar 13, 2018 at 10:59 PM, Eddie James wrote: > From: Christopher Bostic > > Add a struct gpio_chip and define some methods so that this device's > I/O can be accessed via /sys/class/gpio. > + /* > +* Note: > +

Re: [PATCH v2 1/2] hwmon: (ucd9000) Add gpio chip interface

On Tue, Mar 13, 2018 at 10:59 PM, Eddie James wrote: > From: Christopher Bostic > > Add a struct gpio_chip and define some methods so that this device's > I/O can be accessed via /sys/class/gpio. > + /* > +* Note: > +* > +* Pinmux support has not been added to the

[PATCH] btree: avoid variable-length allocations

I agree that the code is garbage. In my defense, creating generic iterator-type functions for multiple data types appears to be one of the hardest problems in CS with many bad examples of what not to do. Patch below should fix it. We have tcm_qla2xxx systems, so I will stick it into our test

[PATCH] btree: avoid variable-length allocations

I agree that the code is garbage. In my defense, creating generic iterator-type functions for multiple data types appears to be one of the hardest problems in CS with many bad examples of what not to do. Patch below should fix it. We have tcm_qla2xxx systems, so I will stick it into our test

Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working

I've tested this v2 series on Centriq 2400. Looks good to me. Reviewed-by: Austin Christ On 3/12/2018 7:14 AM, Abhishek Sahu wrote: * v2: 1. Address review comments in v1 2. Changed the license to SPDX 3. Changed commit messages for some of the patch having more

Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working

I've tested this v2 series on Centriq 2400. Looks good to me. Reviewed-by: Austin Christ On 3/12/2018 7:14 AM, Abhishek Sahu wrote: * v2: 1. Address review comments in v1 2. Changed the license to SPDX 3. Changed commit messages for some of the patch having more detail 4. Removed event-based

[PATCH] [v3] xen: remove pre-xen3 fallback handlers

The legacy hypercall handlers were originally added with a comment explaining that "copying the argument structures in HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local variable is sufficiently safe" and only made sure to not write past the end of the argument structure, the

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

Hi Al, 1 minor issue on the new shrink_lock_dentry()... > From 121a8e0834862d2c5d88c95f8e6bc8984f195abf Mon Sep 17 00:00:00 2001 > From: Al Viro > Date: Fri, 23 Feb 2018 21:54:18 -0500 > Subject: [PATCH] get rid of trylock loop in locking dentries on shrink > list > >

[PATCH] [v3] xen: remove pre-xen3 fallback handlers

The legacy hypercall handlers were originally added with a comment explaining that "copying the argument structures in HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local variable is sufficiently safe" and only made sure to not write past the end of the argument structure, the

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

Hi Al, 1 minor issue on the new shrink_lock_dentry()... > From 121a8e0834862d2c5d88c95f8e6bc8984f195abf Mon Sep 17 00:00:00 2001 > From: Al Viro > Date: Fri, 23 Feb 2018 21:54:18 -0500 > Subject: [PATCH] get rid of trylock loop in locking dentries on shrink > list > > In case of trylock

[PATCH v3 9/9] x86/microcode/AMD: be more tolerant of late parse failures in late loader

The early loader just ends its microcode container file processing when it is unable to parse some patch section, but keeps the already read patches from this file for their eventual application. We can do the same in the late loader - we'll just return an error if we are unable to parse any

Re: [PATCH v4 4/6] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

On 03/13/2018 04:29 PM, Eric W. Biederman wrote: > Waiman Long writes: > >> On 03/13/2018 02:17 PM, Eric W. Biederman wrote: >>> Waiman Long writes: >>> A user can write arbitrary integer values to msgmni and shmmni sysctl parameters without

[PATCH v3 9/9] x86/microcode/AMD: be more tolerant of late parse failures in late loader

The early loader just ends its microcode container file processing when it is unable to parse some patch section, but keeps the already read patches from this file for their eventual application. We can do the same in the late loader - we'll just return an error if we are unable to parse any

Re: [PATCH v4 4/6] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

On 03/13/2018 04:29 PM, Eric W. Biederman wrote: > Waiman Long writes: > >> On 03/13/2018 02:17 PM, Eric W. Biederman wrote: >>> Waiman Long writes: >>> A user can write arbitrary integer values to msgmni and shmmni sysctl parameters without getting error, but the actual limit is

[PATCH v3 8/9] x86/microcode/AMD: check the equivalence table size when scanning it

Currently, the code scanning the CPU equivalence table read from a microcode container file assumes that it actually contains a terminating zero entry. Let's check also the size of this table to make sure that we don't read past it in case it actually doesn't. Signed-off-by: Maciej S. Szmigiero

[PATCH v3 8/9] x86/microcode/AMD: check the equivalence table size when scanning it

Currently, the code scanning the CPU equivalence table read from a microcode container file assumes that it actually contains a terminating zero entry. Let's check also the size of this table to make sure that we don't read past it in case it actually doesn't. Signed-off-by: Maciej S. Szmigiero

[PATCH v3 7/9] x86/microcode/AMD: check microcode container file size before accessing it

The early loader parse_container() function should check whether the microcode container file is actually large enough to contain the patch of an indicated size, just like the late loader does. Also, the request_microcode_amd() function should check whether the container file is actually large

[PATCH v3 7/9] x86/microcode/AMD: check microcode container file size before accessing it

The early loader parse_container() function should check whether the microcode container file is actually large enough to contain the patch of an indicated size, just like the late loader does. Also, the request_microcode_amd() function should check whether the container file is actually large

[PATCH v3 1/9] x86/microcode/AMD: subtract SECTION_HDR_SIZE from file leftover length

verify_patch_size() function verifies whether the microcode container file remaining size is large enough to contain a patch of the indicated size. However, the section header length is not included in this indicated size but it is present in the leftover file length so it should be subtracted

[PATCH v3 1/9] x86/microcode/AMD: subtract SECTION_HDR_SIZE from file leftover length

verify_patch_size() function verifies whether the microcode container file remaining size is large enough to contain a patch of the indicated size. However, the section header length is not included in this indicated size but it is present in the leftover file length so it should be subtracted

[PATCH v3 3/9] x86/microcode/AMD: install_equiv_cpu_table() should not return (signed) int

The maximum possible value returned by install_equiv_cpu_table() is UINT_MAX + CONTAINER_HDR_SZ (on a 64-bit kernel). This is more than (signed) int type currently returned by this function can hold so this function will need to return a size_t instead. The individual (negative) error codes

[PATCH v3 3/9] x86/microcode/AMD: install_equiv_cpu_table() should not return (signed) int

The maximum possible value returned by install_equiv_cpu_table() is UINT_MAX + CONTAINER_HDR_SZ (on a 64-bit kernel). This is more than (signed) int type currently returned by this function can hold so this function will need to return a size_t instead. The individual (negative) error codes

[PATCH v3 4/9] x86/microcode/AMD: automatically compute the PATCH_MAX_SIZE macro

The PATCH_MAX_SIZE macro should contain the maximum of all family patch sizes, computed automatically so that future changes there don't cause an inconsistency. Unfortunately, we can't use a standard max{,3} macros for this since they only work inside a function (they use a compound statement as

[PATCH v3 5/9] x86/microcode/AMD: check patch size in verify_and_add_patch()

Now that we have the PATCH_MAX_SIZE macro correctly computed we can verify properly the indicated size of a patch in a microcode container file and whether this file is actually large enough to contain it in the late loader verify_and_add_patch() function. The early loader already does the

[PATCH v3 2/9] x86/microcode/AMD: check whether the equivalence table fits in the file

Before loading a CPU equivalence table from a microcode container file we need to verify whether this file is actually large enough to contain the table of a size indicated in this file. If it is not, there is no point of continuing with loading it since microcode patches are located after the

[PATCH v3 6/9] x86/microcode/AMD: verify patch section type for every such section

We should check whether the patch section currently being processed is actually a patch section for each of them (not just the first one) in the late loader verify_and_add_patch() function, just like the early loader already does in parse_container() function. Signed-off-by: Maciej S. Szmigiero

[PATCH v3 4/9] x86/microcode/AMD: automatically compute the PATCH_MAX_SIZE macro

The PATCH_MAX_SIZE macro should contain the maximum of all family patch sizes, computed automatically so that future changes there don't cause an inconsistency. Unfortunately, we can't use a standard max{,3} macros for this since they only work inside a function (they use a compound statement as

[PATCH v3 5/9] x86/microcode/AMD: check patch size in verify_and_add_patch()

Now that we have the PATCH_MAX_SIZE macro correctly computed we can verify properly the indicated size of a patch in a microcode container file and whether this file is actually large enough to contain it in the late loader verify_and_add_patch() function. The early loader already does the

[PATCH v3 2/9] x86/microcode/AMD: check whether the equivalence table fits in the file

Before loading a CPU equivalence table from a microcode container file we need to verify whether this file is actually large enough to contain the table of a size indicated in this file. If it is not, there is no point of continuing with loading it since microcode patches are located after the

[PATCH v3 6/9] x86/microcode/AMD: verify patch section type for every such section

We should check whether the patch section currently being processed is actually a patch section for each of them (not just the first one) in the late loader verify_and_add_patch() function, just like the early loader already does in parse_container() function. Signed-off-by: Maciej S. Szmigiero

[PATCH v3 0/9] x86/microcode/AMD: check microcode file sanity before loading it

Currently, it is very easy to make the AMD microcode update driver crash or spin on a malformed microcode container file since it does very little consistency checking on data loaded from such file. This series introduces various checks, mostly on length-type fields, so all corrupted microcode

[PATCH v3 0/9] x86/microcode/AMD: check microcode file sanity before loading it

Currently, it is very easy to make the AMD microcode update driver crash or spin on a malformed microcode container file since it does very little consistency checking on data loaded from such file. This series introduces various checks, mostly on length-type fields, so all corrupted microcode

Re: [PATCH v3 00/10] splash screen on the stm32f769 disco board

On Tue, Mar 13, 2018 at 1:50 PM, Anatolij Gustschin wrote: > On Tue, 13 Mar 2018 16:23:10 +0100 > Daniel Vetter dan...@ffwll.ch wrote: > ... >> Shouldn't we patch the drivers/gpu/drm/stm driver instead of the >> drivers/video one? fbdev is kinda a dead end and not for adding new hw

Re: [PATCH v3 00/10] splash screen on the stm32f769 disco board

On Tue, Mar 13, 2018 at 1:50 PM, Anatolij Gustschin wrote: > On Tue, 13 Mar 2018 16:23:10 +0100 > Daniel Vetter dan...@ffwll.ch wrote: > ... >> Shouldn't we patch the drivers/gpu/drm/stm driver instead of the >> drivers/video one? fbdev is kinda a dead end and not for adding new hw >> support ...

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote: > On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds > wrote: > > On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton > > wrote: > >> > >> Replacing the

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Mon, 12 Mar 2018 21:28:57 -0700 Kees Cook wrote: > On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds > wrote: > > On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton > > wrote: > >> > >> Replacing the __builtin_choose_expr() with ?: works of course. > > > > Hmm. That sounds like the right thing to

Re: [PATCH] clang-format: add configuration file

On Tue, 13 Mar 2018 00:39:52 +0100 Miguel Ojeda wrote: > --- a/Documentation/process/4.Coding.rst > +++ b/Documentation/process/4.Coding.rst > @@ -58,6 +58,12 @@ can never be transgressed. If there is a good reason to > go against the > style (a line which

Re: [PATCH] clang-format: add configuration file

On Tue, 13 Mar 2018 00:39:52 +0100 Miguel Ojeda wrote: > --- a/Documentation/process/4.Coding.rst > +++ b/Documentation/process/4.Coding.rst > @@ -58,6 +58,12 @@ can never be transgressed. If there is a good reason to > go against the > style (a line which becomes far less readable if split

[PATCH] staging: vme: vme_user: Fix some error handling paths in 'vme_user_probe()'

2 gotos in error handling paths branch to the wrong label. Fix it. Signed-off-by: Christophe JAILLET --- drivers/staging/vme/devices/vme_user.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vme/devices/vme_user.c

[PATCH] staging: vme: vme_user: Fix some error handling paths in 'vme_user_probe()'

2 gotos in error handling paths branch to the wrong label. Fix it. Signed-off-by: Christophe JAILLET --- drivers/staging/vme/devices/vme_user.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vme/devices/vme_user.c

Re: [RESEND] rsi: Remove stack VLA usage

On Tue, Mar 13, 2018 at 10:17 PM, tcharding wrote: > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote: >> tcharding wrote: I'm pretty much sure it depends on the original email headers, like above ^^^ — no name. Perhaps git config on your side should be

Re: [RESEND] rsi: Remove stack VLA usage

On Tue, Mar 13, 2018 at 10:17 PM, tcharding wrote: > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote: >> tcharding wrote: I'm pretty much sure it depends on the original email headers, like above ^^^ — no name. Perhaps git config on your side should be done. -- With Best Regards,

Richard Stallman VS Bill Gates

Richard Stallman: Plays on Ignatius known for drinking urine: https://www.youtube.com/watch?v=8c-EVhY5Vms Bill Gates: Enjoys Ghetto Feces Water: https://www.youtube.com/watch?v=t18jmxLwLFE The Alternative?: Racoh Computer: https://www.youtube.com/watch?v=x8HzSVdBHZU The earlier low-jitter

Richard Stallman VS Bill Gates

Richard Stallman: Plays on Ignatius known for drinking urine: https://www.youtube.com/watch?v=8c-EVhY5Vms Bill Gates: Enjoys Ghetto Feces Water: https://www.youtube.com/watch?v=t18jmxLwLFE The Alternative?: Racoh Computer: https://www.youtube.com/watch?v=x8HzSVdBHZU The earlier low-jitter

[PATCH] drm/panel: rm68200: add backlight dependency

Like many other panel drivers, this one fails to build when backlight support is disabled: drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe': panel-raydium-rm68200.c:(.text+0x14a): undefined reference to `devm_of_find_backlight' This adds the appropriate dependency.

[PATCH] drm/panel: rm68200: add backlight dependency

Like many other panel drivers, this one fails to build when backlight support is disabled: drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe': panel-raydium-rm68200.c:(.text+0x14a): undefined reference to `devm_of_find_backlight' This adds the appropriate dependency.

[PATCH v2 1/2] hwmon: (ucd9000) Add gpio chip interface

From: Christopher Bostic Add a struct gpio_chip and define some methods so that this device's I/O can be accessed via /sys/class/gpio. Signed-off-by: Christopher Bostic Signed-off-by: Andrew Jeffery Signed-off-by: Eddie

[PATCH v2 1/2] hwmon: (ucd9000) Add gpio chip interface

From: Christopher Bostic Add a struct gpio_chip and define some methods so that this device's I/O can be accessed via /sys/class/gpio. Signed-off-by: Christopher Bostic Signed-off-by: Andrew Jeffery Signed-off-by: Eddie James --- drivers/hwmon/pmbus/ucd9000.c | 201

[PATCH] pktgen: use dynamic allocation for debug print buffer

After the removal of the VLA, we get a harmless warning about a large stack frame: net/core/pktgen.c: In function 'pktgen_if_write': net/core/pktgen.c:1710:1: error: the frame size of 1076 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] The function was previously shown to be safe

[PATCH v2 0/2] hwmon: (ucd9000) Add gpio and debugfs interfaces

The ucd9000 series chips have gpio pins. Add a gpio chip interface to the ucd device so that users can query and set the state of the gpio pins. Add a debugfs interface using the existing pmbus debugfs directory to provide MFR_STATUS and the status of the gpi faults to users. Changes since v1:

[PATCH] pktgen: use dynamic allocation for debug print buffer

After the removal of the VLA, we get a harmless warning about a large stack frame: net/core/pktgen.c: In function 'pktgen_if_write': net/core/pktgen.c:1710:1: error: the frame size of 1076 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] The function was previously shown to be safe

[PATCH v2 0/2] hwmon: (ucd9000) Add gpio and debugfs interfaces

The ucd9000 series chips have gpio pins. Add a gpio chip interface to the ucd device so that users can query and set the state of the gpio pins. Add a debugfs interface using the existing pmbus debugfs directory to provide MFR_STATUS and the status of the gpi faults to users. Changes since v1:

[PATCH v2 2/2] hwmon: (ucd9000) Add debugfs attributes to provide mfr_status

From: Christopher Bostic Expose the gpiN_fault fields of mfr_status as individual debugfs attributes. This provides a way for users to be easily notified of gpi faults. Also provide the whole mfr_status register in debugfs. Signed-off-by: Christopher Bostic

[PATCH v2 2/2] hwmon: (ucd9000) Add debugfs attributes to provide mfr_status

From: Christopher Bostic Expose the gpiN_fault fields of mfr_status as individual debugfs attributes. This provides a way for users to be easily notified of gpi faults. Also provide the whole mfr_status register in debugfs. Signed-off-by: Christopher Bostic Signed-off-by: Andrew Jeffery

Re: linux-next: build failure after merge of the akpm-current tree

Hi Andrew, On Tue, 13 Mar 2018 12:44:34 -0700 Andrew Morton wrote: > > On Tue, 13 Mar 2018 20:51:19 +1100 Stephen Rothwell > wrote: > > > After merging the akpm-current tree, today's linux-next build (lots of > > configuations) failed like

Re: linux-next: build failure after merge of the akpm-current tree

Hi Andrew, On Tue, 13 Mar 2018 12:44:34 -0700 Andrew Morton wrote: > > On Tue, 13 Mar 2018 20:51:19 +1100 Stephen Rothwell > wrote: > > > After merging the akpm-current tree, today's linux-next build (lots of > > configuations) failed like this: > > > > (from the i386 defconfig build) > >

Re: [PATCH v3 3/3] Bluetooth: hci_qca: Add serdev support

On Tue, Mar 13, 2018 at 8:38 PM, Thierry Escande wrote: > Add support for Qualcomm serial slave devices. Probe the serial device, > retrieve its maximum speed and register a new hci uart device. > config BT_HCIUART_QCA > bool "Qualcomm Atheros protocol

Re: [PATCH v3 3/3] Bluetooth: hci_qca: Add serdev support

On Tue, Mar 13, 2018 at 8:38 PM, Thierry Escande wrote: > Add support for Qualcomm serial slave devices. Probe the serial device, > retrieve its maximum speed and register a new hci uart device. > config BT_HCIUART_QCA > bool "Qualcomm Atheros protocol support" > - depends on

Re: [PATCH v2 5/5] iommu/amd - Add a debugfs entry to specify a IOMMU device table entry

On Tue, Mar 13, 2018 at 8:54 PM, Gary R Hook wrote: > On 03/13/2018 12:20 PM, Andy Shevchenko wrote: >>> + } else if (obuf[0] == '0' && obuf[1] == 'x') { >>> + n = sscanf(obuf, "%x", _iommu_devid); >>> + } else { >>> + n = sscanf(obuf,

Re: [PATCH v2 5/5] iommu/amd - Add a debugfs entry to specify a IOMMU device table entry

On Tue, Mar 13, 2018 at 8:54 PM, Gary R Hook wrote: > On 03/13/2018 12:20 PM, Andy Shevchenko wrote: >>> + } else if (obuf[0] == '0' && obuf[1] == 'x') { >>> + n = sscanf(obuf, "%x", _iommu_devid); >>> + } else { >>> + n = sscanf(obuf, "%d", _iommu_devid);

Re: perf-core build fails on powerpc

On 13/03/2018 20:10, Sukadev Bhattiprolu wrote: + John Garry [john.ga...@huawei.com] wrote: On 13/03/2018 19:17, Sukadev Bhattiprolu wrote: Building perf on Powerpc seems broken when using Arnaldo's perf/core branch with HEAD as: 1b442ed ("perf test: Fix exit code for

Re: perf-core build fails on powerpc

On 13/03/2018 20:10, Sukadev Bhattiprolu wrote: + John Garry [john.ga...@huawei.com] wrote: On 13/03/2018 19:17, Sukadev Bhattiprolu wrote: Building perf on Powerpc seems broken when using Arnaldo's perf/core branch with HEAD as: 1b442ed ("perf test: Fix exit code for

Re: [PATCH v3 00/10] splash screen on the stm32f769 disco board

On Tue, 13 Mar 2018 16:23:10 +0100 Daniel Vetter dan...@ffwll.ch wrote: ... > Shouldn't we patch the drivers/gpu/drm/stm driver instead of the > drivers/video one? fbdev is kinda a dead end and not for adding new hw > support ... this patch series adds display driver to U-Boot project, I don't

Re: [PATCH v3 00/10] splash screen on the stm32f769 disco board

On Tue, 13 Mar 2018 16:23:10 +0100 Daniel Vetter dan...@ffwll.ch wrote: ... > Shouldn't we patch the drivers/gpu/drm/stm driver instead of the > drivers/video one? fbdev is kinda a dead end and not for adding new hw > support ... this patch series adds display driver to U-Boot project, I don't

Re: [PATCH V2] perf/x86/intel/uncore: Querying number of CHAs from CAPID6 register

On 3/13/2018 4:24 PM, Kroening, Gary wrote: I've tested this patch on the same set of hubless (single-segment) and scalable (segment-per-socket) configurations as for Kan's version 1. As far as we can tell this will also work for Cascade Lake, but will need revisiting for Ice Lake. For

Re: [PATCH V2] perf/x86/intel/uncore: Querying number of CHAs from CAPID6 register

On 3/13/2018 4:24 PM, Kroening, Gary wrote: I've tested this patch on the same set of hubless (single-segment) and scalable (segment-per-socket) configurations as for Kan's version 1. As far as we can tell this will also work for Cascade Lake, but will need revisiting for Ice Lake. For

Re: linux-next: Tree for Mar 13

Hi Dominik, On Tue, 13 Mar 2018 18:52:05 +0100 Dominik Brodowski wrote: > > would it be possible to have > >https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git > syscalls-next > > added to -next? This will probably only be for one or two release

Re: linux-next: Tree for Mar 13

Hi Dominik, On Tue, 13 Mar 2018 18:52:05 +0100 Dominik Brodowski wrote: > > would it be possible to have > >https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git > syscalls-next > > added to -next? This will probably only be for one or two release cycles, > but it might easen

Re: [RESEND RFC] translate_pid API

On Mon, Mar 12, 2018 at 10:18 AM, wrote: > Resending the RFC with participants of previous discussions > in the list. > > Following patch which is a variation of a solution discussed > in https://lwn.net/Articles/736330/ provides the users of > pid namespace,

Re: [RESEND RFC] translate_pid API

On Mon, Mar 12, 2018 at 10:18 AM, wrote: > Resending the RFC with participants of previous discussions > in the list. > > Following patch which is a variation of a solution discussed > in https://lwn.net/Articles/736330/ provides the users of > pid namespace, the functionality of pid translation

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 01:53 PM, Sinan Kaya wrote: > I agree disabling globally would be bad. Somebody can always say I have > ten switches on my system. I want to do peer-to-peer on one switch only. Now, > this change weakened security for the other switches that I had no intention > with doing P2P. > >

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

On 2018-03-12, Al Viro wrote: >> If someone else has grabbed a reference, it shouldn't be added to the >> lru list. Only decremented. >> >> if (entry->d_lockref.count == 1) > > Nah, better handle that in retain_dentry() itself. See updated > #work.dcache. > > + if

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 01:53 PM, Sinan Kaya wrote: > I agree disabling globally would be bad. Somebody can always say I have > ten switches on my system. I want to do peer-to-peer on one switch only. Now, > this change weakened security for the other switches that I had no intention > with doing P2P. > >

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

On 2018-03-12, Al Viro wrote: >> If someone else has grabbed a reference, it shouldn't be added to the >> lru list. Only decremented. >> >> if (entry->d_lockref.count == 1) > > Nah, better handle that in retain_dentry() itself. See updated > #work.dcache. > > + if

Re: [v5 1/2] mm: disable interrupts while initializing deferred pages

> Soft lockup: kernel has run for too long without rescheduling > Hard lockup: kernel has run for too long with interrupts disabled > > Both of these are detected by the NMI watchdog handler. > > 9b6e63cbf85b89b2d fixes a soft lockup by adding a manual rescheduling > point. Replacing that with

Re: [v5 1/2] mm: disable interrupts while initializing deferred pages

> Soft lockup: kernel has run for too long without rescheduling > Hard lockup: kernel has run for too long with interrupts disabled > > Both of these are detected by the NMI watchdog handler. > > 9b6e63cbf85b89b2d fixes a soft lockup by adding a manual rescheduling > point. Replacing that with

<    1   2   3   4   5   6   7   8   9   10   >