[PATCH v8 01/15] platform/x86: wmi: Add new method wmidev_evaluate_method

Drivers properly using the wmibus can pass their wmi_device pointer rather than the GUID back to the WMI bus to evaluate the proper methods. Any "new" drivers added that use the WMI bus should use this rather than the old wmi_evaluate_method that would take the GUID. Signed-off-by: Mario

[PATCH v8 01/15] platform/x86: wmi: Add new method wmidev_evaluate_method

Drivers properly using the wmibus can pass their wmi_device pointer rather than the GUID back to the WMI bus to evaluate the proper methods. Any "new" drivers added that use the WMI bus should use this rather than the old wmi_evaluate_method that would take the GUID. Signed-off-by: Mario

[PATCH v8 04/15] platform/x86: dell-wmi: allow 32k return size in the descriptor

Some platforms this year will be adopting 32k WMI buffer, so don't complain when encountering those. Signed-off-by: Mario Limonciello --- drivers/platform/x86/dell-wmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v8 06/15] platform/x86: wmi: Don't allow drivers to get each other's GUIDs

The only driver using this was dell-wmi, and it really was a hack. The driver was getting a data attribute from another driver and this type of action should not be encouraged. Rather drivers that need to interact with one another should pass data back and forth via exported functions.

[PATCH v8 04/15] platform/x86: dell-wmi: allow 32k return size in the descriptor

Some platforms this year will be adopting 32k WMI buffer, so don't complain when encountering those. Signed-off-by: Mario Limonciello --- drivers/platform/x86/dell-wmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/dell-wmi.c

[PATCH v8 06/15] platform/x86: wmi: Don't allow drivers to get each other's GUIDs

The only driver using this was dell-wmi, and it really was a hack. The driver was getting a data attribute from another driver and this type of action should not be encouraged. Rather drivers that need to interact with one another should pass data back and forth via exported functions.

[PATCH v8 05/15] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver

All communication on individual GUIDs should occur in separate drivers. Allowing a driver to communicate with the bus to another GUID is just a hack that discourages drivers to adopt the bus model. The information found from the WMI descriptor driver is now exported for use by other drivers.

[PATCH v8 05/15] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver

All communication on individual GUIDs should occur in separate drivers. Allowing a driver to communicate with the bus to another GUID is just a hack that discourages drivers to adopt the bus model. The information found from the WMI descriptor driver is now exported for use by other drivers.

[PATCH v8 15/15] platform/x86: dell-smbios-wmi: introduce userspace interface

It's important for the driver to provide a R/W ioctl to ensure that two competing userspace processes don't race to provide or read each others data. This userspace character device will be used to perform SMBIOS calls from any applications. It provides an ioctl that will allow passing the WMI

[PATCH v8 15/15] platform/x86: dell-smbios-wmi: introduce userspace interface

It's important for the driver to provide a R/W ioctl to ensure that two competing userspace processes don't race to provide or read each others data. This userspace character device will be used to perform SMBIOS calls from any applications. It provides an ioctl that will allow passing the WMI

[PATCH v8 11/15] platform/x86: dell-smbios-smm: test for WSMT

WSMT is as an attestation to the OS that the platform won't modify memory outside of pre-defined areas. If a platform has WSMT enabled in BIOS setup, SMM calls through dcdbas will fail. The only way to access platform data in these instances is through the WMI SMBIOS calling interface.

[PATCH v8 09/15] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

This splits up the dell-smbios driver into two drivers: * dell-smbios * dell-smbios-smm dell-smbios can operate with multiple different dispatcher drivers to perform SMBIOS operations. Also modify the interface that dell-laptop and dell-wmi use align to this model more closely. Rather than a

[PATCH v8 07/15] platform/x86: dell-smbios: only run if proper oem string is detected

The proper way to indicate that a system is a 'supported' Dell System is by the presence of this string in OEM strings. Allowing the driver to load on non-Dell systems will have undefined results. Signed-off-by: Mario Limonciello ---

[PATCH v8 11/15] platform/x86: dell-smbios-smm: test for WSMT

WSMT is as an attestation to the OS that the platform won't modify memory outside of pre-defined areas. If a platform has WSMT enabled in BIOS setup, SMM calls through dcdbas will fail. The only way to access platform data in these instances is through the WMI SMBIOS calling interface.

[PATCH v8 09/15] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

