Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

On 4/20/2017 11:59 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:17:11PM -0500, Tom Lendacky wrote: When System Memory Encryption (SME) is enabled, the physical address space is reduced. Adjust the x86_phys_bits value to reflect this reduction. Signed-off-by: Tom Lendacky

Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

On 4/20/2017 11:59 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:17:11PM -0500, Tom Lendacky wrote: When System Memory Encryption (SME) is enabled, the physical address space is reduced. Adjust the x86_phys_bits value to reflect this reduction. Signed-off-by: Tom Lendacky ---

Re: [PATCH v4 6/6] mtd: dataflash: Add flash_info for AT45DB641E

On 04/20/2017 06:29 PM, Andrey Smirnov wrote: > Cc: cphe...@gmail.com > Cc: David Woodhouse > Cc: Brian Norris > Cc: Boris Brezillon > Cc: Marek Vasut > Cc: Richard Weinberger

Re: [PATCH v4 6/6] mtd: dataflash: Add flash_info for AT45DB641E

On 04/20/2017 06:29 PM, Andrey Smirnov wrote: > Cc: cphe...@gmail.com > Cc: David Woodhouse > Cc: Brian Norris > Cc: Boris Brezillon > Cc: Marek Vasut > Cc: Richard Weinberger > Cc: Cyrille Pitchen > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Andrey Smirnov Acked-by: Marek Vasut >

Re: [PATCH v4 5/6] mtd: dataflash: Make use of "extened device information"

On 04/20/2017 06:29 PM, Andrey Smirnov wrote: > In anticipation of supporting chips that need it, extend the size of > struct flash_info's 'jedec_id' field to make room 2 byte of extended > device information as well as add code to fetch this data during > jedec_probe(). > > Cc: cphe...@gmail.com

Re: [PATCH v4 5/6] mtd: dataflash: Make use of "extened device information"

On 04/20/2017 06:29 PM, Andrey Smirnov wrote: > In anticipation of supporting chips that need it, extend the size of > struct flash_info's 'jedec_id' field to make room 2 byte of extended > device information as well as add code to fetch this data during > jedec_probe(). > > Cc: cphe...@gmail.com

Re: [PATCH] fs:orangefs:orangefs-debug, orangefs-kernel: Fixing warning issues and use ARRAY_SIZE

Hi Karim, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170420] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Karim-Eshapa/fs-orangefs-orangefs-debug

Re: [PATCH] fs:orangefs:orangefs-debug, orangefs-kernel: Fixing warning issues and use ARRAY_SIZE

Hi Karim, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170420] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Karim-Eshapa/fs-orangefs-orangefs-debug

Re: [PATCH 0/5] fs, xfs refcount conversions

On Thu, Apr 20, 2017 at 08:11:41AM +, Reshetova, Elena wrote: > > > > v3: > > * fixed header file inclusion > > I don't think I have heard anything back on this v3 patch set. > Is there still smth here to fix or could you take the changes in? Generally I think it looks ok; it's running

Re: [PATCH 0/5] fs, xfs refcount conversions

On Thu, Apr 20, 2017 at 08:11:41AM +, Reshetova, Elena wrote: > > > > v3: > > * fixed header file inclusion > > I don't think I have heard anything back on this v3 patch set. > Is there still smth here to fix or could you take the changes in? Generally I think it looks ok; it's running

Re: [PATCH v6 1/4] net: dsa: add support for the SMSC-LAN9303 tagging format

On 04/18/2017 01:48 AM, Juergen Borleis wrote: > To define the outgoing port and to discover the incoming port a regular > VLAN tag is used by the LAN9303. But its VID meaning is 'special'. > > This tag handler/filter depends on some hardware features which must be > enabled in the device to

Re: [PATCH v6 1/4] net: dsa: add support for the SMSC-LAN9303 tagging format

On 04/18/2017 01:48 AM, Juergen Borleis wrote: > To define the outgoing port and to discover the incoming port a regular > VLAN tag is used by the LAN9303. But its VID meaning is 'special'. > > This tag handler/filter depends on some hardware features which must be > enabled in the device to

Re: [PATCH] fs:orangefs:orangefs-debug, orangefs-kernel: Fixing warning issues and use ARRAY_SIZE

