Re: [PATCH 3/4] can: m_can: Update documentation to mention new fixed transceiver binding

On Wed, Jul 19, 2017 at 06:36:53PM -0500, Franklin S Cooper Jr wrote: > Add information regarding fixed transceiver binding. This is especially > important for MCAN since the IP allows CAN FD mode to run significantly > faster than what most transceivers are capable of. > > Signed-off-by:

Re: [PATCH 3/4] can: m_can: Update documentation to mention new fixed transceiver binding

On Wed, Jul 19, 2017 at 06:36:53PM -0500, Franklin S Cooper Jr wrote: > Add information regarding fixed transceiver binding. This is especially > important for MCAN since the IP allows CAN FD mode to run significantly > faster than what most transceivers are capable of. > > Signed-off-by:

[RFC 2/5] doc: fpga: add sysfs document for fpga region

Document the firmware_name attribute added for each region. Signed-off-by: Alan Tull --- Documentation/ABI/testing/sysfs-class-fpga-region | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-region diff --git

[RFC 2/5] doc: fpga: add sysfs document for fpga region

Document the firmware_name attribute added for each region. Signed-off-by: Alan Tull --- Documentation/ABI/testing/sysfs-class-fpga-region | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-region diff --git

[RFC 3/5] fpga: add dev to fpga_image_info

This patch should be rolled into the next version of my "non-dt support for FPGA regions" patchset. Add a pointer to the device that owns the fpga_image_info to fpga_image_info. That way the fpga_image_info_free can drop the 'dev' parameter and we are left with: struct fpga_image_info

[RFC 3/5] fpga: add dev to fpga_image_info

This patch should be rolled into the next version of my "non-dt support for FPGA regions" patchset. Add a pointer to the device that owns the fpga_image_info to fpga_image_info. That way the fpga_image_info_free can drop the 'dev' parameter and we are left with: struct fpga_image_info

[RFC 5/5] fpga-region support for fdt headers on fpga images

Support a FDT header for FPGA images. Header format is a simplified FIT containing at most one FPGA image and one DT overlay. The FPGA image section includes FPGA image info properties needed for programming. If present, the DT overlay image is applied after the FPGA is programmed. Both images

[RFC 4/5] fpga-region: new function fpga_region_free

Add FPGA region API function fpga_region_free() that undoes some of what fpga_region_program_fpga() does to free up a region to be reprogrammed. Signed-off-by: Alan Tull --- drivers/fpga/fpga-region.c | 20 drivers/fpga/of-fpga-region.c| 5 +

[RFC 4/5] fpga-region: new function fpga_region_free

Add FPGA region API function fpga_region_free() that undoes some of what fpga_region_program_fpga() does to free up a region to be reprogrammed. Signed-off-by: Alan Tull --- drivers/fpga/fpga-region.c | 20 drivers/fpga/of-fpga-region.c| 5 +

[RFC 5/5] fpga-region support for fdt headers on fpga images

Support a FDT header for FPGA images. Header format is a simplified FIT containing at most one FPGA image and one DT overlay. The FPGA image section includes FPGA image info properties needed for programming. If present, the DT overlay image is applied after the FPGA is programmed. Both images

[RFC 1/5] doc: fpga: add document for the fdt FPGA header

Add a document for the open source fdt FPGA header. Signed-off-by: Alan Tull --- Documentation/fpga/fpga-header.txt | 103 + 1 file changed, 103 insertions(+) create mode 100644 Documentation/fpga/fpga-header.txt diff --git

[RFC 1/5] doc: fpga: add document for the fdt FPGA header

Add a document for the open source fdt FPGA header. Signed-off-by: Alan Tull --- Documentation/fpga/fpga-header.txt | 103 + 1 file changed, 103 insertions(+) create mode 100644 Documentation/fpga/fpga-header.txt diff --git

[RFC 0/5] Open source FPGA image header

This patch set adds open source FPGA image headers. This allows FPGA FPGA image specific information to be added to the images themselves. The header format is a simplified form of u-boot FIT images and can be expanded as real use cases are raised. As all the FPGA kernel frameworks are intended

[RFC 0/5] Open source FPGA image header