This splits up the dell-smbios driver into two drivers: * dell-smbios * dell-smbios-smm dell-smbios can operate with multiple different dispatcher drivers to perform SMBIOS operations. Also modify the interface that dell-laptop and dell-wmi use align to this model more closely. Rather than a

[PATCH v8 07/15] platform/x86: dell-smbios: only run if proper oem string is detected

The proper way to indicate that a system is a 'supported' Dell System is by the presence of this string in OEM strings. Allowing the driver to load on non-Dell systems will have undefined results. Signed-off-by: Mario Limonciello --- drivers/platform/x86/dell-smbios.c | 7 +++ 1 file

[PATCH v8 08/15] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens

Currently userspace tools can access system tokens via the dcdbas kernel module and a SMI call that will cause the platform to execute SMM code. With a goal in mind of deprecating the dcdbas kernel module a different method for accessing these tokens from userspace needs to be created. This is

[PATCH v8 08/15] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens

Currently userspace tools can access system tokens via the dcdbas kernel module and a SMI call that will cause the platform to execute SMM code. With a goal in mind of deprecating the dcdbas kernel module a different method for accessing these tokens from userspace needs to be created. This is

[PATCH v8 03/15] platform/x86: dell-wmi: clean up wmi descriptor check

Some cases the wrong type was used for errors and checks can be done more cleanly. Signed-off-by: Mario Limonciello Reviewed-by: Edward O'Callaghan Suggested-by: Andy Shevchenko --- drivers/platform/x86/dell-wmi.c |

[PATCH v8 03/15] platform/x86: dell-wmi: clean up wmi descriptor check

Some cases the wrong type was used for errors and checks can be done more cleanly. Signed-off-by: Mario Limonciello Reviewed-by: Edward O'Callaghan Suggested-by: Andy Shevchenko --- drivers/platform/x86/dell-wmi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH v8 10/15] platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver

The dell-smbios stack only currently uses an SMI interface which grants direct access to physical memory to the firmware SMM methods via a pointer. This dispatcher driver adds a WMI-ACPI interface that is detected by WMI probe and preferred over the SMI interface in dell-smbios. Changing this to

[PATCH v8 10/15] platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver

The dell-smbios stack only currently uses an SMI interface which grants direct access to physical memory to the firmware SMM methods via a pointer. This dispatcher driver adds a WMI-ACPI interface that is detected by WMI probe and preferred over the SMI interface in dell-smbios. Changing this to

[PATCH v8 14/15] platform/x86: wmi: create userspace interface for drivers

For WMI operations that are only Set or Query read or write sysfs attributes created by WMI vendor drivers make sense. For other WMI operations that are run on Method, there needs to be a way to guarantee to userspace that the results from the method call belong to the data request to the method

[PATCH v8 13/15] platform/x86: wmi: Add sysfs attribute for required_buffer_size

Method type WMI objects need to be able to describe the size of the interface that they will expect to use. Export this information to sysfs and allow vendor drivers to set it. Signed-off-by: Mario Limonciello --- drivers/platform/x86/wmi.c | 31

[PATCH v8 12/15] platform/x86: dell-smbios: Add filtering support

When a userspace interface is introduced to dell-smbios filtering support will be used to make sure that userspace doesn't make calls deemed unsafe or that can cause the kernel drivers to get out of sync. A blacklist is provided for the following: - Items that are in use by other kernel drivers -

[PATCH v8 14/15] platform/x86: wmi: create userspace interface for drivers

For WMI operations that are only Set or Query read or write sysfs attributes created by WMI vendor drivers make sense. For other WMI operations that are run on Method, there needs to be a way to guarantee to userspace that the results from the method call belong to the data request to the method

[PATCH v8 13/15] platform/x86: wmi: Add sysfs attribute for required_buffer_size

Method type WMI objects need to be able to describe the size of the interface that they will expect to use. Export this information to sysfs and allow vendor drivers to set it. Signed-off-by: Mario Limonciello --- drivers/platform/x86/wmi.c | 31 +++

[PATCH v8 12/15] platform/x86: dell-smbios: Add filtering support

When a userspace interface is introduced to dell-smbios filtering support will be used to make sure that userspace doesn't make calls deemed unsafe or that can cause the kernel drivers to get out of sync. A blacklist is provided for the following: - Items that are in use by other kernel drivers -

[PATCH v8 00/15] Introduce support for Dell SMBIOS over WMI