Hi Karim, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170420] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Karim-Eshapa/fs-orangefs-orangefs-debug

Re: [PATCH] fs:orangefs:orangefs-debug, orangefs-kernel: Fixing warning issues and use ARRAY_SIZE

Hi Karim, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170420] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Karim-Eshapa/fs-orangefs-orangefs-debug

Re: [PATCH] net/mlx4: suppress 'may be used uninitialized' warning

From: Greg Thelen Date: Mon, 17 Apr 2017 23:21:35 -0700 > gcc 4.8.4 complains that mlx4_SW2HW_MPT_wrapper() uses an uninitialized > 'mpt' variable: > drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function > 'mlx4_SW2HW_MPT_wrapper': >

Re: [PATCH] net/mlx4: suppress 'may be used uninitialized' warning

From: Greg Thelen Date: Mon, 17 Apr 2017 23:21:35 -0700 > gcc 4.8.4 complains that mlx4_SW2HW_MPT_wrapper() uses an uninitialized > 'mpt' variable: > drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function > 'mlx4_SW2HW_MPT_wrapper': >

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

On 2017-04-20 11:19, Serge E. Hallyn wrote: Quoting Matt Brown (m...@nmatt.com): On 04/19/2017 07:53 PM, Serge E. Hallyn wrote: >Quoting Matt Brown (m...@nmatt.com): >>On 04/19/2017 12:58 AM, Serge E. Hallyn wrote: >>>On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote: This patch

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

On 2017-04-20 11:19, Serge E. Hallyn wrote: Quoting Matt Brown (m...@nmatt.com): On 04/19/2017 07:53 PM, Serge E. Hallyn wrote: >Quoting Matt Brown (m...@nmatt.com): >>On 04/19/2017 12:58 AM, Serge E. Hallyn wrote: >>>On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote: This patch

Re: [PATCH v2] PCI: disable SERR for kdump kernel

On 4/18/2017 8:31 PM, Yinghai Lu wrote: > * pci_setup_device - fill in class and map information of a device > * @dev: the device structure to fill > @@ -1572,6 +1592,9 @@ int pci_setup_device(struct pci_dev *dev > /* device class may be changed after fixup */ > class = dev->class >>

Re: [PATCH v2] PCI: disable SERR for kdump kernel

On 4/18/2017 8:31 PM, Yinghai Lu wrote: > * pci_setup_device - fill in class and map information of a device > * @dev: the device structure to fill > @@ -1572,6 +1592,9 @@ int pci_setup_device(struct pci_dev *dev > /* device class may be changed after fixup */ > class = dev->class >>

[PATCH] staging: ccree: fix semicolon.cocci warnings

drivers/staging/ccree/ssi_request_mgr.c:623:3-4: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Gilad Ben-Yossef Signed-off-by: Fengguang Wu --- ssi_request_mgr.c |2 +- 1 file

[PATCH] staging: ccree: fix ifnullfree.cocci warnings

drivers/staging/ccree/ssi_buffer_mgr.c:530:3-19: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid passing NULL values. NULL check before some freeing functions is

[PATCH] staging: ccree: fix semicolon.cocci warnings

drivers/staging/ccree/ssi_request_mgr.c:623:3-4: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Gilad Ben-Yossef Signed-off-by: Fengguang Wu --- ssi_request_mgr.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ---

[PATCH] staging: ccree: fix ifnullfree.cocci warnings

drivers/staging/ccree/ssi_buffer_mgr.c:530:3-19: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid passing NULL values. NULL check before some freeing functions is

[PATCH] staging: ccree: fix platform_no_drv_owner.cocci warnings

drivers/staging/ccree/ssi_driver.c:484:6-11: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci CC: Gilad Ben-Yossef Signed-off-by: Fengguang

Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock

On Wed, 19 Apr 2017, Peter Zijlstra wrote: - explain why the loss of lock stealing makes sense. IIRC walken added that specifically to address mmap_sem performance issues. That's right, and the same applies to the writer spinning stuff; which can makes a huge difference - more so than

Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock

On Wed, 19 Apr 2017, Peter Zijlstra wrote: - explain why the loss of lock stealing makes sense. IIRC walken added that specifically to address mmap_sem performance issues. That's right, and the same applies to the writer spinning stuff; which can makes a huge difference - more so than

[PATCH] staging: ccree: fix platform_no_drv_owner.cocci warnings

drivers/staging/ccree/ssi_driver.c:484:6-11: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci CC: Gilad Ben-Yossef Signed-off-by: Fengguang Wu --- ssi_driver.c

[PATCH] staging: ccree: fix array_size.cocci warnings

drivers/staging/ccree/ssi_sysfs.c:319:34-35: WARNING: Use ARRAY_SIZE drivers/staging/ccree/ssi_sysfs.c:429:34-35: WARNING: Use ARRAY_SIZE Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element Semantic patch information: This makes an effort to find cases where ARRAY_SIZE can

Re: [PATCH v2 1/9] staging: ccree: introduce CryptoCell HW driver

Hi Gilad, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7] [cannot apply to staging/staging-testing next-20170420] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

[PATCH] staging: ccree: fix array_size.cocci warnings

drivers/staging/ccree/ssi_sysfs.c:319:34-35: WARNING: Use ARRAY_SIZE drivers/staging/ccree/ssi_sysfs.c:429:34-35: WARNING: Use ARRAY_SIZE Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element Semantic patch information: This makes an effort to find cases where ARRAY_SIZE can

Re: [PATCH v2 1/9] staging: ccree: introduce CryptoCell HW driver

Hi Gilad, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7] [cannot apply to staging/staging-testing next-20170420] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: MMC block addressing mode.

