Re: [PATCH 1/1] mmc: core: export emmc revision via sysfs

Hi, On 03/22/2017 07:01 AM, Jin Qian wrote: > Extend sysfs to access ext_csd revision information. > > Signed-off-by: Jin Qian > Signed-off-by: Jin Qian I think you can choose one of them for signed-off tag. > --- > drivers/mmc/core/mmc.c | 2 ++ > 1

Re: [PATCH 1/1] mmc: core: export emmc revision via sysfs

Hi, On 03/22/2017 07:01 AM, Jin Qian wrote: > Extend sysfs to access ext_csd revision information. > > Signed-off-by: Jin Qian > Signed-off-by: Jin Qian I think you can choose one of them for signed-off tag. > --- > drivers/mmc/core/mmc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff

Build errors, was Re: [PATCH 07/13] perf, tools: Add a simple expression parser for JSON

Em Tue, Mar 21, 2017 at 04:15:49PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Mar 21, 2017 at 04:14:23PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Mon, Mar 20, 2017 at 01:17:05PM -0700, Andi Kleen escreveu: > > > From: Andi Kleen > > > > > > Add a simple

Build errors, was Re: [PATCH 07/13] perf, tools: Add a simple expression parser for JSON

Em Tue, Mar 21, 2017 at 04:15:49PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Mar 21, 2017 at 04:14:23PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Mon, Mar 20, 2017 at 01:17:05PM -0700, Andi Kleen escreveu: > > > From: Andi Kleen > > > > > > Add a simple expression parser good

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

2017-03-22 0:16 GMT+03:00 Adam Borowski : > On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote: >> After my changes to mmap(), its code now relies on the bitness of >> performing syscall. According to that, it chooses the base of allocation: >> mmap_base for 64-bit

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

2017-03-22 0:16 GMT+03:00 Adam Borowski : > On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote: >> After my changes to mmap(), its code now relies on the bitness of >> performing syscall. According to that, it chooses the base of allocation: >> mmap_base for 64-bit mmap() and

RE: [tpmdd-devel] [PATCH] tpm/tpm_crb: fix unused warnings on suspend/resume functions

> On Thu, Mar 16, 2017 at 09:51:33PM -0400, Jérémy Lefaure wrote: > > When PM_SLEEP is disabled crb_pm_suspend and crb_pm_resume are not > > used by SET_SYSTEM_SLEEP_PM_OPS even if PM is enabled: > > > > drvers/char/tpm/tpm_crb.c:540:12: warning: ‘crb_pm_suspend’ defined > > but not used

RE: [tpmdd-devel] [PATCH] tpm/tpm_crb: fix unused warnings on suspend/resume functions

> On Thu, Mar 16, 2017 at 09:51:33PM -0400, Jérémy Lefaure wrote: > > When PM_SLEEP is disabled crb_pm_suspend and crb_pm_resume are not > > used by SET_SYSTEM_SLEEP_PM_OPS even if PM is enabled: > > > > drvers/char/tpm/tpm_crb.c:540:12: warning: ‘crb_pm_suspend’ defined > > but not used

Re: linux-next: something wrong with 5-level paging