The existing way that the dell-smbios helper module and associated other drivers (dell-laptop, dell-wmi) communicate with the platform really isn't secure. It requires creating a buffer in physical DMA32 memory space and passing that to the platform via SMM. Since the platform got a physical

[PATCH v8 00/15] Introduce support for Dell SMBIOS over WMI

The existing way that the dell-smbios helper module and associated other drivers (dell-laptop, dell-wmi) communicate with the platform really isn't secure. It requires creating a buffer in physical DMA32 memory space and passing that to the platform via SMM. Since the platform got a physical

[PATCH v8 02/15] platform/x86: dell-wmi: increase severity of some failures

There is a lot of error checking in place for the format of the WMI descriptor buffer, but some of the potentially raised issues should be considered critical failures. If the buffer size or header don't match, this is a good indication that the buffer format changed in a way that the rest of the

[PATCH v8 02/15] platform/x86: dell-wmi: increase severity of some failures

There is a lot of error checking in place for the format of the WMI descriptor buffer, but some of the potentially raised issues should be considered critical failures. If the buffer size or header don't match, this is a good indication that the buffer format changed in a way that the rest of the

Re: 4.13 regression: get_kctl_0dB_offset doesn't handle all possible callbacks

Hi, On Oct 14 2017 07:46, PaX Team wrote: > what KERNEXEC on i386 does is that it executes kernel code in its own 0-based > code segment hence the 'low' code addresses. due to the current logic that > checks for SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK in get_kctl_0dB_offset, this > callback address is

Re: 4.13 regression: get_kctl_0dB_offset doesn't handle all possible callbacks

Hi, On Oct 14 2017 07:46, PaX Team wrote: > what KERNEXEC on i386 does is that it executes kernel code in its own 0-based > code segment hence the 'low' code addresses. due to the current logic that > checks for SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK in get_kctl_0dB_offset, this > callback address is

Re: [PATCH V9 0/7] blk-mq-sched: improve sequential I/O performance

On Fri, Oct 13, 2017 at 02:23:07PM -0600, Jens Axboe wrote: > On 10/13/2017 01:21 PM, Jens Axboe wrote: > > On 10/13/2017 01:08 PM, Jens Axboe wrote: > >> On 10/13/2017 12:05 PM, Ming Lei wrote: > >>> Hi Jens, > >>> > >>> In Red Hat internal storage test wrt. blk-mq scheduler, we found that I/O >

Re: [PATCH V9 0/7] blk-mq-sched: improve sequential I/O performance

On Fri, Oct 13, 2017 at 02:23:07PM -0600, Jens Axboe wrote: > On 10/13/2017 01:21 PM, Jens Axboe wrote: > > On 10/13/2017 01:08 PM, Jens Axboe wrote: > >> On 10/13/2017 12:05 PM, Ming Lei wrote: > >>> Hi Jens, > >>> > >>> In Red Hat internal storage test wrt. blk-mq scheduler, we found that I/O >

Re: [PATCH v3] hwmon: xgene: Support hwmon v2

Hi On Fri, Oct 13, 2017 at 9:54 PM, Guenter Roeck wrote: > On 10/13/2017 09:38 PM, Hoan Tran wrote: >> >> Hi Guenter, >> >> On Fri, Oct 13, 2017 at 9:28 PM, Guenter Roeck wrote: >>> >>> On 10/13/2017 04:10 PM, Hoan Tran wrote: This patch

Re: [PATCH v3] hwmon: xgene: Support hwmon v2

Hi On Fri, Oct 13, 2017 at 9:54 PM, Guenter Roeck wrote: > On 10/13/2017 09:38 PM, Hoan Tran wrote: >> >> Hi Guenter, >> >> On Fri, Oct 13, 2017 at 9:28 PM, Guenter Roeck wrote: >>> >>> On 10/13/2017 04:10 PM, Hoan Tran wrote: This patch supports xgene-hwmon v2 which uses the

Re: [PATCH v3] hwmon: xgene: Support hwmon v2

On 10/13/2017 09:38 PM, Hoan Tran wrote: Hi Guenter, On Fri, Oct 13, 2017 at 9:28 PM, Guenter Roeck wrote: On 10/13/2017 04:10 PM, Hoan Tran wrote: This patch supports xgene-hwmon v2 which uses the non-cachable memory as the PCC shared memory. Signed-off-by: Hoan Tran

Re: [PATCH v3] hwmon: xgene: Support hwmon v2