On 04/20/2017 09:17 AM, Steven J. Hill wrote: On 04/20/2017 09:18 AM, Ulf Hansson wrote: The Cavium hardware requires knowledge of the card addressing mode. We need to either restore mmc_card_blockaddr(), or create another way to generate the same information. You previously suggested use of

Re: MMC block addressing mode.

On 04/20/2017 09:17 AM, Steven J. Hill wrote: On 04/20/2017 09:18 AM, Ulf Hansson wrote: The Cavium hardware requires knowledge of the card addressing mode. We need to either restore mmc_card_blockaddr(), or create another way to generate the same information. You previously suggested use of

Re: [GIT PULL 00/28] perf/core fixes and cleanups

Em Thu, Apr 20, 2017 at 01:29:26PM +0200, Ingo Molnar escreveu: > > * Arnaldo Carvalho de Melo wrote: > > > Em Thu, Apr 20, 2017 at 10:10:49AM +0200, Ingo Molnar escreveu: > > > * Arnaldo Carvalho de Melo wrote: > > > Pulled, thanks a lot Arnaldo! > > > > > >

Re: [PATCH v2] net: arc_emac: switch to phy_start()/phy_stop()

On 04/20/2017 06:29 AM, Alexander Kochetkov wrote: > Currently driver use phy_start_aneg() in arc_emac_open() to bring > up PHY. But phy_start() function is more appropriate for this purposes. > Besides that it call phy_start_aneg() as part of PHY startup sequence > it also can correctly bring up

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