This patch set adds open source FPGA image headers. This allows FPGA FPGA image specific information to be added to the images themselves. The header format is a simplified form of u-boot FIT images and can be expanded as real use cases are raised. As all the FPGA kernel frameworks are intended

Re: [PATCH v1 07/13] xen/pvcalls: implement accept command

On 22/07/17 02:11, Stefano Stabellini wrote: > Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make > sure that only one accept command is executed at any given time by > setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on the > inflight_accept_req waitqueue. > >

Re: [PATCH v1 07/13] xen/pvcalls: implement accept command

On 22/07/17 02:11, Stefano Stabellini wrote: > Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make > sure that only one accept command is executed at any given time by > setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on the > inflight_accept_req waitqueue. > >

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

Yeah I noticed that, sorry if my response wasn't very clear! Should probably wait to have my morning coffee before responding to these messages :P On Mon, 2017-07-24 at 21:28 +0200, Jiri Kosina wrote: > On Mon, 24 Jul 2017, Lyude Paul wrote: > > > > > So, call hid_hw_open() in rmi_post_resume()

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

Yeah I noticed that, sorry if my response wasn't very clear! Should probably wait to have my morning coffee before responding to these messages :P On Mon, 2017-07-24 at 21:28 +0200, Jiri Kosina wrote: > On Mon, 24 Jul 2017, Lyude Paul wrote: > > > > > So, call hid_hw_open() in rmi_post_resume()

Re: [PATCH v1 06/13] xen/pvcalls: implement listen command

On 22/07/17 02:11, Stefano Stabellini wrote: > Send PVCALLS_LISTEN to the backend. > > Signed-off-by: Stefano Stabellini > CC: boris.ostrov...@oracle.com > CC: jgr...@suse.com > --- > drivers/xen/pvcalls-front.c | 49 > + >

Re: [PATCH v1 06/13] xen/pvcalls: implement listen command

On 22/07/17 02:11, Stefano Stabellini wrote: > Send PVCALLS_LISTEN to the backend. > > Signed-off-by: Stefano Stabellini > CC: boris.ostrov...@oracle.com > CC: jgr...@suse.com > --- > drivers/xen/pvcalls-front.c | 49 > + >

Re: [PATCH v1 05/13] xen/pvcalls: implement bind command

On 22/07/17 02:11, Stefano Stabellini wrote: > Send PVCALLS_BIND to the backend. Introduce a new structure, part of > struct sock_mapping, to store information specific to passive sockets. > > Introduce a status field to keep track of the status of the passive > socket. > > Introduce a waitqueue

Re: [PATCH v1 05/13] xen/pvcalls: implement bind command

On 22/07/17 02:11, Stefano Stabellini wrote: > Send PVCALLS_BIND to the backend. Introduce a new structure, part of > struct sock_mapping, to store information specific to passive sockets. > > Introduce a status field to keep track of the status of the passive > socket. > > Introduce a waitqueue

Re: [PATCH v1 04/13] xen/pvcalls: implement connect command

On 22/07/17 02:11, Stefano Stabellini wrote: > Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for > the active socket. > > Introduce a data structure to keep track of sockets. Introduce a > waitqueue to allow the frontend to wait on data coming from the backend > on the

Re: [PATCH v1 04/13] xen/pvcalls: implement connect command

On 22/07/17 02:11, Stefano Stabellini wrote: > Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for > the active socket. > > Introduce a data structure to keep track of sockets. Introduce a > waitqueue to allow the frontend to wait on data coming from the backend > on the

[PATCH v2] hwmon: (it87) Reapply probe path chip registers settings after resume

After a suspend / resume cycle we possibly need to reapply chip registers settings that we had set or fixed in a probe path, since they might have been reset to default values or set incorrectly by a BIOS again. Tested on a Gigabyte M720-US3 board, which requires routing internal VCCH5V to in7

[PATCH v2] hwmon: (it87) Reapply probe path chip registers settings after resume

After a suspend / resume cycle we possibly need to reapply chip registers settings that we had set or fixed in a probe path, since they might have been reset to default values or set incorrectly by a BIOS again. Tested on a Gigabyte M720-US3 board, which requires routing internal VCCH5V to in7

