Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

On Wed, Aug 16, 2017 at 4:14 PM, Laura Abbott wrote: > From: Daniel Micay > > > Existing Android bootloaders usually pass data useful as early entropy > on the kernel command-line. It may also be the case on other embedded > systems. Sample command-line

Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

On Wed, Aug 16, 2017 at 4:14 PM, Laura Abbott wrote: > From: Daniel Micay > > > Existing Android bootloaders usually pass data useful as early entropy > on the kernel command-line. It may also be the case on other embedded > systems. Sample command-line from a Google Pixel running CopperheadOS:

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

Linus Torvalds writes: > On Tue, Aug 15, 2017 at 3:57 PM, Linus Torvalds > wrote: >> >> Oh, and the page wait-queue really needs that key argument too, which >> is another thing that swait queue code got rid of in the name of >>

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

Linus Torvalds writes: > On Tue, Aug 15, 2017 at 3:57 PM, Linus Torvalds > wrote: >> >> Oh, and the page wait-queue really needs that key argument too, which >> is another thing that swait queue code got rid of in the name of >> simplicity. > > Actually, it gets worse. > > Because the page wait

Re: linux-next: Signed-off-by missing for commit in the drivers-x86 tree

+Olof and Arnd, I am curious how you handle the situation below as a maintainer team. This problem arose from a new for-next test which triggers on the committer not having a SOB tag in the patch (which can happen when a shared branch is rebased to drop a patch). Do you have a branch that you

Re: linux-next: Signed-off-by missing for commit in the drivers-x86 tree

+Olof and Arnd, I am curious how you handle the situation below as a maintainer team. This problem arose from a new for-next test which triggers on the committer not having a SOB tag in the patch (which can happen when a shared branch is rebased to drop a patch). Do you have a branch that you

refactoring timers to avoid init_timer*()

Hi, So, my earlier patch[1] to add canaries to the timer struct did not handle many many cases, as I've uncovered. To have a sensible canary, it needs to be written at function-assignment time, but right now things are extremely ad-hoc in the timer API, making it non-trivial to figure out if the

refactoring timers to avoid init_timer*()

Hi, So, my earlier patch[1] to add canaries to the timer struct did not handle many many cases, as I've uncovered. To have a sensible canary, it needs to be written at function-assignment time, but right now things are extremely ad-hoc in the timer API, making it non-trivial to figure out if the

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