On 04/20/2017 12:15 PM, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote: >>> This is getting ludicrous. Xen is plain broken, and instead of fixing >>> it, you propose to somehow deal with its obviously crack induced >>> behaviour :-( >> Totally agree and I

Re: [GIT PULL 00/28] perf/core fixes and cleanups

Em Thu, Apr 20, 2017 at 01:29:26PM +0200, Ingo Molnar escreveu: > > * Arnaldo Carvalho de Melo wrote: > > > Em Thu, Apr 20, 2017 at 10:10:49AM +0200, Ingo Molnar escreveu: > > > * Arnaldo Carvalho de Melo wrote: > > > Pulled, thanks a lot Arnaldo! > > > > > > > For this specific pull request

Re: [PATCH v2] net: arc_emac: switch to phy_start()/phy_stop()

On 04/20/2017 06:29 AM, Alexander Kochetkov wrote: > Currently driver use phy_start_aneg() in arc_emac_open() to bring > up PHY. But phy_start() function is more appropriate for this purposes. > Besides that it call phy_start_aneg() as part of PHY startup sequence > it also can correctly bring up

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

On 04/20/2017 12:15 PM, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote: >>> This is getting ludicrous. Xen is plain broken, and instead of fixing >>> it, you propose to somehow deal with its obviously crack induced >>> behaviour :-( >> Totally agree and I

Re: [PATCH v2 0/2] nvme APST quirk updates, take two

On 04/20/2017 11:06 AM, Andy Lutomirski wrote: > > > On Apr 20, 2017 9:38 AM, "Jens Axboe" > wrote: > > On 04/20/2017 10:30 AM, Jens Axboe wrote: > > On 04/20/2017 10:29 AM, Keith Busch wrote: > >> On Thu, Apr 20, 2017 at 07:15:15PM +0300,

Re: [PATCH v2 0/2] nvme APST quirk updates, take two

On 04/20/2017 11:06 AM, Andy Lutomirski wrote: > > > On Apr 20, 2017 9:38 AM, "Jens Axboe" > wrote: > > On 04/20/2017 10:30 AM, Jens Axboe wrote: > > On 04/20/2017 10:29 AM, Keith Busch wrote: > >> On Thu, Apr 20, 2017 at 07:15:15PM +0300, Sagi Grimberg

Re: [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v4)

On 03/29/2017 05:26 PM, Eric Anholt wrote: > Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for > now, so it's useful to be able to test that mode on an upstream > kernel. It's also been useful for me to use the same board for 32-bit > and 64-bit development. > >

Re: [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v4)

On 03/29/2017 05:26 PM, Eric Anholt wrote: > Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for > now, so it's useful to be able to test that mode on an upstream > kernel. It's also been useful for me to use the same board for 32-bit > and 64-bit development. > >

Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

On Tue, Apr 18, 2017 at 04:17:11PM -0500, Tom Lendacky wrote: > When System Memory Encryption (SME) is enabled, the physical address > space is reduced. Adjust the x86_phys_bits value to reflect this > reduction. > > Signed-off-by: Tom Lendacky > --- >

Re: [PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

On Tue, Apr 18, 2017 at 04:17:11PM -0500, Tom Lendacky wrote: > When System Memory Encryption (SME) is enabled, the physical address > space is reduced. Adjust the x86_phys_bits value to reflect this > reduction. > > Signed-off-by: Tom Lendacky > --- > arch/x86/kernel/cpu/amd.c | 14

Re: [PATCH v3] dcssblk: add dax_operations support

On Wed, 19 Apr 2017 15:32:38 -0700 Dan Williams wrote: > Setup a dax_dev to have the same lifetime as the dcssblk block device > and add a ->direct_access() method that is equivalent to > dcssblk_direct_access(). Once fs/dax.c has been converted to use > dax_operations

Re: [PATCH v3] dcssblk: add dax_operations support

On Wed, 19 Apr 2017 15:32:38 -0700 Dan Williams wrote: > Setup a dax_dev to have the same lifetime as the dcssblk block device > and add a ->direct_access() method that is equivalent to > dcssblk_direct_access(). Once fs/dax.c has been converted to use > dax_operations the old

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

On 20/04/17 16:06, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: >> In this patch I suggest we set __max_logical_packages based on the >> max_physical_pkg_id and total_cpus, > So my 4 socket 144 CPU system will then get max_physical_pkg_id=144, > instead

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

On 20/04/17 16:06, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: >> In this patch I suggest we set __max_logical_packages based on the >> max_physical_pkg_id and total_cpus, > So my 4 socket 144 CPU system will then get max_physical_pkg_id=144, > instead

[PATCH v3] soc: brcmstb: enable drivers for ARM64 and BMIPS

From: Markus Mayer We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64 and BMIPS. Signed-off-by: Markus Mayer --- Changes since v2: - It is not necessary to use (COMPILE_TEST && OF) Changes since v1: - Add BMIPS - Add

[PATCH v3] soc: brcmstb: enable drivers for ARM64 and BMIPS

From: Markus Mayer We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64 and BMIPS. Signed-off-by: Markus Mayer --- Changes since v2: - It is not necessary to use (COMPILE_TEST && OF) Changes since v1: - Add BMIPS - Add COMPILE_TEST drivers/soc/bcm/Kconfig | 2 +- 1

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/19/2017 09:43 PM, Frank Rowand wrote: >> Something else to keep in mind is that while pr_debugs could be used to >> provide feedback on the reference counts and of_reconfig events they >> don't in anyway tell us where they are happening in the kernel. The > > Yes, that is critical

Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle

On 04/19/2017 09:43 PM, Frank Rowand wrote: >> Something else to keep in mind is that while pr_debugs could be used to >> provide feedback on the reference counts and of_reconfig events they >> don't in anyway tell us where they are happening in the kernel. The > > Yes, that is critical

Re: [PATCH] checkpatch: add --typedefsfile

On Thu, 2017-04-20 at 17:39 +0200, Jerome Forissier wrote: > When using checkpatch on out-of-tree code, it may occur that some > project-specific types are used, which will cause spurious warnings. > Add the --typedefsfile option as a way to extend the known types and > deal with this issue. I'm

Re: [PATCH] checkpatch: add --typedefsfile

On Thu, 2017-04-20 at 17:39 +0200, Jerome Forissier wrote: > When using checkpatch on out-of-tree code, it may occur that some > project-specific types are used, which will cause spurious warnings. > Add the --typedefsfile option as a way to extend the known types and > deal with this issue. I'm

Re: kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds

On Thu, Apr 13, 2017 at 04:50:46PM +0100, Suzuki K. Poulose wrote: > On Thu, Apr 13, 2017 at 10:17:54AM +0100, Suzuki K Poulose wrote: > > On 12/04/17 19:43, Marc Zyngier wrote: > > > On 12/04/17 17:19, Andrey Konovalov wrote: > > > > > > Hi Andrey, > > > > > > > Apparently this wasn't fixed, I've

Re: kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds

On Thu, Apr 13, 2017 at 04:50:46PM +0100, Suzuki K. Poulose wrote: > On Thu, Apr 13, 2017 at 10:17:54AM +0100, Suzuki K Poulose wrote: > > On 12/04/17 19:43, Marc Zyngier wrote: > > > On 12/04/17 17:19, Andrey Konovalov wrote: > > > > > > Hi Andrey, > > > > > > > Apparently this wasn't fixed, I've

Re: [PATCH v2 0/2] nvme APST quirk updates, take two

On 04/20/2017 10:30 AM, Jens Axboe wrote: > On 04/20/2017 10:29 AM, Keith Busch wrote: >> On Thu, Apr 20, 2017 at 07:15:15PM +0300, Sagi Grimberg wrote: >>> > Hi Jens- > > These are just the quirk updates, split out. The patches are > unchanged. > > I think that, even if

Re: [PATCH v2 0/2] nvme APST quirk updates, take two

On 04/20/2017 10:30 AM, Jens Axboe wrote: > On 04/20/2017 10:29 AM, Keith Busch wrote: >> On Thu, Apr 20, 2017 at 07:15:15PM +0300, Sagi Grimberg wrote: >>> > Hi Jens- > > These are just the quirk updates, split out. The patches are > unchanged. > > I think that, even if

Re: [PATCH] drivers, md: convert stripe_head.count from atomic_t to refcount_t

On Thu, Apr 20, 2017 at 09:15:00AM +, Reshetova, Elena wrote: > Just a ping on this updated patch. Did you find any new issues or could you > please apply it? sorry, for the dalay. I'm in vacation. Since the stripe_head.count could be 0 (and it's not freed), I assume it should stay as

Re: [PATCH] drivers, md: convert stripe_head.count from atomic_t to refcount_t

On Thu, Apr 20, 2017 at 09:15:00AM +, Reshetova, Elena wrote: > Just a ping on this updated patch. Did you find any new issues or could you > please apply it? sorry, for the dalay. I'm in vacation. Since the stripe_head.count could be 0 (and it's not freed), I assume it should stay as

[PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

From: Haiyang Zhang This patch uses the lower 16 bits of the serial number as PCI domain, otherwise some drivers may not be able to handle it. Signed-off-by: Haiyang Zhang --- drivers/pci/host/pci-hyperv.c |4 +++- 1 files changed, 3

[PATCH] pci-hyperv: Use only 16 bit integer for PCI domain

From: Haiyang Zhang This patch uses the lower 16 bits of the serial number as PCI domain, otherwise some drivers may not be able to handle it. Signed-off-by: Haiyang Zhang --- drivers/pci/host/pci-hyperv.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git

Re: [PATCH] [media] sti: hdmi: improve MEDIA_CEC_NOTIFIER dependency

On Wed, Apr 19, 2017 at 11:06 PM, Hans Verkuil wrote: > On 19/04/17 18:59, Arnd Bergmann wrote: >> When the media subsystem is built as a loadable module, a built-in >> This adds a Kconfig dependency to enforce the HDMI driver to also >> be a loadable module in this case. > >

Re: [PATCH] [media] sti: hdmi: improve MEDIA_CEC_NOTIFIER dependency

On Wed, Apr 19, 2017 at 11:06 PM, Hans Verkuil wrote: > On 19/04/17 18:59, Arnd Bergmann wrote: >> When the media subsystem is built as a loadable module, a built-in >> This adds a Kconfig dependency to enforce the HDMI driver to also >> be a loadable module in this case. > > I've marked this

Re: [PATCH v3 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series

Hi Hans, v4 has been sent with "v4l2-compliance -s -f" report provided in cover letter. Bindings acked by Rob. http://www.mail-archive.com/linux-media@vger.kernel.org/msg111743.html BR, Hugues. On 04/10/2017 10:55 AM, Hans Verkuil wrote: > On 04/04/2017 05:44 PM, Hugues Fruchet wrote: >> This

Re: [PATCH v3 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series

Hi Hans, v4 has been sent with "v4l2-compliance -s -f" report provided in cover letter. Bindings acked by Rob. http://www.mail-archive.com/linux-media@vger.kernel.org/msg111743.html BR, Hugues. On 04/10/2017 10:55 AM, Hans Verkuil wrote: > On 04/04/2017 05:44 PM, Hugues Fruchet wrote: >> This

Re: [resend PATCH v2 11/33] dm: add dax_device and dax_operations support

On Mon, Apr 17, 2017 at 12:09 PM, Dan Williams wrote: > Allocate a dax_device to represent the capacity of a device-mapper > instance. Provide a ->direct_access() method via the new dax_operations > indirection that mirrors the functionality of the current direct_access

[PATCH v4 4/6] mtd: dataflash: Get rid of loop counter in jedec_probe()

"For" loop in jedec_probe can be simplified to not need counter 'i'. Convert the code and get rid of the variable. Cc: cphe...@gmail.com Cc: David Woodhouse Cc: Brian Norris Cc: Boris Brezillon Cc: Marek

Re: [resend PATCH v2 11/33] dm: add dax_device and dax_operations support

On Mon, Apr 17, 2017 at 12:09 PM, Dan Williams wrote: > Allocate a dax_device to represent the capacity of a device-mapper > instance. Provide a ->direct_access() method via the new dax_operations > indirection that mirrors the functionality of the current direct_access > support via

[PATCH v4 4/6] mtd: dataflash: Get rid of loop counter in jedec_probe()

"For" loop in jedec_probe can be simplified to not need counter 'i'. Convert the code and get rid of the variable. Cc: cphe...@gmail.com Cc: David Woodhouse Cc: Brian Norris Cc: Boris Brezillon Cc: Marek Vasut Cc: Richard Weinberger Cc: Cyrille Pitchen Cc: linux-kernel@vger.kernel.org

Re: [PATCH v2 0/2] nvme APST quirk updates, take two

On 04/20/2017 10:29 AM, Keith Busch wrote: > On Thu, Apr 20, 2017 at 07:15:15PM +0300, Sagi Grimberg wrote: >> Hi Jens- These are just the quirk updates, split out. The patches are unchanged. I think that, even if we want to apply a broader quirk for 4.11, we

Re: [PATCH v2 0/2] nvme APST quirk updates, take two

On 04/20/2017 10:29 AM, Keith Busch wrote: > On Thu, Apr 20, 2017 at 07:15:15PM +0300, Sagi Grimberg wrote: >> Hi Jens- These are just the quirk updates, split out. The patches are unchanged. I think that, even if we want to apply a broader quirk for 4.11, we

[PATCH v4 5/6] mtd: dataflash: Make use of "extened device information"

In anticipation of supporting chips that need it, extend the size of struct flash_info's 'jedec_id' field to make room 2 byte of extended device information as well as add code to fetch this data during jedec_probe(). Cc: cphe...@gmail.com Cc: David Woodhouse Cc: Brian

[PATCH v4 5/6] mtd: dataflash: Make use of "extened device information"

In anticipation of supporting chips that need it, extend the size of struct flash_info's 'jedec_id' field to make room 2 byte of extended device information as well as add code to fetch this data during jedec_probe(). Cc: cphe...@gmail.com Cc: David Woodhouse Cc: Brian Norris Cc: Boris

[PATCH v4 6/6] mtd: dataflash: Add flash_info for AT45DB641E

Cc: cphe...@gmail.com Cc: David Woodhouse Cc: Brian Norris Cc: Boris Brezillon Cc: Marek Vasut Cc: Richard Weinberger Cc: Cyrille Pitchen

[PATCH v4 6/6] mtd: dataflash: Add flash_info for AT45DB641E

Cc: cphe...@gmail.com Cc: David Woodhouse Cc: Brian Norris Cc: Boris Brezillon Cc: Marek Vasut Cc: Richard Weinberger Cc: Cyrille Pitchen Cc: linux-kernel@vger.kernel.org Signed-off-by: Andrey Smirnov --- Changes since [v3]: - Update the patch ot use SUP_EXTID No changes between

[PATCH v4 3/6] mtd: dataflash: Replace pr_debug, printk with dev_* functions

Lion's share of calls to pr_debug in this driver follow the pattern of pr_debug("%s ", dev_name(), ), which should be semantically identical to dev_dbg(, "", ), so replace such occurencies to simplify the code. Convert the small minority of pr_debug that do not follow pattern from above to use

[PATCH v4 2/6] mtd: dataflash: Improve coding style in jedec_probe()

Change the following: - Replace indentation between type and name of local variable from tabs to spaces - Replace magic number 0x1F with CFI_MFR_ATMEL macro - Replace variable 'tmp' with 'ret' and 'i' where appropriate - Reformat multi-line comments and add newlines where

[PATCH v4 3/6] mtd: dataflash: Replace pr_debug, printk with dev_* functions

Lion's share of calls to pr_debug in this driver follow the pattern of pr_debug("%s ", dev_name(), ), which should be semantically identical to dev_dbg(, "", ), so replace such occurencies to simplify the code. Convert the small minority of pr_debug that do not follow pattern from above to use

[PATCH v4 2/6] mtd: dataflash: Improve coding style in jedec_probe()

Change the following: - Replace indentation between type and name of local variable from tabs to spaces - Replace magic number 0x1F with CFI_MFR_ATMEL macro - Replace variable 'tmp' with 'ret' and 'i' where appropriate - Reformat multi-line comments and add newlines where

[PATCH v4 1/6] mtd: dataflash: Replace C99 types with their kernel counterparts

No functional change intended. Cc: cphe...@gmail.com Cc: David Woodhouse Cc: Brian Norris Cc: Boris Brezillon Cc: Marek Vasut Cc: Richard Weinberger Cc: Cyrille

[PATCH v4 1/6] mtd: dataflash: Replace C99 types with their kernel counterparts

No functional change intended. Cc: cphe...@gmail.com Cc: David Woodhouse Cc: Brian Norris Cc: Boris Brezillon Cc: Marek Vasut Cc: Richard Weinberger Cc: Cyrille Pitchen Cc: linux-kernel@vger.kernel.org Acked-by: Marek Vasut Signed-off-by: Andrey Smirnov --- No changes since [v3]

Re: [PATCH v2 1/3] mmc: dt-bindings: update Mediatek MMC bindings

On Tue, Apr 18, 2017 at 06:13:09PM +0800, Yong Mao wrote: > From: yong mao > > Add description for mediatek,clk-pad-delay > > Signed-off-by: Yong Mao > Signed-off-by: Chaotian Jing > --- >

Re: [PATCH v2 1/3] mmc: dt-bindings: update Mediatek MMC bindings

On Tue, Apr 18, 2017 at 06:13:09PM +0800, Yong Mao wrote: > From: yong mao > > Add description for mediatek,clk-pad-delay > > Signed-off-by: Yong Mao > Signed-off-by: Chaotian Jing > --- > Documentation/devicetree/bindings/mmc/mtk-sd.txt |2 ++ > 1 file changed, 2 insertions(+)

[PATCH v2 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

From: Sean Wang This patch adds support for hardware random generator on MT7623 SoC and should also work on other similar Mediatek SoCs. Currently, the driver is already tested successfully with rng-tools. Signed-off-by: Sean Wang Reviewed-by:

[PATCH v2 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

From: Sean Wang This patch adds support for hardware random generator on MT7623 SoC and should also work on other similar Mediatek SoCs. Currently, the driver is already tested successfully with rng-tools. Signed-off-by: Sean Wang Reviewed-by: PrasannaKumar Muralidharan ---

[PATCH v2 0/2] hwrng: mtk: add support for hardware random generator on MT7623 SoC

From: Sean Wang This patchset introduces support for Mediatek hardware random generator (RNG) Currently, the driver is already tested successfully with rng-tools on MT7623 SoC. And it should also be workable on other similar Mediatek SoCs. Changes since v1: - remove

[PATCH v2 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings

From: Sean Wang Document the devicetree bindings for Mediatek random number generator which could be found on MT7623 SoC or other similar Mediatek SoCs. Signed-off-by: Sean Wang Acked-by: Rob Herring ---

[PATCH v2 0/2] hwrng: mtk: add support for hardware random generator on MT7623 SoC

From: Sean Wang This patchset introduces support for Mediatek hardware random generator (RNG) Currently, the driver is already tested successfully with rng-tools on MT7623 SoC. And it should also be workable on other similar Mediatek SoCs. Changes since v1: - remove unnecessary warning message

[PATCH v2 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings

From: Sean Wang Document the devicetree bindings for Mediatek random number generator which could be found on MT7623 SoC or other similar Mediatek SoCs. Signed-off-by: Sean Wang Acked-by: Rob Herring --- Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++ 1 file

[PATCHv5 2/9] x86/boot/64: Rewrite startup_64 in C

The patch write most of startup_64 logic in C. This is preparation for 5-level paging enabling. Signed-off-by: Kirill A. Shutemov --- arch/x86/kernel/head64.c | 85 +- arch/x86/kernel/head_64.S | 95

[PATCHv5 2/9] x86/boot/64: Rewrite startup_64 in C

The patch write most of startup_64 logic in C. This is preparation for 5-level paging enabling. Signed-off-by: Kirill A. Shutemov --- arch/x86/kernel/head64.c | 85 +- arch/x86/kernel/head_64.S | 95 ++- 2

[PATCHv5 7/9] x86/mm: Add support for 5-level paging for KASLR

With 5-level paging randomization happens on P4D level instead of PUD. Maximum amount of physical memory also bumped to 52-bits for 5-level paging. Signed-off-by: Kirill A. Shutemov --- arch/x86/mm/kaslr.c | 81

[PATCHv5 7/9] x86/mm: Add support for 5-level paging for KASLR

With 5-level paging randomization happens on P4D level instead of PUD. Maximum amount of physical memory also bumped to 52-bits for 5-level paging. Signed-off-by: Kirill A. Shutemov --- arch/x86/mm/kaslr.c | 81 - 1 file changed, 62

[PATCHv5 0/9] x86: 5-level paging enabling for v4.12, Part 4

Here's updated version the fourth and the last bunch of of patches that brings initial 5-level paging enabling. Please review and consider applying. v5: - Fix KASLR bug due to rewriting rewriting startup_64() in C. Kirill A. Shutemov (9): x86/asm: Fix comment in return_from_SYSCALL_64

[PATCHv5 5/9] x86/mm: Add sync_global_pgds() for configuration with 5-level paging

This basically restores slightly modified version of original sync_global_pgds() which we had before folded p4d was introduced. The only modification is protection against 'address' overflow. Signed-off-by: Kirill A. Shutemov --- arch/x86/mm/init_64.c | 35

[PATCHv5 0/9] x86: 5-level paging enabling for v4.12, Part 4

Here's updated version the fourth and the last bunch of of patches that brings initial 5-level paging enabling. Please review and consider applying. v5: - Fix KASLR bug due to rewriting rewriting startup_64() in C. Kirill A. Shutemov (9): x86/asm: Fix comment in return_from_SYSCALL_64

[PATCHv5 5/9] x86/mm: Add sync_global_pgds() for configuration with 5-level paging

This basically restores slightly modified version of original sync_global_pgds() which we had before folded p4d was introduced. The only modification is protection against 'address' overflow. Signed-off-by: Kirill A. Shutemov --- arch/x86/mm/init_64.c | 35 +++

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