Re: [PATCH v3 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

On Mon, Jul 24, 2017 at 9:23 AM, Rob Herring wrote: > On Mon, Jul 24, 2017 at 08:09:15AM -0700, Andrey Smirnov wrote: >> Cc: cphe...@gmail.com >> Cc: Lucas Stach >> Cc: Nikita Yushchenko >> Cc: Rob Herring

Re: [PATCH v3 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

On Mon, Jul 24, 2017 at 9:23 AM, Rob Herring wrote: > On Mon, Jul 24, 2017 at 08:09:15AM -0700, Andrey Smirnov wrote: >> Cc: cphe...@gmail.com >> Cc: Lucas Stach >> Cc: Nikita Yushchenko >> Cc: Rob Herring >> Cc: Mark Rutland >> Cc: devicet...@vger.kernel.org >> Acked-for-MFD-by: Lee Jones

Re: [PATCH v1 03/13] xen/pvcalls: implement socket command and handle events

On 22/07/17 02:11, Stefano Stabellini wrote: > Send a PVCALLS_SOCKET command to the backend, use the masked > req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0 > and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array > ready for the response, and there cannot be

Re: [PATCH v1 03/13] xen/pvcalls: implement socket command and handle events

On 22/07/17 02:11, Stefano Stabellini wrote: > Send a PVCALLS_SOCKET command to the backend, use the masked > req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0 > and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array > ready for the response, and there cannot be

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

On Mon, 24 Jul 2017, Lyude Paul wrote: > > > So, call hid_hw_open() in rmi_post_resume() so we make sure that > > > the > > > device is alive before we try talking to it. > > > > > > This fixes RMI device suspend/resume over HID. > > > - int ret; > > > + int ret = 0; > > > > What's

Re: [PATCH] HID: rmi: Make sure the HID device is opened on resume

On Mon, 24 Jul 2017, Lyude Paul wrote: > > > So, call hid_hw_open() in rmi_post_resume() so we make sure that > > > the > > > device is alive before we try talking to it. > > > > > > This fixes RMI device suspend/resume over HID. > > > - int ret; > > > + int ret = 0; > > > > What's

Re: bcache with existing ext4 filesystem

Am 24.07.2017 um 20:57 schrieb Pavel Machek: Would it be feasible to run bcache (write-through) with existing ext4 filesystem? I have 400GB of data I'd rather not move, and SSD I could use for caching. Ok, SSD is connecte over USB2, but I guess it is still way faster then seeking harddrive on

Re: bcache with existing ext4 filesystem

Am 24.07.2017 um 20:57 schrieb Pavel Machek: Would it be feasible to run bcache (write-through) with existing ext4 filesystem? I have 400GB of data I'd rather not move, and SSD I could use for caching. Ok, SSD is connecte over USB2, but I guess it is still way faster then seeking harddrive on

Re: bcache with existing ext4 filesystem

On Mon, Jul 24, 2017 at 09:15:48PM +0200, Pavel Machek wrote: > > > > Am 24.07.2017 um 20:57 schrieb Pavel Machek: > > >Would it be feasible to run bcache (write-through) with existing ext4 > > >filesystem? > > > > > >I have 400GB of data I'd rather not move, and SSD I could use for > > >caching.

Re: bcache with existing ext4 filesystem

On Mon, Jul 24, 2017 at 09:15:48PM +0200, Pavel Machek wrote: > > > > Am 24.07.2017 um 20:57 schrieb Pavel Machek: > > >Would it be feasible to run bcache (write-through) with existing ext4 > > >filesystem? > > > > > >I have 400GB of data I'd rather not move, and SSD I could use for > > >caching.

Re: [PATCH v1 02/13] xen/pvcalls: connect to the backend

On 22/07/17 02:11, Stefano Stabellini wrote: > Implement the probe function for the pvcalls frontend. Read the > supported versions, max-page-order and function-calls nodes from > xenstore. > > Introduce a data structure named pvcalls_bedata. It contains pointers to > the command ring, the event

Re: [PATCH v1 02/13] xen/pvcalls: connect to the backend

On 22/07/17 02:11, Stefano Stabellini wrote: > Implement the probe function for the pvcalls frontend. Read the > supported versions, max-page-order and function-calls nodes from > xenstore. > > Introduce a data structure named pvcalls_bedata. It contains pointers to > the command ring, the event

Re: [PATCH 2/3] can: m_can: Update documentation to indicate that hclk may be optional

On Wed, Jul 19, 2017 at 06:09:25PM -0500, Franklin S Cooper Jr wrote: > Update the documentation to reflect that hclk is now an optional clock. > > Signed-off-by: Franklin S Cooper Jr > --- > Documentation/devicetree/bindings/net/can/m_can.txt | 3 ++- > 1 file changed, 2

Re: [PATCH 2/3] can: m_can: Update documentation to indicate that hclk may be optional

On Wed, Jul 19, 2017 at 06:09:25PM -0500, Franklin S Cooper Jr wrote: > Update the documentation to reflect that hclk is now an optional clock. > > Signed-off-by: Franklin S Cooper Jr > --- > Documentation/devicetree/bindings/net/can/m_can.txt | 3 ++- > 1 file changed, 2 insertions(+), 1

Re: [PATCH 2/7] memory: atmel-ebi: Simplify SMC config code

Hi Alexander, Le Mon, 24 Jul 2017 11:12:18 +0200, Alexander Dahl a écrit : > Hello Boris, > > while testing v4.13-rc2 on an at91sam9g20 baed platform I'm coming back > to this topic. Meanwhile the whole new SMC and NAND below EBI stuff is > in mainline, this TDF bug however

Re: [PATCH 2/7] memory: atmel-ebi: Simplify SMC config code

Hi Alexander, Le Mon, 24 Jul 2017 11:12:18 +0200, Alexander Dahl a écrit : > Hello Boris, > > while testing v4.13-rc2 on an at91sam9g20 baed platform I'm coming back > to this topic. Meanwhile the whole new SMC and NAND below EBI stuff is > in mainline, this TDF bug however is still in

Re: [PATCHv4 1/3] dt-bindings: input: add pwm-vibrator

On Fri 2017-07-14 12:01:49, Sebastian Reichel wrote: > Add DT binding document for PWM controlled vibrator devices. > > Signed-off-by: Sebastian Reichel Acked-by: Pavel Machek > index ..09145d18491d > --- /dev/null > +++

Re: [PATCHv4 1/3] dt-bindings: input: add pwm-vibrator

On Fri 2017-07-14 12:01:49, Sebastian Reichel wrote: > Add DT binding document for PWM controlled vibrator devices. > > Signed-off-by: Sebastian Reichel Acked-by: Pavel Machek > index ..09145d18491d > --- /dev/null > +++ b/Documentation/devicetree/bindings/input/pwm-vibrator.txt >

Re: [PATCH 07/11] mfd: Drop unnecessary static

Hi! > > > Drop static on a local variable, when the variable is initialized before > > > any possible use. Thus, the static has no benefit. Actually... it has possible other benefit -- saving stack space. I've used static for that purpose before. So ... careful with the automation. --

Re: [PATCH 3/3] ARM: dts: omap4-droid4: add soundcard

On Mon 2017-07-10 13:26:02, Mark Brown wrote: > On Fri, Jul 07, 2017 at 06:42:29PM +0200, Sebastian Reichel wrote: > > > + soundcard { > > + compatible = "simple-audio-card"; > > + simple-audio-card,name = "Droid 4 Audio"; > > New systems should be using the of-graph card

Re: [PATCH 07/11] mfd: Drop unnecessary static

Hi! > > > Drop static on a local variable, when the variable is initialized before > > > any possible use. Thus, the static has no benefit. Actually... it has possible other benefit -- saving stack space. I've used static for that purpose before. So ... careful with the automation. --

Re: [PATCH 3/3] ARM: dts: omap4-droid4: add soundcard

On Mon 2017-07-10 13:26:02, Mark Brown wrote: > On Fri, Jul 07, 2017 at 06:42:29PM +0200, Sebastian Reichel wrote: > > > + soundcard { > > + compatible = "simple-audio-card"; > > + simple-audio-card,name = "Droid 4 Audio"; > > New systems should be using the of-graph card

Re: [GIT PULL] MFD for v4.13

Hi! > > > > include/linux/mfd/madera/registers.h | 8832 > > > > > > > > > > So I've pulled everything but this, because honestly, that file looks > > > like utter garbage. > > > > > > Why are there all those _hundreds_ of odd defines for > > > > > >

Re: [GIT PULL] MFD for v4.13

Hi! > > > > include/linux/mfd/madera/registers.h | 8832 > > > > > > > > > > So I've pulled everything but this, because honestly, that file looks > > > like utter garbage. > > > > > > Why are there all those _hundreds_ of odd defines for > > > > > >

Re: [PATCH v4 2/5] dt-bindings: pwm-backlight: add PWM delay proprieties.

On Mon 2017-07-24 16:21:44, Daniel Thompson wrote: > On 21/07/17 11:48, Enric Balletbo i Serra wrote: > >Hardware needs a delay between setting an initial (non-zero) PWM and > >enabling the backlight using GPIO. The post-pwm-on-delay-ms specifies > >this delay in milli seconds. Hardware also needs

Re: [PATCH V2 2/9] dt-bindings: usb: bdc: Add Device Tree binding for Broadcom UDC driver

On Wed, Jul 19, 2017 at 03:11:41PM -0400, Al Cooper wrote: > Add Device Tree binding document for Broadcom USB Device > Controller (BDC). > > Signed-off-by: Al Cooper > --- > Documentation/devicetree/bindings/usb/brcm,bdc.txt | 29 > ++ > 1 file

Re: [PATCH v4 2/5] dt-bindings: pwm-backlight: add PWM delay proprieties.

On Mon 2017-07-24 16:21:44, Daniel Thompson wrote: > On 21/07/17 11:48, Enric Balletbo i Serra wrote: > >Hardware needs a delay between setting an initial (non-zero) PWM and > >enabling the backlight using GPIO. The post-pwm-on-delay-ms specifies > >this delay in milli seconds. Hardware also needs

Re: [PATCH V2 2/9] dt-bindings: usb: bdc: Add Device Tree binding for Broadcom UDC driver

On Wed, Jul 19, 2017 at 03:11:41PM -0400, Al Cooper wrote: > Add Device Tree binding document for Broadcom USB Device > Controller (BDC). > > Signed-off-by: Al Cooper > --- > Documentation/devicetree/bindings/usb/brcm,bdc.txt | 29 > ++ > 1 file changed, 29 insertions(+) >

Re: [PATCH v2 12/25] dt-bindings: qcom_nandc: QPIC NAND documentation

On Wed, Jul 19, 2017 at 05:18:00PM +0530, Abhishek Sahu wrote: > 1. QPIC NAND will use compatible string "qcom,qpic-nandc-v1.4.0" > 2. QPIC NAND will 3 BAM channels: command, data tx and data rx >while EBI2 NAND uses only single ADM channel. > 3. CRCI is only required for ADM DMA and its not

Re: [PATCH v2 12/25] dt-bindings: qcom_nandc: QPIC NAND documentation

On Wed, Jul 19, 2017 at 05:18:00PM +0530, Abhishek Sahu wrote: > 1. QPIC NAND will use compatible string "qcom,qpic-nandc-v1.4.0" > 2. QPIC NAND will 3 BAM channels: command, data tx and data rx >while EBI2 NAND uses only single ADM channel. > 3. CRCI is only required for ADM DMA and its not

Re: bcache with existing ext4 filesystem

On Mon 2017-07-24 21:08:16, Reindl Harald wrote: > > > Am 24.07.2017 um 20:57 schrieb Pavel Machek: > >Would it be feasible to run bcache (write-through) with existing ext4 > >filesystem? > > > >I have 400GB of data I'd rather not move, and SSD I could use for > >caching. Ok, SSD is connecte

Re: bcache with existing ext4 filesystem

On Mon 2017-07-24 21:08:16, Reindl Harald wrote: > > > Am 24.07.2017 um 20:57 schrieb Pavel Machek: > >Would it be feasible to run bcache (write-through) with existing ext4 > >filesystem? > > > >I have 400GB of data I'd rather not move, and SSD I could use for > >caching. Ok, SSD is connecte

Re: [PATCH] cgroup: remove unnecessary empty check when enabling threaded mode

On 07/23/2017 08:18 AM, Tejun Heo wrote: > cgroup_enable_threaded() checks that the cgroup doesn't have any tasks > or children and fails the operation if so. This test is unnecessary > because the first part is already checked by > cgroup_can_be_thread_root() and the latter is unnecessary. The

Re: [PATCH] cgroup: remove unnecessary empty check when enabling threaded mode

On 07/23/2017 08:18 AM, Tejun Heo wrote: > cgroup_enable_threaded() checks that the cgroup doesn't have any tasks > or children and fails the operation if so. This test is unnecessary > because the first part is already checked by > cgroup_can_be_thread_root() and the latter is unnecessary. The

Re: [PATCH v2 04/25] dt-bindings: qcom_nandc: change compatible string for EBI2 NANDC

On Wed, Jul 19, 2017 at 05:17:52PM +0530, Abhishek Sahu wrote: > The current compatible string “qcom,ipq806x-nand" implies that > the driver is specific to IPQ806x. This driver can be used by > any chip which uses EBI2 NAND controller so changed the > compatible string to “qcom,ebi2-nandc” to give

Re: [PATCH v2 04/25] dt-bindings: qcom_nandc: change compatible string for EBI2 NANDC

On Wed, Jul 19, 2017 at 05:17:52PM +0530, Abhishek Sahu wrote: > The current compatible string “qcom,ipq806x-nand" implies that > the driver is specific to IPQ806x. This driver can be used by > any chip which uses EBI2 NAND controller so changed the > compatible string to “qcom,ebi2-nandc” to give

Re: [PATCH v2 06/25] dt-bindings: qcom_nandc: remove chip select compatible string

On Wed, Jul 19, 2017 at 05:17:54PM +0530, Abhishek Sahu wrote: > Currently the compatible “qcom,nandcs” is being used for each > connected NAND device to support for multiple NAND devices in the > same bus. The same thing can be achieved by looking reg property > for each sub nodes which contains

Re: [PATCH v2 06/25] dt-bindings: qcom_nandc: remove chip select compatible string

On Wed, Jul 19, 2017 at 05:17:54PM +0530, Abhishek Sahu wrote: > Currently the compatible “qcom,nandcs” is being used for each > connected NAND device to support for multiple NAND devices in the > same bus. The same thing can be achieved by looking reg property > for each sub nodes which contains

[RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

From: Tom Lendacky Secure Encrypted Virtualization (SEV) does not support string I/O, so unroll the string I/O operation into a loop operating on one element at a time. Signed-off-by: Tom Lendacky Signed-off-by: Brijesh Singh

[RFC Part1 PATCH v3 13/17] x86/io: Unroll string I/O when SEV is active

From: Tom Lendacky Secure Encrypted Virtualization (SEV) does not support string I/O, so unroll the string I/O operation into a loop operating on one element at a time. Signed-off-by: Tom Lendacky Signed-off-by: Brijesh Singh --- arch/x86/include/asm/io.h | 26 ++ 1

[RFC Part1 PATCH v3 14/17] x86/boot: Add early boot support when running with SEV active

From: Tom Lendacky Early in the boot process, add checks to determine if the kernel is running with Secure Encrypted Virtualization (SEV) active. Checking for SEV requires checking that the kernel is running under a hypervisor (CPUID 0x0001, bit 31), that the SEV

[RFC Part1 PATCH v3 14/17] x86/boot: Add early boot support when running with SEV active

From: Tom Lendacky Early in the boot process, add checks to determine if the kernel is running with Secure Encrypted Virtualization (SEV) active. Checking for SEV requires checking that the kernel is running under a hypervisor (CPUID 0x0001, bit 31), that the SEV feature is available (CPUID

[RFC Part1 PATCH v3 15/17] x86: Add support for changing memory encryption attribute in early boot

Some KVM-specific custom MSRs shares the guest physical address with hypervisor. When SEV is active, the shared physical address must be mapped with encryption attribute cleared so that both hypervsior and guest can access the data. Add APIs to change memory encryption attribute in early boot

[RFC Part1 PATCH v3 15/17] x86: Add support for changing memory encryption attribute in early boot

Some KVM-specific custom MSRs shares the guest physical address with hypervisor. When SEV is active, the shared physical address must be mapped with encryption attribute cleared so that both hypervsior and guest can access the data. Add APIs to change memory encryption attribute in early boot

[RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU variable at compile time and share its physical address with hypervisor. It presents a challege when SEV is active in guest OS, when SEV is active, the guest memory is encrypted with guest key hence hypervisor will not able

[RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables

Some KVM specific MSR's (steal-time, asyncpf, avic_eio) allocates per-CPU variable at compile time and share its physical address with hypervisor. It presents a challege when SEV is active in guest OS, when SEV is active, the guest memory is encrypted with guest key hence hypervisor will not able

[RFC Part1 PATCH v3 17/17] X86/KVM: Clear encryption attribute when SEV is active

The guest physical memory area holding the struct pvclock_wall_clock and struct pvclock_vcpu_time_info are shared with the hypervisor. Hypervisor periodically updates the contents of the memory. When SEV is active, we must clear the encryption attributes from the shared memory pages so that both

[RFC Part1 PATCH v3 17/17] X86/KVM: Clear encryption attribute when SEV is active

The guest physical memory area holding the struct pvclock_wall_clock and struct pvclock_vcpu_time_info are shared with the hypervisor. Hypervisor periodically updates the contents of the memory. When SEV is active, we must clear the encryption attributes from the shared memory pages so that both

[GIT PULL 3/5] arm64: dts: exynos: Updates for v4.14

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.14 for you to fetch changes up to

[GIT PULL 3/5] arm64: dts: exynos: Updates for v4.14

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.14 for you to fetch changes up to

[GIT PULL 4/5] ARM: defconfig: Exynos updates for v4.14

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.14 for you to fetch changes up to

[GIT PULL 4/5] ARM: defconfig: Exynos updates for v4.14

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.14 for you to fetch changes up to

Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Add support for qcom,gpios-disallowed property

On Wed, Jul 19, 2017 at 03:17:07PM +0800, fengl...@codeaurora.org wrote: > From: Fenglin Wu > > Add support for qcom,gpios-disallowed property which is used to exclude > PMIC GPIOs not owned by the APSS processor from the pinctrl device. > > Signed-off-by: Fenglin Wu

[GIT PULL 5/5] ARM: defconfig: Cleanups for v4.14

Hi, Non-Samsung cleanups for defconfigs Best regards, Krzysztof The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git

Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Add support for qcom,gpios-disallowed property

On Wed, Jul 19, 2017 at 03:17:07PM +0800, fengl...@codeaurora.org wrote: > From: Fenglin Wu > > Add support for qcom,gpios-disallowed property which is used to exclude > PMIC GPIOs not owned by the APSS processor from the pinctrl device. > > Signed-off-by: Fenglin Wu > --- >

[GIT PULL 5/5] ARM: defconfig: Cleanups for v4.14

Hi, Non-Samsung cleanups for defconfigs Best regards, Krzysztof The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git

[RFC Part1 PATCH v3 12/17] x86/mm: DMA support for SEV memory encryption

From: Tom Lendacky DMA access to memory mapped as encrypted while SEV is active can not be encrypted during device write or decrypted during device read. In order for DMA to properly work when SEV is active, the SWIOTLB bounce buffers must be used. Signed-off-by: Tom

[RFC Part1 PATCH v3 11/17] x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages

From: Tom Lendacky In order for memory pages to be properly mapped when SEV is active, we need to use the PAGE_KERNEL protection attribute as the base protection. This will insure that memory mapping of, e.g. ACPI tables, receives the proper mapping attributes.

Re: Simplfying copy_siginfo_to_user

Linus Torvalds writes: > On Sat, Jul 22, 2017 at 1:25 PM, Eric W. Biederman > wrote: >> I played with some clever changes such as limiting the copy to 48 bytes, >> disabling the memset and the like but I could not get a strong enough >>

[RFC Part1 PATCH v3 11/17] x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages

From: Tom Lendacky In order for memory pages to be properly mapped when SEV is active, we need to use the PAGE_KERNEL protection attribute as the base protection. This will insure that memory mapping of, e.g. ACPI tables, receives the proper mapping attributes. Signed-off-by: Tom Lendacky

Re: Simplfying copy_siginfo_to_user

Linus Torvalds writes: > On Sat, Jul 22, 2017 at 1:25 PM, Eric W. Biederman > wrote: >> I played with some clever changes such as limiting the copy to 48 bytes, >> disabling the memset and the like but I could not get a strong enough >> signal to say that any one change removed the extra or a

[RFC Part1 PATCH v3 12/17] x86/mm: DMA support for SEV memory encryption

From: Tom Lendacky DMA access to memory mapped as encrypted while SEV is active can not be encrypted during device write or decrypted during device read. In order for DMA to properly work when SEV is active, the SWIOTLB bounce buffers must be used. Signed-off-by: Tom Lendacky Signed-off-by:

[GIT PULL 2/5] ARM: dts: exynos: Updates for v4.14

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.14 for you to fetch changes up to

[RFC Part1 PATCH v3 10/17] resource: Provide resource struct in resource walk callback

From: Tom Lendacky In prep for a new function that will need additional resource information during the resource walk, update the resource walk callback to pass the resource structure. Since the current callback start and end arguments are pulled from the resource

[GIT PULL 2/5] ARM: dts: exynos: Updates for v4.14

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.14 for you to fetch changes up to

[RFC Part1 PATCH v3 10/17] resource: Provide resource struct in resource walk callback

From: Tom Lendacky In prep for a new function that will need additional resource information during the resource walk, update the resource walk callback to pass the resource structure. Since the current callback start and end arguments are pulled from the resource structure, the callback

[GIT PULL 1/5] ARM: s3c24xx: Early stuff for v4.14

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.14 for you to fetch changes up to

[RFC Part1 PATCH v3 09/17] resource: Consolidate resource walking code

From: Tom Lendacky The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range() functions each have much of the same code. Create a new function that consolidates the common code from these functions in one place to reduce the amount of duplicated code.

[GIT PULL 1/5] ARM: s3c24xx: Early stuff for v4.14

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.14 for you to fetch changes up to

[RFC Part1 PATCH v3 09/17] resource: Consolidate resource walking code

From: Tom Lendacky The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range() functions each have much of the same code. Create a new function that consolidates the common code from these functions in one place to reduce the amount of duplicated code. Signed-off-by: Tom

[RFC Part1 PATCH v3 05/17] x86, realmode: Don't decrypt trampoline area under SEV

From: Tom Lendacky When SEV is active the trampoline area will need to be in encrypted memory so only mark the area decrypted if SME is active. Signed-off-by: Tom Lendacky Signed-off-by: Brijesh Singh ---

[RFC Part1 PATCH v3 05/17] x86, realmode: Don't decrypt trampoline area under SEV

From: Tom Lendacky When SEV is active the trampoline area will need to be in encrypted memory so only mark the area decrypted if SME is active. Signed-off-by: Tom Lendacky Signed-off-by: Brijesh Singh --- arch/x86/realmode/init.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)

[RFC Part1 PATCH v3 06/17] x86/mm: Use encrypted access of boot related data with SEV

From: Tom Lendacky When Secure Encrypted Virtualization (SEV) is active, boot data (such as EFI related data, setup data) is encrypted and needs to be accessed as such when mapped. Update the architecture override in early_memremap to keep the encryption attribute when

[RFC Part1 PATCH v3 06/17] x86/mm: Use encrypted access of boot related data with SEV

From: Tom Lendacky When Secure Encrypted Virtualization (SEV) is active, boot data (such as EFI related data, setup data) is encrypted and needs to be accessed as such when mapped. Update the architecture override in early_memremap to keep the encryption attribute when mapping this data.

<    4   5   6   7   8   9   10   11   12   13   >