On 08/16/2017 12:21 PM, Bart Van Assche wrote: > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote: >> As of next-20170809, linux-next on powerpc boot hung with below trace >> message. >> >> [ ... ] >> >> A bisection resulted in first bad commit (270065e92 - scsi: scsi-mq: >> Always unprepare

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

On 08/16/2017 12:21 PM, Bart Van Assche wrote: > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote: >> As of next-20170809, linux-next on powerpc boot hung with below trace >> message. >> >> [ ... ] >> >> A bisection resulted in first bad commit (270065e92 - scsi: scsi-mq: >> Always unprepare

[PATCHv3 2/2] extract early boot entropy from the passed cmdline

From: Daniel Micay Existing Android bootloaders usually pass data useful as early entropy on the kernel command-line. It may also be the case on other embedded systems. Sample command-line from a Google Pixel running CopperheadOS: console=ttyHSL0,115200,n8

[PATCHv3 0/2] Command line randomness

Hi, This is v3 of the series to add the kernel command line as a source of randomness. The main change from v2 is to correctly place the command line randomness _before_ the stack canary initialization so the canary can take advantage of that. Daniel Micay (1): extract early boot entropy from

[PATCHv3 1/2] init: Move stack canary initialization after setup_arch

From: Laura Abbott Stack canary intialization involves getting a random number. Getting this random number may involve accessing caches or other architectural specific features which are not available until after the architecture is setup. Move the stack canary

[PATCHv3 0/2] Command line randomness

Hi, This is v3 of the series to add the kernel command line as a source of randomness. The main change from v2 is to correctly place the command line randomness _before_ the stack canary initialization so the canary can take advantage of that. Daniel Micay (1): extract early boot entropy from

[PATCHv3 1/2] init: Move stack canary initialization after setup_arch

From: Laura Abbott Stack canary intialization involves getting a random number. Getting this random number may involve accessing caches or other architectural specific features which are not available until after the architecture is setup. Move the stack canary initialization later to

[PATCHv3 2/2] extract early boot entropy from the passed cmdline

From: Daniel Micay Existing Android bootloaders usually pass data useful as early entropy on the kernel command-line. It may also be the case on other embedded systems. Sample command-line from a Google Pixel running CopperheadOS: console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0

Re: [RFC][PATCH 2/2] selftests: timers: freq-step: Fix build warning

On Wed, Aug 16, 2017 at 4:01 PM, Shuah Khan wrote: > Hi John, > > On 08/15/2017 06:11 AM, Miroslav Lichvar wrote: >> On Mon, Aug 14, 2017 at 02:01:36PM -0700, John Stultz wrote: >>> Fixes the following build warning: >>> freq-step.c: In function ‘main’: >>>

Re: [RFC][PATCH 2/2] selftests: timers: freq-step: Fix build warning

On Wed, Aug 16, 2017 at 4:01 PM, Shuah Khan wrote: > Hi John, > > On 08/15/2017 06:11 AM, Miroslav Lichvar wrote: >> On Mon, Aug 14, 2017 at 02:01:36PM -0700, John Stultz wrote: >>> Fixes the following build warning: >>> freq-step.c: In function ‘main’: >>> freq-step.c:271:1: warning: control

Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures

Michael Ellerman [m...@ellerman.id.au] wrote: > Sukadev Bhattiprolu writes: > > > Nicholas Piggin [npig...@gmail.com] wrote: > >> On Mon, 14 Aug 2017 15:21:48 +1000 > >> Michael Ellerman wrote: > >> > >> > Sukadev Bhattiprolu

Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures

Michael Ellerman [m...@ellerman.id.au] wrote: > Sukadev Bhattiprolu writes: > > > Nicholas Piggin [npig...@gmail.com] wrote: > >> On Mon, 14 Aug 2017 15:21:48 +1000 > >> Michael Ellerman wrote: > >> > >> > Sukadev Bhattiprolu writes: > >> > >> > > arch/powerpc/include/asm/vas.h | 35

Re: [PATCH v2 1/1] rtc: rtctest: Improve support detection

On 08/15/2017 02:46 AM, Lukáš Doktor wrote: > The rtc-generic and opal-rtc are failing to run this test as they do not > support all the features. Let's treat the error returns and skip to the > following test. > > Theoretically the test_DATE should be also adjusted, but as it's enabled > on

Re: [PATCH v2 1/1] rtc: rtctest: Improve support detection

On 08/15/2017 02:46 AM, Lukáš Doktor wrote: > The rtc-generic and opal-rtc are failing to run this test as they do not > support all the features. Let's treat the error returns and skip to the > following test. > > Theoretically the test_DATE should be also adjusted, but as it's enabled > on

Re: [RFC][PATCH 2/2] selftests: timers: freq-step: Fix build warning

Hi John, On 08/15/2017 06:11 AM, Miroslav Lichvar wrote: > On Mon, Aug 14, 2017 at 02:01:36PM -0700, John Stultz wrote: >> Fixes the following build warning: >> freq-step.c: In function ‘main’: >> freq-step.c:271:1: warning: control reaches end of non-void function >> [-Wreturn-type] > >> @@

Re: [RFC][PATCH 2/2] selftests: timers: freq-step: Fix build warning

Hi John, On 08/15/2017 06:11 AM, Miroslav Lichvar wrote: > On Mon, Aug 14, 2017 at 02:01:36PM -0700, John Stultz wrote: >> Fixes the following build warning: >> freq-step.c: In function ‘main’: >> freq-step.c:271:1: warning: control reaches end of non-void function >> [-Wreturn-type] > >> @@

Re: [PATCH v2 1/2] kbuild: Also evaluate alternative option passed to cc-option, etc

El Thu, Aug 17, 2017 at 12:03:05AM +0900 Masahiro Yamada ha dit: > Hi Matthias, > > > 2017-08-15 10:29 GMT+09:00 Matthias Kaehlcke : > > The macro cc-option receives two parameters (the second may be empty). It > > returns the first parameter if it is a valid compiler option,

Re: [PATCH v2 1/2] kbuild: Also evaluate alternative option passed to cc-option, etc

El Thu, Aug 17, 2017 at 12:03:05AM +0900 Masahiro Yamada ha dit: > Hi Matthias, > > > 2017-08-15 10:29 GMT+09:00 Matthias Kaehlcke : > > The macro cc-option receives two parameters (the second may be empty). It > > returns the first parameter if it is a valid compiler option, otherwise > > the

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 16, 2017 at 3:46 PM, Eric W. Biederman wrote: >> tty->link->driver_data = pts_path; >> >> retval = ptm_driver->ops->open(tty, filp); > ^^^ > > If this open fails the code jumps to err_put_path which falls > through into out_put_fsi. No

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 16, 2017 at 3:46 PM, Eric W. Biederman wrote: >> tty->link->driver_data = pts_path; >> >> retval = ptm_driver->ops->open(tty, filp); > ^^^ > > If this open fails the code jumps to err_put_path which falls > through into out_put_fsi. No it doesn't.

Re: [PATCH] ARM: dts: TI: Enable __symbols__ in dtb files for some platforms

On 08/16/17 15:33, Frank Rowand wrote: > On 08/16/17 14:59, Tom Rini wrote: >> Build the dtb file for these platfroms with __symbol__ information >> included. This will reduce the size of the dtb (and resident memory > > typo: reduce the size should be increase the size > > >> usage) in

Re: [PATCH] ARM: dts: TI: Enable __symbols__ in dtb files for some platforms

On 08/16/17 15:33, Frank Rowand wrote: > On 08/16/17 14:59, Tom Rini wrote: >> Build the dtb file for these platfroms with __symbol__ information >> included. This will reduce the size of the dtb (and resident memory > > typo: reduce the size should be increase the size > > >> usage) in

Re: [PATCH v2 1/3] ASoC: rockchip: Parse dai links from dts

hi matthias, thanks for your suggestion. On 08/17/2017 05:59 AM, Matthias Kaehlcke wrote: El Thu, Aug 10, 2017 at 12:54:56PM +0800 Jeffy Chen ha dit: >Refactor rockchip_sound_probe, parse dai links from dts instead of >hard coding them. Mark doesn't seem to be overly convinced that

Re: [PATCH v2 1/3] ASoC: rockchip: Parse dai links from dts

hi matthias, thanks for your suggestion. On 08/17/2017 05:59 AM, Matthias Kaehlcke wrote: El Thu, Aug 10, 2017 at 12:54:56PM +0800 Jeffy Chen ha dit: >Refactor rockchip_sound_probe, parse dai links from dts instead of >hard coding them. Mark doesn't seem to be overly convinced that

Re: [PATCHv2 2/2] extract early boot entropy from the passed cmdline

On 08/16/2017 03:48 PM, Kees Cook wrote: > On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott wrote: >> From: Daniel Micay >> >> Existing Android bootloaders usually pass data useful as early entropy >> on the kernel command-line. It may also be the case on

Re: [PATCHv2 2/2] extract early boot entropy from the passed cmdline

On 08/16/2017 03:48 PM, Kees Cook wrote: > On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott wrote: >> From: Daniel Micay >> >> Existing Android bootloaders usually pass data useful as early entropy >> on the kernel command-line. It may also be the case on other embedded >> systems. Sample

Re: [PATCHv2 1/2] init: Move stack canary initialization after setup_arch

On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott wrote: > From: Laura Abbott > > Stack canary intialization involves getting a random number. > Getting this random number may involve accessing caches or other > architectural specific features which are not

Re: [PATCHv2 1/2] init: Move stack canary initialization after setup_arch

On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott wrote: > From: Laura Abbott > > Stack canary intialization involves getting a random number. > Getting this random number may involve accessing caches or other > architectural specific features which are not available until > after the architecture

Re: [PATCHv2 2/2] extract early boot entropy from the passed cmdline

On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott wrote: > From: Daniel Micay > > Existing Android bootloaders usually pass data useful as early entropy > on the kernel command-line. It may also be the case on other embedded > systems. Sample command-line

Re: [PATCHv2 2/2] extract early boot entropy from the passed cmdline

On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott wrote: > From: Daniel Micay > > Existing Android bootloaders usually pass data useful as early entropy > on the kernel command-line. It may also be the case on other embedded > systems. Sample command-line from a Google Pixel running CopperheadOS: >

[PATCHv2 2/2] extract early boot entropy from the passed cmdline

From: Daniel Micay Existing Android bootloaders usually pass data useful as early entropy on the kernel command-line. It may also be the case on other embedded systems. Sample command-line from a Google Pixel running CopperheadOS: console=ttyHSL0,115200,n8

[PATCHv2 2/2] extract early boot entropy from the passed cmdline

From: Daniel Micay Existing Android bootloaders usually pass data useful as early entropy on the kernel command-line. It may also be the case on other embedded systems. Sample command-line from a Google Pixel running CopperheadOS: console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

Linus Torvalds writes: > On Wed, Aug 16, 2017 at 1:30 PM, Linus Torvalds > wrote: >> >> I suspect the easiest fix is to just add a "mnt" argument to >> devpts_acquire(), It shouldn't be too painful. Let me try. > > Ok, here's a

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

Linus Torvalds writes: > On Wed, Aug 16, 2017 at 1:30 PM, Linus Torvalds > wrote: >> >> I suspect the easiest fix is to just add a "mnt" argument to >> devpts_acquire(), It shouldn't be too painful. Let me try. > > Ok, here's a *very* lightly tested patch. It might have new bugs, but > it

[PATCHv2 1/2] init: Move stack canary initialization after setup_arch

From: Laura Abbott Stack canary intialization involves getting a random number. Getting this random number may involve accessing caches or other architectural specific features which are not available until after the architecture is setup. Move the stack canary

[PATCHv2 1/2] init: Move stack canary initialization after setup_arch

From: Laura Abbott Stack canary intialization involves getting a random number. Getting this random number may involve accessing caches or other architectural specific features which are not available until after the architecture is setup. Move the stack canary initialization later to accomodate

[PATCHv2 0/2] Command line randomness

Hi, This is a series to add the kernel command line as a source of randomness. The first patch is an (old) prepatory patch from me to move the stack canary initialization later. The second patch is from Daniel Micay to actually add the command line to the pool. Kees suggested this go through

[PATCHv2 0/2] Command line randomness

Hi, This is a series to add the kernel command line as a source of randomness. The first patch is an (old) prepatory patch from me to move the stack canary initialization later. The second patch is from Daniel Micay to actually add the command line to the pool. Kees suggested this go through

RE: [PATCH net-next 1/3] VMCI: only load on VMware hypervisor

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > > Without the patch, vmw_vsock_vmci_transport.ko and vmw_vmci.ko can > > automatically load when an application creates an AF_VSOCK socket. > > > > This is the expected good behavior on VMware hypervisor, but as we > > are going to add

RE: [PATCH net-next 1/3] VMCI: only load on VMware hypervisor

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > > Without the patch, vmw_vsock_vmci_transport.ko and vmw_vmci.ko can > > automatically load when an application creates an AF_VSOCK socket. > > > > This is the expected good behavior on VMware hypervisor, but as we > > are going to add

Re: [PATCH] ARM: dts: TI: Enable __symbols__ in dtb files for some platforms

On 08/16/17 14:59, Tom Rini wrote: > Build the dtb file for these platfroms with __symbol__ information > included. This will reduce the size of the dtb (and resident memory typo: reduce the size should be increase the size > usage) in exchange for allowing more types of overlays to be applied

Re: [PATCH] ARM: dts: TI: Enable __symbols__ in dtb files for some platforms

On 08/16/17 14:59, Tom Rini wrote: > Build the dtb file for these platfroms with __symbol__ information > included. This will reduce the size of the dtb (and resident memory typo: reduce the size should be increase the size > usage) in exchange for allowing more types of overlays to be applied

Re: [PATCH] kvm: x86: disable KVM_FAST_MMIO_BUS

On Wed, Aug 16, 2017 at 11:25:35PM +0200, Paolo Bonzini wrote: > On 16/08/2017 21:59, Michael S. Tsirkin wrote: > > On Wed, Aug 16, 2017 at 09:03:17PM +0200, Radim Krčmář wrote: > >> 2017-08-16 19:19+0200, Paolo Bonzini: > >>> On 16/08/2017 18:50, Michael S. Tsirkin wrote: > On Wed, Aug 16,

Re: [PATCH] kvm: x86: disable KVM_FAST_MMIO_BUS

On Wed, Aug 16, 2017 at 11:25:35PM +0200, Paolo Bonzini wrote: > On 16/08/2017 21:59, Michael S. Tsirkin wrote: > > On Wed, Aug 16, 2017 at 09:03:17PM +0200, Radim Krčmář wrote: > >> 2017-08-16 19:19+0200, Paolo Bonzini: > >>> On 16/08/2017 18:50, Michael S. Tsirkin wrote: > On Wed, Aug 16,

[PATCH v2 3/3] arm64: compat: Add CONFIG_KUSER_HELPERS

From: Kevin Brodsky Make it possible to disable the kuser helpers by adding a KUSER_HELPERS config option (enabled by default). When disabled, all kuser helpers-related code is removed from the kernel and no mapping is done at the fixed high address (0x); any

[PATCH v2 3/3] arm64: compat: Add CONFIG_KUSER_HELPERS

From: Kevin Brodsky Make it possible to disable the kuser helpers by adding a KUSER_HELPERS config option (enabled by default). When disabled, all kuser helpers-related code is removed from the kernel and no mapping is done at the fixed high address (0x); any attempt to use a kuser

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 16, 2017 at 11:45 PM, Linus Torvalds wrote: > On Wed, Aug 16, 2017 at 2:37 PM, Christian Brauner > wrote: >>> And Christian, if you can beat on this, that would be good. >> >> Yes, I can pound on this nicely with liblxc.

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 16, 2017 at 11:45 PM, Linus Torvalds wrote: > On Wed, Aug 16, 2017 at 2:37 PM, Christian Brauner > wrote: >>> And Christian, if you can beat on this, that would be good. >> >> Yes, I can pound on this nicely with liblxc. We have patch >> ( https://github.com/lxc/lxc/pull/1728 ) up

[PATCH v2 2/3] arm64: compat: Split the sigreturn trampolines and kuser helpers (assembler sources)

From: Kevin Brodsky AArch32 processes are currently installed a special [vectors] page that contains the sigreturn trampolines and the kuser helpers, at the fixed address mandated by the kuser helpers ABI. Having both functionalities in the same page has become

[PATCH v2 2/3] arm64: compat: Split the sigreturn trampolines and kuser helpers (assembler sources)

From: Kevin Brodsky AArch32 processes are currently installed a special [vectors] page that contains the sigreturn trampolines and the kuser helpers, at the fixed address mandated by the kuser helpers ABI. Having both functionalities in the same page has become problematic, because: * It makes

[PATCH v2 1/3] arm64: compat: Split the sigreturn trampolines and kuser helpers (C sources)

From: Kevin Brodsky AArch32 processes are currently installed a special [vectors] page that contains the sigreturn trampolines and the kuser helpers, at the fixed address mandated by the kuser helpers ABI. Having both functionalities in the same page has become

[PATCH v2 1/3] arm64: compat: Split the sigreturn trampolines and kuser helpers (C sources)

From: Kevin Brodsky AArch32 processes are currently installed a special [vectors] page that contains the sigreturn trampolines and the kuser helpers, at the fixed address mandated by the kuser helpers ABI. Having both functionalities in the same page has become problematic, because: * It makes

[PATCH v5 4/4] perf, tools: Add test cases for new data source encoding

From: Andi Kleen Add some simple tests to perf test to test data source printing. v2: Make the tests actually checked for the correct name of Forward v3: Adjust to new encoding Signed-off-by: Andi Kleen --- tools/perf/tests/Build | 1 +

[PATCH v5 4/4] perf, tools: Add test cases for new data source encoding

From: Andi Kleen Add some simple tests to perf test to test data source printing. v2: Make the tests actually checked for the correct name of Forward v3: Adjust to new encoding Signed-off-by: Andi Kleen --- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4

Fix Skylake PEBS data source for perf v5

Fix data source reporting for Skylake and Skylake Server. The encodings have changed to express support for L4 and persistent memory. The first patch is a (independent) cleanup. The second is for the kernel and the third/fourth for perf/tools. The kernel part and perf tools will compile

[PATCH v5 1/4] perf/x86: Move Nehalem PEBS code to flag

From: Andi Kleen Minor cleanup: use an explicit x86_pmu flag to handle the missing Lock / TLB information on Nehalem, instead of always checking the model number for each PEBS sample. Signed-off-by: Andi Kleen --- arch/x86/events/intel/core.c | 1 +

Fix Skylake PEBS data source for perf v5

Fix data source reporting for Skylake and Skylake Server. The encodings have changed to express support for L4 and persistent memory. The first patch is a (independent) cleanup. The second is for the kernel and the third/fourth for perf/tools. The kernel part and perf tools will compile

[PATCH v5 1/4] perf/x86: Move Nehalem PEBS code to flag

From: Andi Kleen Minor cleanup: use an explicit x86_pmu flag to handle the missing Lock / TLB information on Nehalem, instead of always checking the model number for each PEBS sample. Signed-off-by: Andi Kleen --- arch/x86/events/intel/core.c | 1 + arch/x86/events/intel/ds.c | 5 +

[PATCH v5 2/4] perf/x86: Fix data source decoding for Skylake

From: Andi Kleen Skylake changed the encoding of the PEBS data source field. Some combinations are not available anymore, but some new cases e.g. for L4 cache hit are added. Fix up the conversion table for Skylake, similar as had been done for Nehalem. On Skylake server

[PATCH v5 3/4] perf, tools: Add support for printing new mem_info encodings

From: Andi Kleen Add decoding for the new lvlx and snoopx field meminfo field added earlier to the kernel so that "perf mem report" and other tools can print it properly. v2: Merge with persistent memory patch. Switch to new bit encoding for each combination. v3: Switch to

[PATCH v5 2/4] perf/x86: Fix data source decoding for Skylake

From: Andi Kleen Skylake changed the encoding of the PEBS data source field. Some combinations are not available anymore, but some new cases e.g. for L4 cache hit are added. Fix up the conversion table for Skylake, similar as had been done for Nehalem. On Skylake server the encoding for L4

[PATCH v5 3/4] perf, tools: Add support for printing new mem_info encodings

From: Andi Kleen Add decoding for the new lvlx and snoopx field meminfo field added earlier to the kernel so that "perf mem report" and other tools can print it properly. v2: Merge with persistent memory patch. Switch to new bit encoding for each combination. v3: Switch to generic lvlnum field.

Re: [PATCH 2/9] Implement containers as kernel objects

On Mon, Aug 14, 2017 at 1:47 AM, Richard Guy Briggs wrote: > Hi David, > > I wanted to respond to this thread to attempt some constructive feedback, > better late than never. I had a look at your fsopen/fsmount() patchset(s) to > support this patchset which was interesting, but

Re: [PATCH 2/9] Implement containers as kernel objects

On Mon, Aug 14, 2017 at 1:47 AM, Richard Guy Briggs wrote: > Hi David, > > I wanted to respond to this thread to attempt some constructive feedback, > better late than never. I had a look at your fsopen/fsmount() patchset(s) to > support this patchset which was interesting, but doesn't directly

Re: [PATCH 2/2] iommu/tegra-gart: Add support for struct iommu_device

Hello Joerg, On 10.08.2017 01:29, Joerg Roedel wrote: > From: Joerg Roedel > > Add a struct iommu_device to each tegra-gart and register it > with the iommu-core. Also link devices added to the driver > to their respective hardware iommus. > > Signed-off-by: Joerg Roedel

Re: [PATCH 2/2] iommu/tegra-gart: Add support for struct iommu_device

Hello Joerg, On 10.08.2017 01:29, Joerg Roedel wrote: > From: Joerg Roedel > > Add a struct iommu_device to each tegra-gart and register it > with the iommu-core. Also link devices added to the driver > to their respective hardware iommus. > > Signed-off-by: Joerg Roedel > --- >

[PATCH v2 0/3] ARM: dts: keystone-k2g: Add I2C support for 66AK2G

Add I2C support to 66AK2G. Primary requirement is to add PM Runtime support to the driver. This has been tested on following platforms by performing simple i2c test such as i2c detect and reading on board i2c devices: K2G GP evm OMAPL138 K2L GP EVM and boot tested on: K2E GP EVM K2HK GP EVM

[PATCH v2 0/3] ARM: dts: keystone-k2g: Add I2C support for 66AK2G

Add I2C support to 66AK2G. Primary requirement is to add PM Runtime support to the driver. This has been tested on following platforms by performing simple i2c test such as i2c detect and reading on board i2c devices: K2G GP evm OMAPL138 K2L GP EVM and boot tested on: K2E GP EVM K2HK GP EVM

[PATCH v2 2/3] i2c: davinci: Add PM Runtime Support

66AK2G has I2C instances that are not apart of the ALWAYS_ON power domain like other Keystone 2 SoCs and OMAPL138. Therefore, pm_runtime is required to insure the power domain used by the specific I2C instance is properly turned on along with its functional clock. Signed-off-by: Franklin S Cooper

[PATCH v2 2/3] i2c: davinci: Add PM Runtime Support

66AK2G has I2C instances that are not apart of the ALWAYS_ON power domain like other Keystone 2 SoCs and OMAPL138. Therefore, pm_runtime is required to insure the power domain used by the specific I2C instance is properly turned on along with its functional clock. Signed-off-by: Franklin S Cooper

[PATCH v2 3/3] dt-bindings: i2c: i2c-davinci: Update binding for 66AK2Gx pwr dm property

Add pm-domains property which is required for 66AK2Gx. Also document 66AK2G unique clocks property usage. Signed-off-by: Franklin S Cooper Jr Acked-by: Rob Herring --- Documentation/devicetree/bindings/i2c/i2c-davinci.txt | 12 1 file changed, 12

[PATCH v2 3/3] dt-bindings: i2c: i2c-davinci: Update binding for 66AK2Gx pwr dm property

Add pm-domains property which is required for 66AK2Gx. Also document 66AK2G unique clocks property usage. Signed-off-by: Franklin S Cooper Jr Acked-by: Rob Herring --- Documentation/devicetree/bindings/i2c/i2c-davinci.txt | 12 1 file changed, 12 insertions(+) diff --git

[PATCH v2 1/3] i2c: davinci: Preserve return value of devm_clk_get

The i2c driver can run into driver dependency issues if its loaded before a clock driver it depends on. Therefore, EPROBE_DEFER may be returned by devm_clk_get and should be returned in probe to allow the kernel to reprobe the driver at a later time. This patch allows the error value returned by

[PATCH v2 1/3] i2c: davinci: Preserve return value of devm_clk_get

The i2c driver can run into driver dependency issues if its loaded before a clock driver it depends on. Therefore, EPROBE_DEFER may be returned by devm_clk_get and should be returned in probe to allow the kernel to reprobe the driver at a later time. This patch allows the error value returned by

Re: [PATCH] x86/boot/64: clang: use fixup_pointer() to access next_early_pgt

On Wed, Aug 16, 2017 at 09:08:08PM +0200, Alexander Potapenko wrote: > __startup_64() is normally using fixup_pointer() to access globals in a > position-independent fashion. However |next_early_pgt| was accessed > directly, which wasn't guaranteed to work. > > Luckily GCC was generating a

Re: [PATCH] x86/boot/64: clang: use fixup_pointer() to access next_early_pgt

On Wed, Aug 16, 2017 at 09:08:08PM +0200, Alexander Potapenko wrote: > __startup_64() is normally using fixup_pointer() to access globals in a > position-independent fashion. However |next_early_pgt| was accessed > directly, which wasn't guaranteed to work. > > Luckily GCC was generating a

[GIT PULL] SCSI fixes for 4.13-rc4

A couple of minor fixes (st, ses) and some bigger driver fixes for qla2xxx (crash triggered by fw dump) and ipr (lockdep problems with mq). The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes The short changelog is: Bodo Stroesser (1):

[GIT PULL] SCSI fixes for 4.13-rc4

A couple of minor fixes (st, ses) and some bigger driver fixes for qla2xxx (crash triggered by fw dump) and ipr (lockdep problems with mq). The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes The short changelog is: Bodo Stroesser (1):

Re: [PATCH v3 00/22] staging: ccree: fixes and simplifications

On Tue, Aug 15, 2017 at 09:26:28AM +0300, Gilad Ben-Yossef wrote: > The series includes various bug fixes, code simplification and style > cleanups. > > Changer from v2: > - Drop M32R as supported architecture, which resolve the kbuild bot > warnings on Joe Perches patch. > - Bug fix that

Re: [PATCH v3 00/22] staging: ccree: fixes and simplifications

On Tue, Aug 15, 2017 at 09:26:28AM +0300, Gilad Ben-Yossef wrote: > The series includes various bug fixes, code simplification and style > cleanups. > > Changer from v2: > - Drop M32R as supported architecture, which resolve the kbuild bot > warnings on Joe Perches patch. > - Bug fix that

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

On Mon, Jul 31, 2017 at 02:47:23PM +0530, RishabhHardas wrote: > From: RishabhHardas > > Sparse was giving out a warning for symbols 'cc_set_ree_fips_status' and > 'fips_handler' > that they were not declared and need to be made static. This patch makes both > the

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

On Mon, Jul 31, 2017 at 02:47:23PM +0530, RishabhHardas wrote: > From: RishabhHardas > > Sparse was giving out a warning for symbols 'cc_set_ree_fips_status' and > 'fips_handler' > that they were not declared and need to be made static. This patch makes both > the symbols > static inline, to

Re: [PATCH v3 11/22] staging: ccree: fix line indentation and breaks

On Tue, Aug 15, 2017 at 09:26:39AM +0300, Gilad Ben-Yossef wrote: > Fix wrong indentation and line breaks, including missing tabs, > breaking lines longer then 80 char or wrongly broken. > > Signed-off-by: Gilad Ben-Yossef > --- > drivers/staging/ccree/ssi_driver.c | 107 >

Re: [PATCH v3 11/22] staging: ccree: fix line indentation and breaks

On Tue, Aug 15, 2017 at 09:26:39AM +0300, Gilad Ben-Yossef wrote: > Fix wrong indentation and line breaks, including missing tabs, > breaking lines longer then 80 char or wrongly broken. > > Signed-off-by: Gilad Ben-Yossef > --- > drivers/staging/ccree/ssi_driver.c | 107 >

Re: [PATCH 2/2] KVM: SVM: Enable Virtual GIF feature

- Original Message - > From: "Janakarajan Natarajan" > To: "Radim Krcmar" > Cc: k...@vger.kernel.org, x...@kernel.org, linux-kernel@vger.kernel.org, > "Paolo Bonzini" , "Joerg > Roedel" , "Andy

Re: [PATCH 2/2] KVM: SVM: Enable Virtual GIF feature

- Original Message - > From: "Janakarajan Natarajan" > To: "Radim Krcmar" > Cc: k...@vger.kernel.org, x...@kernel.org, linux-kernel@vger.kernel.org, > "Paolo Bonzini" , "Joerg > Roedel" , "Andy Lutomirski" , "Tony Luck" > , "Borislav Petkov" > , "Thomas Gleixner" , "Ingo Molnar" > ,

[PATCH] mm/vmalloc: Don't unconditonally use __GFP_HIGHMEM

Commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly") added use of __GFP_HIGHMEM for allocations. vmalloc_32 may use GFP_DMA/GFP_DMA32 which does not play nice with __GFP_HIGHMEM and will drigger a BUG in gfp_zone. Only add __GFP_HIGHMEM if we aren't using GFP_DMA/GFP_DMA32. Bugzilla:

[PATCH] mm/vmalloc: Don't unconditonally use __GFP_HIGHMEM

Commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly") added use of __GFP_HIGHMEM for allocations. vmalloc_32 may use GFP_DMA/GFP_DMA32 which does not play nice with __GFP_HIGHMEM and will drigger a BUG in gfp_zone. Only add __GFP_HIGHMEM if we aren't using GFP_DMA/GFP_DMA32. Bugzilla:

[PULL] Please pull Skylake server JSON events

Hi Arnaldo, Please pull the skylake server JSON events. I'm not posting them because they are fairly large and boring. This requires the two preparation patches I posted earlier (actually only the first of them) -Andi The following changes since commit

[PULL] Please pull Skylake server JSON events

Hi Arnaldo, Please pull the skylake server JSON events. I'm not posting them because they are fairly large and boring. This requires the two preparation patches I posted earlier (actually only the first of them) -Andi The following changes since commit

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 16, 2017 at 11:55 PM, Linus Torvalds wrote: > On Wed, Aug 16, 2017 at 2:45 PM, Linus Torvalds > wrote: >> >> But it would be good to just test this in general too, and make sure I >> didn't screw up some reference count or

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 16, 2017 at 11:55 PM, Linus Torvalds wrote: > On Wed, Aug 16, 2017 at 2:45 PM, Linus Torvalds > wrote: >> >> But it would be good to just test this in general too, and make sure I >> didn't screw up some reference count or something. The patch *looks* >> obviously correct, but ... >

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