On 10/13/2017 09:38 PM, Hoan Tran wrote: Hi Guenter, On Fri, Oct 13, 2017 at 9:28 PM, Guenter Roeck wrote: On 10/13/2017 04:10 PM, Hoan Tran wrote: This patch supports xgene-hwmon v2 which uses the non-cachable memory as the PCC shared memory. Signed-off-by: Hoan Tran --- v3 - Use

Re: [RFC][PATCH] x86, syscalls: use SYSCALL_DEFINE() macros for sys_modify_ldt()

On Fri, Oct 13, 2017 at 4:49 PM, Brian Gerst wrote: > On Fri, Oct 13, 2017 at 5:03 PM, Andy Lutomirski wrote: >> On Fri, Oct 13, 2017 at 1:39 PM, Dave Hansen >> wrote: >>> >>> I noticed that we don't have tracepoints for

Re: [RFC][PATCH] x86, syscalls: use SYSCALL_DEFINE() macros for sys_modify_ldt()

On Fri, Oct 13, 2017 at 4:49 PM, Brian Gerst wrote: > On Fri, Oct 13, 2017 at 5:03 PM, Andy Lutomirski wrote: >> On Fri, Oct 13, 2017 at 1:39 PM, Dave Hansen >> wrote: >>> >>> I noticed that we don't have tracepoints for sys_modify_ldt(). I >>> think that's because we define it directly

Re: [PATCH v3] hwmon: xgene: Support hwmon v2

Hi Guenter, On Fri, Oct 13, 2017 at 9:28 PM, Guenter Roeck wrote: > On 10/13/2017 04:10 PM, Hoan Tran wrote: >> >> This patch supports xgene-hwmon v2 which uses the non-cachable memory >> as the PCC shared memory. >> >> Signed-off-by: Hoan Tran >> --- >> v3

Re: [PATCH v3] hwmon: xgene: Support hwmon v2

Hi Guenter, On Fri, Oct 13, 2017 at 9:28 PM, Guenter Roeck wrote: > On 10/13/2017 04:10 PM, Hoan Tran wrote: >> >> This patch supports xgene-hwmon v2 which uses the non-cachable memory >> as the PCC shared memory. >> >> Signed-off-by: Hoan Tran >> --- >> v3 >> - Use local version variable >>

Re: [PATCH v3] hwmon: xgene: Support hwmon v2

On 10/13/2017 04:10 PM, Hoan Tran wrote: This patch supports xgene-hwmon v2 which uses the non-cachable memory as the PCC shared memory. Signed-off-by: Hoan Tran --- v3 - Use local version variable - Use inline calls instead of the private map function v2 - Map PCC

Re: [PATCH v3] hwmon: xgene: Support hwmon v2

On 10/13/2017 04:10 PM, Hoan Tran wrote: This patch supports xgene-hwmon v2 which uses the non-cachable memory as the PCC shared memory. Signed-off-by: Hoan Tran --- v3 - Use local version variable - Use inline calls instead of the private map function v2 - Map PCC shared mem by

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 8:01 PM, Andi Kleen wrote: > > As far as I can see the current model fundamentally only works for > one user per process (because there is only a single range and abort IP) No, it should work for libraries, you just need to always initialize the

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 8:01 PM, Andi Kleen wrote: > > As far as I can see the current model fundamentally only works for > one user per process (because there is only a single range and abort IP) No, it should work for libraries, you just need to always initialize the proper start/commit/abort

[PATCH 5/7] drm/sun4i: backend: Offset layer buffer address by DRAM starting address