: ident_pmd_init.isra.5+0x5a/0xb0 [ 1252.015636] PGD 0 [ 1252.016003] Oops: [#1] SMP [ 1252.016003] Modules linked in: [ 1252.016003] CPU: 1 PID: 21962 Comm: kexec Not tainted 4.11.0-rc3-next-20170321 #1 [ 1252.016003] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04

Re: linux-next: something wrong with 5-level paging

: ident_pmd_init.isra.5+0x5a/0xb0 [ 1252.015636] PGD 0 [ 1252.016003] Oops: [#1] SMP [ 1252.016003] Modules linked in: [ 1252.016003] CPU: 1 PID: 21962 Comm: kexec Not tainted 4.11.0-rc3-next-20170321 #1 [ 1252.016003] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04

[PATCH] net: virtio_net: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/virtio_net.c | 50

[PATCH 1/1] mmc: core: export emmc revision via sysfs

Extend sysfs to access ext_csd revision information. Signed-off-by: Jin Qian Signed-off-by: Jin Qian --- drivers/mmc/core/mmc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index

[PATCH] net: virtio_net: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/virtio_net.c | 50

[PATCH 1/1] mmc: core: export emmc revision via sysfs

Extend sysfs to access ext_csd revision information. Signed-off-by: Jin Qian Signed-off-by: Jin Qian --- drivers/mmc/core/mmc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index 7fd722868875..08c62c9bec48 100644 ---

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, 2017-03-21 at 15:13 -0400, J. Bruce Fields wrote: > On Tue, Mar 21, 2017 at 02:46:53PM -0400, Jeff Layton wrote: > > On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote: > > > On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > > > > On Tue, 2017-03-21 at 12:30 -0400, J.

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, 2017-03-21 at 15:13 -0400, J. Bruce Fields wrote: > On Tue, Mar 21, 2017 at 02:46:53PM -0400, Jeff Layton wrote: > > On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote: > > > On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > > > > On Tue, 2017-03-21 at 12:30 -0400, J.

RE: [PATCH v2 4/4] x86/mce: Add AMD SMCA support to SRAO notifier

> -Original Message- > From: Ghannam, Yazen > Sent: Monday, March 20, 2017 4:27 PM [...] > +/* Only support this on SMCA systems and errors logged from a UMC. */ > +static int mce_usable_address_amd(struct mce *m, unsigned long *pfn) { > + u8 umc; This should be int umc; to

RE: [PATCH v2 4/4] x86/mce: Add AMD SMCA support to SRAO notifier

> -Original Message- > From: Ghannam, Yazen > Sent: Monday, March 20, 2017 4:27 PM [...] > +/* Only support this on SMCA systems and errors logged from a UMC. */ > +static int mce_usable_address_amd(struct mce *m, unsigned long *pfn) { > + u8 umc; This should be int umc; to

Re: [PATCH net] r8152: fix the list rx_done may be used without initialization

From: Hayes Wang Date: Tue, 14 Mar 2017 14:15:20 +0800 > The list rx_done would be initialized when the linking on occurs. > Therefore, if a napi is scheduled without any linking on before, > the following kernel panic would happen. > > BUG: unable to handle kernel

Re: [PATCH net] r8152: fix the list rx_done may be used without initialization

From: Hayes Wang Date: Tue, 14 Mar 2017 14:15:20 +0800 > The list rx_done would be initialized when the linking on occurs. > Therefore, if a napi is scheduled without any linking on before, > the following kernel panic would happen. > > BUG: unable to handle kernel NULL pointer

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote: > > - It's durable; the above comparison still works if there were reboots > > between the two i_version checks. > > - I don't know how realistic this is--we may need to

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote: > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote: > > - It's durable; the above comparison still works if there were reboots > > between the two i_version checks. > > - I don't know how realistic this is--we may need to

Re: run_timer_softirq gpf. [smc]

On Tue, 21 Mar 2017, Dave Jones wrote: > On Tue, Mar 21, 2017 at 08:25:39PM +0100, Thomas Gleixner wrote: > > > > I just hit this while fuzzing.. > > > > > > general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC > > > CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.11.0-rc2-think+ #1

Re: run_timer_softirq gpf. [smc]

On Tue, 21 Mar 2017, Dave Jones wrote: > On Tue, Mar 21, 2017 at 08:25:39PM +0100, Thomas Gleixner wrote: > > > > I just hit this while fuzzing.. > > > > > > general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC > > > CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.11.0-rc2-think+ #1

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 2:16:48 PM PDT, Adam Borowski wrote: >On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote: >> After my changes to mmap(), its code now relies on the bitness of >> performing syscall. According to that, it chooses the base of >allocation: >>

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 2:16:48 PM PDT, Adam Borowski wrote: >On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote: >> After my changes to mmap(), its code now relies on the bitness of >> performing syscall. According to that, it chooses the base of >allocation: >> mmap_base for 64-bit mmap()

[PATCH 1/1] crypto: If two strings are exact match, they must have same length.

When both "crct10dif-pclmul" algorithm and "crct10dif-generic" algorithm exist in crypto_alg_list, "crct10dif-pclmul" should be selected, since it has higher priority than "crct10dif-generic". However, both algorithms have the same cra_name "crct10dif". If we use "crct10dif" to find a matched

[PATCH 1/1] crypto: If two strings are exact match, they must have same length.

When both "crct10dif-pclmul" algorithm and "crct10dif-generic" algorithm exist in crypto_alg_list, "crct10dif-pclmul" should be selected, since it has higher priority than "crct10dif-generic". However, both algorithms have the same cra_name "crct10dif". If we use "crct10dif" to find a matched

Re: [PATCH] staging: wilc1000: use kernel define byte order macros

Thanks for taking a look, Dan. Sorry if I missed the mark here. Can you tell me a bit more about the bug this would introduce? I see that ieee80211_is_action is defined like this: static inline bool ieee80211_is_action(__le16 fc) ...and that buff[FRAME_TYPE_ID]is a u8 (since FRAME_TYPE_ID =

Re: [PATCH] staging: wilc1000: use kernel define byte order macros

Thanks for taking a look, Dan. Sorry if I missed the mark here. Can you tell me a bit more about the bug this would introduce? I see that ieee80211_is_action is defined like this: static inline bool ieee80211_is_action(__le16 fc) ...and that buff[FRAME_TYPE_ID]is a u8 (since FRAME_TYPE_ID =

Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC

> Aspeed AST2400/AST2500 BMC SoCs include a 16 channel, 10-bit ADC. Low > and high threshold interrupts are supported by the hardware but are not > currently implemented. comments below link to a datasheet would be nice > Signed-off-by: Rick Altherr > --- > > Changes in

Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC

> Aspeed AST2400/AST2500 BMC SoCs include a 16 channel, 10-bit ADC. Low > and high threshold interrupts are supported by the hardware but are not > currently implemented. comments below link to a datasheet would be nice > Signed-off-by: Rick Altherr > --- > > Changes in v2: > - Rewritten as

Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t

On Tue, 2017-03-21 at 13:49 -0700, Kees Cook wrote: > Yeah, this is exactly what I'd like to find as well. Just comparing > cycles between refcount implementations, while interesting, doesn't > show us real-world performance changes, which is what we need to > measure. > > Is Eric's "20

Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t

On Tue, 2017-03-21 at 13:49 -0700, Kees Cook wrote: > Yeah, this is exactly what I'd like to find as well. Just comparing > cycles between refcount implementations, while interesting, doesn't > show us real-world performance changes, which is what we need to > measure. > > Is Eric's "20

Re: [PATCH 2/3] asm-generic, x86: wrap atomic operations

On Tue, Mar 21, 2017 at 7:06 PM, Dmitry Vyukov wrote: > On Tue, Mar 21, 2017 at 11:41 AM, Mark Rutland wrote: >> On Tue, Mar 21, 2017 at 12:25:06PM +0300, Andrey Ryabinin wrote: > > I don't mind changing READ_ONCE_NOCHECK to READ_ONCE. But I don't have >

Re: [PATCH 2/3] asm-generic, x86: wrap atomic operations

On Tue, Mar 21, 2017 at 7:06 PM, Dmitry Vyukov wrote: > On Tue, Mar 21, 2017 at 11:41 AM, Mark Rutland wrote: >> On Tue, Mar 21, 2017 at 12:25:06PM +0300, Andrey Ryabinin wrote: > > I don't mind changing READ_ONCE_NOCHECK to READ_ONCE. But I don't have > strong preference either way. > > We

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote: > After my changes to mmap(), its code now relies on the bitness of > performing syscall. According to that, it chooses the base of allocation: > mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall. > It was done by: >

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote: > After my changes to mmap(), its code now relies on the bitness of > performing syscall. According to that, it chooses the base of allocation: > mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall. > It was done by: >

Re: [PATCH v5 2/4] fpga pr ip: Core driver support for Altera Partial Reconfiguration IP.

Hi Matthew, On Fri, 10 Mar 2017 11:40:25 -0800 matthew.gerl...@linux.intel.com matthew.gerl...@linux.intel.com wrote: ... >+int alt_pr_unregister(struct device *dev) >+{ >+ dev_dbg(dev, "%s\n", __func__); >+ >+ fpga_mgr_unregister(dev); >+ >+ return 0; >+}

Re: [PATCH v5 2/4] fpga pr ip: Core driver support for Altera Partial Reconfiguration IP.

Hi Matthew, On Fri, 10 Mar 2017 11:40:25 -0800 matthew.gerl...@linux.intel.com matthew.gerl...@linux.intel.com wrote: ... >+int alt_pr_unregister(struct device *dev) >+{ >+ dev_dbg(dev, "%s\n", __func__); >+ >+ fpga_mgr_unregister(dev); >+ >+ return 0; >+}

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On 03/21/2017 10:24 PM, Cyrill Gorcunov wrote: On Tue, Mar 21, 2017 at 10:19:01PM +0300, Dmitry Safonov wrote: indeed, thanks! Also, even more simple-minded: for now we could just check binary magic from /proc/.../exe, for now stopping on x32 binaries. File may not exist and elfheader

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On 03/21/2017 10:24 PM, Cyrill Gorcunov wrote: On Tue, Mar 21, 2017 at 10:19:01PM +0300, Dmitry Safonov wrote: indeed, thanks! Also, even more simple-minded: for now we could just check binary magic from /proc/.../exe, for now stopping on x32 binaries. File may not exist and elfheader

Re: Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

Michael Zoran writes: > On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote: >> Michael Zoran writes: >> >> > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote: >> > > Michael Zoran writes: >> > > >> > > > > > Since the API

Re: Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

Michael Zoran writes: > On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote: >> Michael Zoran writes: >> >> > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote: >> > > Michael Zoran writes: >> > > >> > > > > > Since the API is completely documented, I see no reason we >> > > > > > or >>

Re: [lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

On Tue, Mar 21, 2017 at 1:25 PM, Thomas Garnier wrote: > The issue seems to be related to exceptions happening in close pages > to the fixmap GDT remapping. > > The original page fault happen in do_test_wp_bit which set a fixmap > entry to test WP flag. If I grow the number

Re: [PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver

On Tue, Mar 21, 2017 at 01:38:31PM -0700, Brian Norris wrote: > + Thierry for real > > On Tue, Mar 21, 2017 at 03:26:35PM -0400, Sean Paul wrote: > > On Wed, Mar 15, 2017 at 03:19:13PM +0800, Chris Zhong wrote: > > > Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI > > >

Re: [lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

On Tue, Mar 21, 2017 at 1:25 PM, Thomas Garnier wrote: > The issue seems to be related to exceptions happening in close pages > to the fixmap GDT remapping. > > The original page fault happen in do_test_wp_bit which set a fixmap > entry to test WP flag. If I grow the number of processors

Re: [PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver

On Tue, Mar 21, 2017 at 01:38:31PM -0700, Brian Norris wrote: > + Thierry for real > > On Tue, Mar 21, 2017 at 03:26:35PM -0400, Sean Paul wrote: > > On Wed, Mar 15, 2017 at 03:19:13PM +0800, Chris Zhong wrote: > > > Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI > > >

[PATCH v6 2/4] fpga pr ip: Core driver support for Altera Partial Reconfiguration IP.

From: Matthew Gerlach Adding the core functions necessary for a fpga-mgr driver for the Altera Partial IP component. It is intended for these functions to be used by the various bus implementations like the platform bus or the PCIe bus. Signed-off-by: Matthew

[PATCH v6 2/4] fpga pr ip: Core driver support for Altera Partial Reconfiguration IP.

From: Matthew Gerlach Adding the core functions necessary for a fpga-mgr driver for the Altera Partial IP component. It is intended for these functions to be used by the various bus implementations like the platform bus or the PCIe bus. Signed-off-by: Matthew Gerlach --- v6: Suggestions

[PATCH v6 4/4] fpga pr ip: Platform driver for Altera Partial Reconfiguration IP.

From: Matthew Gerlach This adds a platform bus driver for a fpga-mgr driver that uses the Altera Partial Reconfiguration IP component. Signed-off-by: Matthew Gerlach --- v6: add MODULE_LICENSE/DESCRIPTION/AUTHOR as suggested

[PATCH v6 4/4] fpga pr ip: Platform driver for Altera Partial Reconfiguration IP.

From: Matthew Gerlach This adds a platform bus driver for a fpga-mgr driver that uses the Altera Partial Reconfiguration IP component. Signed-off-by: Matthew Gerlach --- v6: add MODULE_LICENSE/DESCRIPTION/AUTHOR as suggested by Anatolij Gustschin v5: fix comment as suggested by Rob

[PATCH v6 3/4] fpga dt: bindings for Altera Partial Reconfiguration IP.

From: Matthew Gerlach Device Tree bindings for Altera Partial Reconfiguration IP. Signed-off-by: Matthew Gerlach Acked-by: Rob Herring --- v5: fix comment as suggested by Rob Herring

[PATCH v6 3/4] fpga dt: bindings for Altera Partial Reconfiguration IP.

From: Matthew Gerlach Device Tree bindings for Altera Partial Reconfiguration IP. Signed-off-by: Matthew Gerlach Acked-by: Rob Herring --- v5: fix comment as suggested by Rob Herring added Acked-by: Rob Herring v4: v3 patch set mistakenly sent out labeled as v4 v3:

[PATCH v6 1/4] fpga: add config complete timeout

From: Alan Tull Adding timeout for maximum allowed time for FPGA to go to operating mode after a FPGA region has been programmed. Signed-off-by: Alan Tull --- drivers/fpga/fpga-region.c| 3 +++ include/linux/fpga/fpga-mgr.h | 3 +++

[PATCH v6 1/4] fpga: add config complete timeout

From: Alan Tull Adding timeout for maximum allowed time for FPGA to go to operating mode after a FPGA region has been programmed. Signed-off-by: Alan Tull --- drivers/fpga/fpga-region.c| 3 +++ include/linux/fpga/fpga-mgr.h | 3 +++ 2 files changed, 6 insertions(+) diff --git

[PATCH v6 0/4] Altera Partial Reconfiguration IP

From: Matthew Gerlach This set of patches implements a fpga-mgr driver for the Altera Partial Reconfiguration IP. The driver depends on a patch from Alan Tull that adds a config complete timeout. The driver code itself is divided into core functions and

[PATCH v6 0/4] Altera Partial Reconfiguration IP

From: Matthew Gerlach This set of patches implements a fpga-mgr driver for the Altera Partial Reconfiguration IP. The driver depends on a patch from Alan Tull that adds a config complete timeout. The driver code itself is divided into core functions and functions to implement a platform

[PATCH net] net: bcmgenet: remove bcmgenet_internal_phy_setup()

Commit 6ac3ce8295e6 ("net: bcmgenet: Remove excessive PHY reset") removed the bcmgenet_mii_reset() function from bcmgenet_power_up() and bcmgenet_internal_phy_setup() functions. In so doing it broke the reset of the internal PHY devices used by the GENETv1-GENETv3 which required this reset before

[PATCH net] net: bcmgenet: remove bcmgenet_internal_phy_setup()

Commit 6ac3ce8295e6 ("net: bcmgenet: Remove excessive PHY reset") removed the bcmgenet_mii_reset() function from bcmgenet_power_up() and bcmgenet_internal_phy_setup() functions. In so doing it broke the reset of the internal PHY devices used by the GENETv1-GENETv3 which required this reset before

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On 03/21/2017 09:40 PM, Cyrill Gorcunov wrote: On Tue, Mar 21, 2017 at 09:09:40PM +0300, Dmitry Safonov wrote: I guess the question comes from that we're releasing CRIU 3.0 with 32-bit C/R and some other cool stuff, but we don't support x32 yet. As we don't want release a thing that we aren't

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On 03/21/2017 09:40 PM, Cyrill Gorcunov wrote: On Tue, Mar 21, 2017 at 09:09:40PM +0300, Dmitry Safonov wrote: I guess the question comes from that we're releasing CRIU 3.0 with 32-bit C/R and some other cool stuff, but we don't support x32 yet. As we don't want release a thing that we aren't

iov_iter_pipe warning.

WARNING: CPU: 0 PID: 9290 at lib/iov_iter.c:836 iov_iter_pipe+0x71/0x80 CPU: 0 PID: 9290 Comm: trinity-c7 Not tainted 4.11.0-rc3-think+ #3 Call Trace: dump_stack+0x68/0x93 __warn+0xcb/0xf0 warn_slowpath_null+0x1d/0x20 iov_iter_pipe+0x71/0x80 generic_file_splice_read+0x37/0x140

iov_iter_pipe warning.

WARNING: CPU: 0 PID: 9290 at lib/iov_iter.c:836 iov_iter_pipe+0x71/0x80 CPU: 0 PID: 9290 Comm: trinity-c7 Not tainted 4.11.0-rc3-think+ #3 Call Trace: dump_stack+0x68/0x93 __warn+0xcb/0xf0 warn_slowpath_null+0x1d/0x20 iov_iter_pipe+0x71/0x80 generic_file_splice_read+0x37/0x140

[PATCH] ARM: gemini: don't select SERIAL_OF_PLATFORM

We cannot select the option when SERIAL_8250 is not also set: warning: (ARCH_GEMINI) selects SERIAL_OF_PLATFORM which has unmet direct dependencies (TTY && HAS_IOMEM && SERIAL_8250 && OF) This removes the 'select' statement, requiring that users enable the option manually. Alternatively, we

[PATCH] ARM: gemini: don't select SERIAL_OF_PLATFORM

We cannot select the option when SERIAL_8250 is not also set: warning: (ARCH_GEMINI) selects SERIAL_OF_PLATFORM which has unmet direct dependencies (TTY && HAS_IOMEM && SERIAL_8250 && OF) This removes the 'select' statement, requiring that users enable the option manually. Alternatively, we

[PATCH] arm64: dts: NS2: Add dma-coherent to relevant DT entries

Cache related issues with DMA rings and performance issues related to caching are being caused by not properly setting the "dma-coherent" flag in the device tree entries. Adding it here to correct the issue. Signed-off-by: Jon Mason Fixes: fd5e5dd56 ("arm64: dts: Add

[PATCH] arm64: dts: NS2: Add dma-coherent to relevant DT entries

Cache related issues with DMA rings and performance issues related to caching are being caused by not properly setting the "dma-coherent" flag in the device tree entries. Adding it here to correct the issue. Signed-off-by: Jon Mason Fixes: fd5e5dd56 ("arm64: dts: Add PCIe0 and PCIe4 DT nodes

[PATCH v2 0/7] Add support for pinctrl/gpio on Armada 37xx Was Re: [PATCH v2 0/7] Hi,

Hi, Obviously this cover letter is wrong. Actually I forgot to commit it in git series. Here it is the correct one: After several months here it is the second version of the series adding support for the pin and gpio controllers present on the Armada 37xx SoCs. Each Armada 37xx SoC comes with 2

[PATCH v2 0/7] Add support for pinctrl/gpio on Armada 37xx Was Re: [PATCH v2 0/7] Hi,

Hi, Obviously this cover letter is wrong. Actually I forgot to commit it in git series. Here it is the correct one: After several months here it is the second version of the series adding support for the pin and gpio controllers present on the Armada 37xx SoCs. Each Armada 37xx SoC comes with 2

linux-next: something wrong with 5-level paging

.amazonaws.com/archive.travis-ci.org/jobs/213276252/log.txt I bisected this issue and here is the bisect log: [avagin@laptop linux-next]$ git bisect log # bad: [50eff530518ae89e25d09ec1aa41a7aea6a7d51c] Add linux-next specific files for 20170321 # good: [97da3854c526d3a6ee05c849c96e48d21527606c] Linux 4.11

linux-next: something wrong with 5-level paging

.amazonaws.com/archive.travis-ci.org/jobs/213276252/log.txt I bisected this issue and here is the bisect log: [avagin@laptop linux-next]$ git bisect log # bad: [50eff530518ae89e25d09ec1aa41a7aea6a7d51c] Add linux-next specific files for 20170321 # good: [97da3854c526d3a6ee05c849c96e48d21527606c] Linux 4.11

Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t

On Mon, Mar 20, 2017 at 6:40 AM, Peter Zijlstra wrote: > On Mon, Mar 20, 2017 at 09:27:13PM +0800, Herbert Xu wrote: >> On Mon, Mar 20, 2017 at 02:23:57PM +0100, Peter Zijlstra wrote: >> > >> > So what bench/setup do you want ran? >> >> You can start by counting how many

Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t

On Mon, Mar 20, 2017 at 6:40 AM, Peter Zijlstra wrote: > On Mon, Mar 20, 2017 at 09:27:13PM +0800, Herbert Xu wrote: >> On Mon, Mar 20, 2017 at 02:23:57PM +0100, Peter Zijlstra wrote: >> > >> > So what bench/setup do you want ran? >> >> You can start by counting how many cycles an atomic op takes

[PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC

Aspeed AST2400/AST2500 BMC SoCs include a 16 channel, 10-bit ADC. Low and high threshold interrupts are supported by the hardware but are not currently implemented. Signed-off-by: Rick Altherr --- Changes in v2: - Rewritten as an IIO device - Renamed register macros to

[PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC

Aspeed AST2400/AST2500 BMC SoCs include a 16 channel, 10-bit ADC. Low and high threshold interrupts are supported by the hardware but are not currently implemented. Signed-off-by: Rick Altherr --- Changes in v2: - Rewritten as an IIO device - Renamed register macros to describe the register's

[PATCH v2 1/2] Documentation: dt-bindings: Document bindings for Aspeed AST2400/AST2500 ADC

Signed-off-by: Rick Altherr --- Changes in v2: - Rewritten as an IIO ADC device .../devicetree/bindings/iio/adc/aspeed_adc.txt | 20 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt

[PATCH v2 1/2] Documentation: dt-bindings: Document bindings for Aspeed AST2400/AST2500 ADC

Signed-off-by: Rick Altherr --- Changes in v2: - Rewritten as an IIO ADC device .../devicetree/bindings/iio/adc/aspeed_adc.txt | 20 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt diff --git

Re: [PATCH] acpi: fix incompatibility with mcount-based function graph tracing

Dear Josh, On 2017-03-16 14:56, Josh Poimboeuf wrote: Paul Menzel reported a warning: WARNING: CPU: 0 PID: 774 at /build/linux-ROBWaj/linux-4.9.13/kernel/trace/trace_functions_graph.c:233 ftrace_return_to_handler+0x1aa/0x1e0 Bad frame pointer: expected f6919d98, received f6919db0 from

Re: [PATCH] acpi: fix incompatibility with mcount-based function graph tracing

Dear Josh, On 2017-03-16 14:56, Josh Poimboeuf wrote: Paul Menzel reported a warning: WARNING: CPU: 0 PID: 774 at /build/linux-ROBWaj/linux-4.9.13/kernel/trace/trace_functions_graph.c:233 ftrace_return_to_handler+0x1aa/0x1e0 Bad frame pointer: expected f6919d98, received f6919db0 from

Re: [PATCHv2 2/2] super1: check and output faulty dev role

On Mon, Mar 20 2017, Gioh Kim wrote: > From: Jack Wang > > Output the real dev role in examine_super1, it will help to > find problem. > > Signed-off-by: Jack Wang > Reviewed-by: Gioh Kim > --- > super1.c |

Re: [PATCHv2 2/2] super1: check and output faulty dev role

On Mon, Mar 20 2017, Gioh Kim wrote: > From: Jack Wang > > Output the real dev role in examine_super1, it will help to > find problem. > > Signed-off-by: Jack Wang > Reviewed-by: Gioh Kim > --- > super1.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/super1.c

Re: run_timer_softirq gpf. tracing?

On Tue, 21 Mar 2017, Dave Jones wrote: > I just hit this while fuzzing.. > > general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC > CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.11.0-rc2-think+ #1 > task: 88017f0ed440 task.stack: c9094000 > RIP:

Re: run_timer_softirq gpf. tracing?

On Tue, 21 Mar 2017, Dave Jones wrote: > I just hit this while fuzzing.. > > general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC > CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.11.0-rc2-think+ #1 > task: 88017f0ed440 task.stack: c9094000 > RIP:

Re: [PATCH] mm, swap: Remove WARN_ON_ONCE() in free_swap_slot()

On Mon, 2017-03-20 at 14:26 +0800, Huang, Ying wrote: > From: Huang Ying > > Before commit 452b94b8c8c7 ("mm/swap: don't BUG_ON() due to > uninitialized swap slot cache"), the following bug is reported, > >   [ cut here ] >   kernel BUG at

Re: [PATCH] mm, swap: Remove WARN_ON_ONCE() in free_swap_slot()

On Mon, 2017-03-20 at 14:26 +0800, Huang, Ying wrote: > From: Huang Ying > > Before commit 452b94b8c8c7 ("mm/swap: don't BUG_ON() due to > uninitialized swap slot cache"), the following bug is reported, > >   [ cut here ] >   kernel BUG at mm/swap_slots.c:270! >  

Hello

Hello Friend, Compliment of the day, I got your contact information from a reputable business/professional directory of your country which gives me assurance of your legibility as a person. I send you this brief letter to solicit your partnership to transfer ($22,500,000.00 USD) from Reserve

Hello

Hello Friend, Compliment of the day, I got your contact information from a reputable business/professional directory of your country which gives me assurance of your legibility as a person. I send you this brief letter to solicit your partnership to transfer ($22,500,000.00 USD) from Reserve

Re: 32-bit x86 system reboots automatically on resume from hibernate (ASLR issue?)

On Tue, Mar 21, 2017 at 6:54 AM, Evgenii Shatokhin wrote: > Hi, > > One of my x86 machines with a 32-bit Linux system (ROSA Linux in this case) > automatically reboots when it tries to resume from hibernate. This happens > shortly after "Image loading progress 100%"

Re: 32-bit x86 system reboots automatically on resume from hibernate (ASLR issue?)

On Tue, Mar 21, 2017 at 6:54 AM, Evgenii Shatokhin wrote: > Hi, > > One of my x86 machines with a 32-bit Linux system (ROSA Linux in this case) > automatically reboots when it tries to resume from hibernate. This happens > shortly after "Image loading progress 100%" message is shown on the

Re: [PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver

+ Thierry for real On Tue, Mar 21, 2017 at 03:26:35PM -0400, Sean Paul wrote: > On Wed, Mar 15, 2017 at 03:19:13PM +0800, Chris Zhong wrote: > > Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI > > panel. > > > > Signed-off-by: Chris Zhong > > --- > >

Re: [PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver

+ Thierry for real On Tue, Mar 21, 2017 at 03:26:35PM -0400, Sean Paul wrote: > On Wed, Mar 15, 2017 at 03:19:13PM +0800, Chris Zhong wrote: > > Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI > > panel. > > > > Signed-off-by: Chris Zhong > > --- > > > > Changes in v2: >

Re: [PATCH v3 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

On Tue, Mar 21, 2017 at 04:16:23PM -0400, Sean Paul wrote: > On Fri, Mar 17, 2017 at 11:54:21AM +0800, Chris Zhong wrote: > > For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is > > disabled, MIPI phy can not work. Let's return a error if there is no > > phy_cfg_clk in dts property,

Re: [PATCH v3 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

On Tue, Mar 21, 2017 at 04:16:23PM -0400, Sean Paul wrote: > On Fri, Mar 17, 2017 at 11:54:21AM +0800, Chris Zhong wrote: > > For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is > > disabled, MIPI phy can not work. Let's return a error if there is no > > phy_cfg_clk in dts property,

Re: [PATCH v3 3/4] drm/rockchip/dsi: enable the grf clk before writing grf registers

On Fri, Mar 17, 2017 at 11:54:23AM +0800, Chris Zhong wrote: > For RK3399, the grf clk should be enabled before writing grf registers, > otherwise the register value can not be changed. > > Signed-off-by: Chris Zhong Minor nit below, with that: Reviewed-by: Sean Paul

Re: [PATCH v3 3/4] drm/rockchip/dsi: enable the grf clk before writing grf registers

On Fri, Mar 17, 2017 at 11:54:23AM +0800, Chris Zhong wrote: > For RK3399, the grf clk should be enabled before writing grf registers, > otherwise the register value can not be changed. > > Signed-off-by: Chris Zhong Minor nit below, with that: Reviewed-by: Sean Paul > --- > > Changes in

Re: [PATCH v3 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

On Tue, Mar 21, 2017 at 04:17:00PM -0400, Sean Paul wrote: > On Fri, Mar 17, 2017 at 11:54:22AM +0800, Chris Zhong wrote: > > For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, > > add the description for this clock. > > > > Signed-off-by: Chris Zhong > >

Re: [PATCH v3 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

On Tue, Mar 21, 2017 at 04:17:00PM -0400, Sean Paul wrote: > On Fri, Mar 17, 2017 at 11:54:22AM +0800, Chris Zhong wrote: > > For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, > > add the description for this clock. > > > > Signed-off-by: Chris Zhong > > --- > > > > Changes

Re: [lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

The issue seems to be related to exceptions happening in close pages to the fixmap GDT remapping. The original page fault happen in do_test_wp_bit which set a fixmap entry to test WP flag. If I grow the number of processors supported increasing the distance between the remapped GDT page and the

Re: [lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

The issue seems to be related to exceptions happening in close pages to the fixmap GDT remapping. The original page fault happen in do_test_wp_bit which set a fixmap entry to test WP flag. If I grow the number of processors supported increasing the distance between the remapped GDT page and the

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