The display backend, as well as other peripherals that have a DRAM clock gate and access DRAM directly, bypassing the system bus, address the DRAM starting from 0x0, while physical addresses the system uses starts from 0x4000 (or 0x2000 in A80's case). Correct the address configured into

[PATCH 7/7] drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function

Initially we configured the PAD_CTRL1 register at probe/bind time. However it seems the HDMI controller will modify some of the bits in this register by itself. On the A10 it is particularly annoying as it toggles the output invert bits, which inverts the colors on the display output. The U-boot

[PATCH 1/7] drm/sun4i: don't add components that are already in the queue

Even though the components framework can handle duplicate entries, the extra entries cause a lot more debug messages to be generated, which would be confusing to developers not familiar with our driver and the framework in general. Instead, we can scan the relatively small queue and check if the

[PATCH 5/7] drm/sun4i: backend: Offset layer buffer address by DRAM starting address

The display backend, as well as other peripherals that have a DRAM clock gate and access DRAM directly, bypassing the system bus, address the DRAM starting from 0x0, while physical addresses the system uses starts from 0x4000 (or 0x2000 in A80's case). Correct the address configured into

[PATCH 7/7] drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function

Initially we configured the PAD_CTRL1 register at probe/bind time. However it seems the HDMI controller will modify some of the bits in this register by itself. On the A10 it is particularly annoying as it toggles the output invert bits, which inverts the colors on the display output. The U-boot

[PATCH 1/7] drm/sun4i: don't add components that are already in the queue

Even though the components framework can handle duplicate entries, the extra entries cause a lot more debug messages to be generated, which would be confusing to developers not familiar with our driver and the framework in general. Instead, we can scan the relatively small queue and check if the

[PATCH 0/7] drm/sun4i: More cleanups

Hi, Here's another bunch of cleanups for sun4i-drm. Most of these were found while working on A10/A20 DRM and HDMI support. To be clear, nothing was broken before these patches. Patch 1 trims the sun4i-drm probe sequence by not adding repeating components. The component can deal with duplicates,

[PATCH 0/7] drm/sun4i: More cleanups

Hi, Here's another bunch of cleanups for sun4i-drm. Most of these were found while working on A10/A20 DRM and HDMI support. To be clear, nothing was broken before these patches. Patch 1 trims the sun4i-drm probe sequence by not adding repeating components. The component can deal with duplicates,

[PATCH 6/7] drm/sun4i: hdmi: Document PAD_CTRL1 output invert bits

While debugging inverted color from the HDMI output on the A10, I found that the lowest 3 bits were set. These were cleared on A20 boards that had normal display output. By manually toggling these bits the mapping of the color components to these bits was found. While these are not used anywhere,

[PATCH 4/7] drm/sun4i: backend: Add comment explaining why registers are cleared

Many of the backend's layer configuration registers have undefined default values. This poses a risk as we use regmap_update_bits in some places, and don't overwrite the whole register. At probe/bind time we explicitly clear all the control registers by writing 0 to them. This patch adds a more

[PATCH 6/7] drm/sun4i: hdmi: Document PAD_CTRL1 output invert bits

While debugging inverted color from the HDMI output on the A10, I found that the lowest 3 bits were set. These were cleared on A20 boards that had normal display output. By manually toggling these bits the mapping of the color components to these bits was found. While these are not used anywhere,

[PATCH 4/7] drm/sun4i: backend: Add comment explaining why registers are cleared

Many of the backend's layer configuration registers have undefined default values. This poses a risk as we use regmap_update_bits in some places, and don't overwrite the whole register. At probe/bind time we explicitly clear all the control registers by writing 0 to them. This patch adds a more

[PATCH 3/7] drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display memory

Commit 4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()") adds a new helper, which covers fetching a drm_framebuffer's GEM object and calculating the buffer address for a given plane. This patch uses this helper to replace our own open coded version of the same function.

[PATCH 3/7] drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display memory

Commit 4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()") adds a new helper, which covers fetching a drm_framebuffer's GEM object and calculating the buffer address for a given plane. This patch uses this helper to replace our own open coded version of the same function.

[PATCH 2/7] drm/sun4i: backend: Create regmap after access is possible

The backend has various clocks and reset controls that need to be enabled and deasserted before register access is possible. Move the creation of the regmap to after the clocks and reset controls have been configured where it makes more sense. Signed-off-by: Chen-Yu Tsai ---

[PATCH 2/7] drm/sun4i: backend: Create regmap after access is possible

The backend has various clocks and reset controls that need to be enabled and deasserted before register access is possible. Move the creation of the regmap to after the clocks and reset controls have been configured where it makes more sense. Signed-off-by: Chen-Yu Tsai ---

Re: [linux-sunxi] Re: [PATCH v4 00/11] dmaengine: sun6i: Fixes for H3/A83T, enable A64

Hi Vinod, On Thu, Sep 28, 2017 at 11:26 PM, Maxime Ripard wrote: > On Thu, Sep 28, 2017 at 01:49:17AM +, Stefan Brüns wrote: >> Commit 3a03ea763a67 ("dmaengine: sun6i: Add support for Allwinner A83T >> (sun8i) variant") and commit f008db8c00c1 ("dmaengine:

Re: [linux-sunxi] Re: [PATCH v4 00/11] dmaengine: sun6i: Fixes for H3/A83T, enable A64

Hi Vinod, On Thu, Sep 28, 2017 at 11:26 PM, Maxime Ripard wrote: > On Thu, Sep 28, 2017 at 01:49:17AM +, Stefan Brüns wrote: >> Commit 3a03ea763a67 ("dmaengine: sun6i: Add support for Allwinner A83T >> (sun8i) variant") and commit f008db8c00c1 ("dmaengine: sun6i: Add support for >> Allwinner

Re: [PATCH 0/2] kbuild: use relative path from $(srctree) instead of __FILE__

2017-10-12 18:56 GMT+09:00 Masahiro Yamada : > > Kbuild works in objtree, not in srctree. So, __FILE__ is prefixed > with $(srctree)/ for out-of-tree build. > > For example, WARN_ON() will look as follows if you built your kernel > out of source tree: > > WARNING:

Re: [PATCH 0/2] kbuild: use relative path from $(srctree) instead of __FILE__

2017-10-12 18:56 GMT+09:00 Masahiro Yamada : > > Kbuild works in objtree, not in srctree. So, __FILE__ is prefixed > with $(srctree)/ for out-of-tree build. > > For example, WARN_ON() will look as follows if you built your kernel > out of source tree: > > WARNING: CPU: 1 PID: 1 at

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> That sounds so obvious and stupid that you might go "What do you > mean?", but for things to work for libraries, they have to work > together with *other* users, and with *independent* users. As far as I can see the current model fundamentally only works for one user per process (because there

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> That sounds so obvious and stupid that you might go "What do you > mean?", but for things to work for libraries, they have to work > together with *other* users, and with *independent* users. As far as I can see the current model fundamentally only works for one user per process (because there

Re: [PATCH] ecryptfs: Fix stat command displays wrong file size in xattr region

Could anyone take a look at this patch which fixes the xattr-read issue? Thanks anyway. Jason On Thu, Jun 22, 2017 at 3:21 PM, Jason Xing wrote: > When doing ecryptfs_read_and_validate_xattr_region(), eCryptfs > reads only 16 bytes from xattr region. However, the

Re: [PATCH] ecryptfs: Fix stat command displays wrong file size in xattr region

Could anyone take a look at this patch which fixes the xattr-read issue? Thanks anyway. Jason On Thu, Jun 22, 2017 at 3:21 PM, Jason Xing wrote: > When doing ecryptfs_read_and_validate_xattr_region(), eCryptfs > reads only 16 bytes from xattr region. However, the lower filesystem > like ext4

[PATCH] PCI: hv: fix "spurious APIC interrupt" due to new vector reservation mode

Last month the vector management code was reworked, and as a result of the changes, e.g. commit 22d0b12f3560 ("genirq/irqdomain: Add force reactivation flag to irq domains"), commit 4900be83602b ("x86/vector/msi: Switch to global reservation mode") etc, now we must add this new flag

[PATCH] PCI: hv: fix "spurious APIC interrupt" due to new vector reservation mode

Last month the vector management code was reworked, and as a result of the changes, e.g. commit 22d0b12f3560 ("genirq/irqdomain: Add force reactivation flag to irq domains"), commit 4900be83602b ("x86/vector/msi: Switch to global reservation mode") etc, now we must add this new flag

Re: [RFC PATCH for 4.15 09/14] Provide cpu_opv system call

> + pagefault_disable(); > + switch (len) { > + case 1: > + if (__get_user(tmp._u8, (uint8_t __user *)p)) > + goto end; > + tmp._u8 += (uint8_t)count; > + if (__put_user(tmp._u8, (uint8_t __user *)p)) > + goto

Re: [RFC PATCH for 4.15 09/14] Provide cpu_opv system call

> + pagefault_disable(); > + switch (len) { > + case 1: > + if (__get_user(tmp._u8, (uint8_t __user *)p)) > + goto end; > + tmp._u8 += (uint8_t)count; > + if (__put_user(tmp._u8, (uint8_t __user *)p)) > + goto

Re: [PATCH v6 1/4] cramfs: direct memory access support

On Fri, 13 Oct 2017, Nicolas Pitre wrote: > On Sat, 14 Oct 2017, Al Viro wrote: > > > On Fri, Oct 13, 2017 at 04:09:23PM -0400, Nicolas Pitre wrote: > > > On Fri, 13 Oct 2017, Al Viro wrote: > > > > > > > OK... I wonder if it should simply define stubs for kill_mtd_super(), > > > >

Re: [PATCH v6 1/4] cramfs: direct memory access support

On Fri, 13 Oct 2017, Nicolas Pitre wrote: > On Sat, 14 Oct 2017, Al Viro wrote: > > > On Fri, Oct 13, 2017 at 04:09:23PM -0400, Nicolas Pitre wrote: > > > On Fri, 13 Oct 2017, Al Viro wrote: > > > > > > > OK... I wonder if it should simply define stubs for kill_mtd_super(), > > > >

Re: [PATCH v6 1/4] cramfs: direct memory access support

On Sat, 14 Oct 2017, Al Viro wrote: > On Fri, Oct 13, 2017 at 04:09:23PM -0400, Nicolas Pitre wrote: > > On Fri, 13 Oct 2017, Al Viro wrote: > > > > > OK... I wonder if it should simply define stubs for kill_mtd_super(), > > > mtd_unpoint() and kill_block_super() in !CONFIG_MTD and

Re: [PATCH v6 1/4] cramfs: direct memory access support

On Sat, 14 Oct 2017, Al Viro wrote: > On Fri, Oct 13, 2017 at 04:09:23PM -0400, Nicolas Pitre wrote: > > On Fri, 13 Oct 2017, Al Viro wrote: > > > > > OK... I wonder if it should simply define stubs for kill_mtd_super(), > > > mtd_unpoint() and kill_block_super() in !CONFIG_MTD and

Re: [PATCH v5 01/12] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings

On Fri, 2017-10-13 at 16:50 -0500, Rob Herring wrote: > On Wed, Oct 11, 2017 at 10:41:25AM +0800, Chaotian Jing wrote: > > Change the comptiable for support of multi-platform > > Make compatible explicit > > Add description for reg > > Add description for source_cg > > Add description for

Re: [PATCH v5 01/12] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings

On Fri, 2017-10-13 at 16:50 -0500, Rob Herring wrote: > On Wed, Oct 11, 2017 at 10:41:25AM +0800, Chaotian Jing wrote: > > Change the comptiable for support of multi-platform > > Make compatible explicit > > Add description for reg > > Add description for source_cg > > Add description for

Re: [PATCH v2 03/13] mmc: dt-bindings: make compatible explicit

On Fri, 2017-10-13 at 15:14 -0500, Rob Herring wrote: > On Mon, Oct 09, 2017 at 07:35:16PM +0800, Chaotian Jing wrote: > > the driver has updated to have an explicit compatible, so update > > binding file according to the driver change. > > Normally, that's not a reason for a binding change. An

Re: [PATCH v2 03/13] mmc: dt-bindings: make compatible explicit

On Fri, 2017-10-13 at 15:14 -0500, Rob Herring wrote: > On Mon, Oct 09, 2017 at 07:35:16PM +0800, Chaotian Jing wrote: > > the driver has updated to have an explicit compatible, so update > > binding file according to the driver change. > > Normally, that's not a reason for a binding change. An

RE: [Intel-wired-lan] [PATCH][V3] e1000: avoid null pointer dereference on invalid stat type

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf > Of Colin King > Sent: Friday, September 22, 2017 10:14 AM > To: Kirsher, Jeffrey T ; intel-wired- > l...@lists.osuosl.org; net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org;

RE: [Intel-wired-lan] [PATCH][V3] e1000: avoid null pointer dereference on invalid stat type

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf > Of Colin King > Sent: Friday, September 22, 2017 10:14 AM > To: Kirsher, Jeffrey T ; intel-wired- > l...@lists.osuosl.org; net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org >

Re: [RFC PATCH v2 3/8] cpuidle: add a new predict interface

On Saturday, September 30, 2017 9:20:29 AM CEST Aubrey Li wrote: > For the governor has predict functionality, add a new predict > interface in cpuidle framework to call and use it. > --- > drivers/cpuidle/cpuidle.c| 34 ++ >

Re: [RFC PATCH v2 3/8] cpuidle: add a new predict interface

On Saturday, September 30, 2017 9:20:29 AM CEST Aubrey Li wrote: > For the governor has predict functionality, add a new predict > interface in cpuidle framework to call and use it. > --- > drivers/cpuidle/cpuidle.c| 34 ++ >

Re: [PATCH 08/18] ecryptfs: use ARRAY_SIZE

On 10/01/2017 03:30 PM, Jérémy Lefaure wrote: > Using the ARRAY_SIZE macro improves the readability of the code. > > Found with Coccinelle with the following semantic patch: > @r depends on (org || report)@ > type T; > T[] E; > position p; > @@ > ( > (sizeof(E)@p /sizeof(*E)) > | > (sizeof(E)@p

Re: [PATCH 08/18] ecryptfs: use ARRAY_SIZE

On 10/01/2017 03:30 PM, Jérémy Lefaure wrote: > Using the ARRAY_SIZE macro improves the readability of the code. > > Found with Coccinelle with the following semantic patch: > @r depends on (org || report)@ > type T; > T[] E; > position p; > @@ > ( > (sizeof(E)@p /sizeof(*E)) > | > (sizeof(E)@p

Re: [PATCH 0/3] eCryptfs: Adjustments for several function implementations

On 08/19/2017 12:54 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 19 Aug 2017 18:15:14 +0200 > > Some update suggestions were taken into account > from static source code analysis. > > Markus Elfring (3): > Delete 21 error messages for a

Re: [PATCH 0/3] eCryptfs: Adjustments for several function implementations

On 08/19/2017 12:54 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 19 Aug 2017 18:15:14 +0200 > > Some update suggestions were taken into account > from static source code analysis. > > Markus Elfring (3): > Delete 21 error messages for a failed memory allocation > Return

Re: [PATCH] eCryptfs: constify attribute_group structures.

Hi Arvind - My apologies for the extremely slow review. On 06/30/2017 05:33 AM, Arvind Yadav wrote: > attribute_groups are not supposed to change at runtime. All functions > working with attribute_groups provided by work with const > attribute_group. So mark the non-const structs as const. > >

Re: [PATCH] eCryptfs: constify attribute_group structures.

Hi Arvind - My apologies for the extremely slow review. On 06/30/2017 05:33 AM, Arvind Yadav wrote: > attribute_groups are not supposed to change at runtime. All functions > working with attribute_groups provided by work with const > attribute_group. So mark the non-const structs as const. > >

Re: [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality

On Saturday, September 30, 2017 9:20:26 AM CEST Aubrey Li wrote: > We found under some latency intensive workloads, short idle periods occurs > very common, then idle entry and exit path starts to dominate, so it's > important to optimize them. To determine the short idle pattern, we need > to

Re: [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality

On Saturday, September 30, 2017 9:20:26 AM CEST Aubrey Li wrote: > We found under some latency intensive workloads, short idle periods occurs > very common, then idle entry and exit path starts to dominate, so it's > important to optimize them. To determine the short idle pattern, we need > to

Re: [RFC PATCH v2 8/8] cpuidle: introduce run queue average idle to make idle prediction

On Saturday, September 30, 2017 9:20:34 AM CEST Aubrey Li wrote: > Introduce run queue average idle in scheduler as a factor to make > idle prediction > > Signed-off-by: Aubrey Li > --- > drivers/cpuidle/cpuidle.c | 12 > include/linux/cpuidle.h | 1 +

Re: [RFC PATCH v2 8/8] cpuidle: introduce run queue average idle to make idle prediction

On Saturday, September 30, 2017 9:20:34 AM CEST Aubrey Li wrote: > Introduce run queue average idle in scheduler as a factor to make > idle prediction > > Signed-off-by: Aubrey Li > --- > drivers/cpuidle/cpuidle.c | 12 > include/linux/cpuidle.h | 1 + > kernel/sched/idle.c

Re: [RFC PATCH v2 7/8] cpuidle: introduce irq timing to make idle prediction

On Saturday, September 30, 2017 9:20:33 AM CEST Aubrey Li wrote: > Introduce irq timings output as a factor to predict the duration > of the coming idle > > Signed-off-by: Aubrey Li > --- > drivers/cpuidle/Kconfig | 1 + > drivers/cpuidle/cpuidle.c | 17

Re: [RFC PATCH v2 7/8] cpuidle: introduce irq timing to make idle prediction

On Saturday, September 30, 2017 9:20:33 AM CEST Aubrey Li wrote: > Introduce irq timings output as a factor to predict the duration > of the coming idle > > Signed-off-by: Aubrey Li > --- > drivers/cpuidle/Kconfig | 1 + > drivers/cpuidle/cpuidle.c | 17 - > 2 files changed,

  1   2   3   4   5   6   7   8   9   10   >