Re: [PATCH][next] dax: remove redundant assignment to variable rc

s/dax/bus.c:1207:2: warning: Value stored to 'rc' is never > read [deadcode.DeadStores] > > Signed-off-by: Colin Ian King Reviewed-by: Alison Schofield > --- > drivers/dax/bus.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c

Re: [PATCH] tracing: Add __string_src() helper to help compilers not to get confused

dev() as a string") being applied, as passing > the qdisc_dev() into __string_src() will give an error. > > Link: https://lore.kernel.org/all/ZfNmfCmgCs4Nc+EH@aschofie-mobl2/ Reviewed-by: Alison Schofield > > Reported-by: Alison Schofield > Signed-off-by: Steven Rosted

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, Feb 23, 2024 at 12:56:34PM -0500, Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > [ >This is a treewide change. I will likely re-create this patch again in >the second week of the merge window of v6.9 and submit it then. Hoping >to keep the conflicts that it will

Re: [PATCH v7 5/5] dax: add a sysfs knob to control memmap_on_memory behavior

or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to > preserve legacy behavior. For dax devices via CXL, the default is on. > The sysfs control allows the administrator to override the above > defaults if needed. Reviewed-by: Alison Schofield > > Cc: David Hildenbrand

Re: [PATCH v7 2/5] dax/bus.c: replace several sprintf() with sysfs_emit()

; sysfs_emit() in this file. > Reviewed-by: Alison Schofield > Cc: Dan Williams > Reported-by: Greg Kroah-Hartman > Signed-off-by: Vishal Verma > --- > drivers/dax/bus.c | 32 > 1 file changed, 16 insertions(+), 16 deletions(-) > > diff --git

Re: [PATCH v7 1/5] dax/bus.c: replace driver-core lock usage by a local rwsem

tion and dax device configuration. As a result of this > conversion, no device_lock() usage remains in dax/bus.c. > Reviewed-by: Alison Schofield > Cc: Dan Williams > Reported-by: Greg Kroah-Hartman > Signed-off-by: Vishal Verma >

Re: [PATCH] ACPI: NFIT: add helper to_nfit_mem() to take device to nfit_mem

On Mon, Jul 03, 2023 at 02:17:29PM +0100, Ben Dooks wrote: > Add a quick helper to just do struct device to the struct nfit_mem > field it should be referencing. This reduces the number of code > lines in some of the followgn code as it removes the intermediate > struct nvdimm. > Hi Ben, This a

Re: [PATCH] dax/kmem: Pass valid argument to memory_group_register_static

On Tue, Jun 20, 2023 at 07:33:32PM +0530, Tarun Sahu wrote: > memory_group_register_static takes maximum number of pages as the argument > while dev_dax_kmem_probe passes total_len (in bytes) as the argument. This sounds like a fix. An explanation of the impact and a fixes tag may be needed.

Re: [PATCH] nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

On Fri, Apr 14, 2023 at 06:50:59PM +0200, Markus Elfring wrote: > >> The address of a data structure member was determined before > >> a corresponding null pointer check in the implementation of > >> the function “nd_pfn_validate”. > >> > >> Thus avoid the risk for undefined behaviour by replacing

Re: [PATCH] nvdimm: Replace the usage of a variable by a direct function call in nd_pfn_validate()

On Fri, Apr 14, 2023 at 12:12:37PM +0200, Markus Elfring wrote: > Date: Fri, 14 Apr 2023 12:01:15 +0200 > > The address of a data structure member was determined before > a corresponding null pointer check in the implementation of > the function “nd_pfn_validate”. > > Thus avoid the risk for

Re: [PATCH] nvdimm: check for null return of devm_kmalloc in nd_pfn_probe

On Sun, Feb 26, 2023 at 01:56:15PM +0800, Kang Chen wrote: > devm_kmalloc may fails, pfn_sb might be null and will cause > null pointer dereference later. > > Signed-off-by: Kang Chen > --- > drivers/nvdimm/pfn_devs.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git

[tip: x86/core] x86, sched: Treat Intel SNC topology as default, COD as exception

The following commit has been merged into the x86/core branch of tip: Commit-ID: 2c88d45edbb89029c1190bb3b136d2602f057c98 Gitweb: https://git.kernel.org/tip/2c88d45edbb89029c1190bb3b136d2602f057c98 Author:Alison Schofield AuthorDate:Wed, 10 Mar 2021 11:02:33 -08:00

Re: [PATCH v3] x86, sched: Treat Intel SNC topology as default, COD as exception

Ping - any feedback? Thanks! On Wed, Mar 10, 2021 at 11:02:33AM -0800, Alison Schofield wrote: > Commit 1340ccfa9a9a ("x86,sched: Allow topologies where NUMA nodes > share an LLC") added a vendor and model specific check to never > call topology_sane() for Intel Skylake Server

[PATCH v3] x86, sched: Treat Intel SNC topology as default, COD as exception

n. In SNC mode, Sky Lake, Ice Lake, and Sapphire Rapids servers do not emit this warning: sched: CPU #3's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency. Acked-by: Dave Hansen Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Alison Schofield Cc: sta...@vger.

[PATCH v2] x86,sched: Update the Intel SNC CPU list that allows shared LLCs

, Ice Lake and Sapphire Rapids servers will no longer emit this warning: sched: CPU #3's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency. Acked-by: Dave Hansen Signed-off-by: Alison Schofield Cc: Dave Hansen Cc: Tony Luck Cc: Tim Chen Cc: "H. Peter Anvin

Re: [PATCH] x86, sched: Allow NUMA nodes to share an LLC on Intel platforms

On Tue, Feb 16, 2021 at 12:29:02PM +0100, Peter Zijlstra wrote: > On Wed, Feb 10, 2021 at 02:11:34PM -0800, Alison Schofield wrote: > > > This is equivalent to determining if x86_has_numa_in_package. > > Do you think there is an opportunity to set x86_has_numa_in_package &g

Re: [PATCH] x86, sched: Allow NUMA nodes to share an LLC on Intel platforms

On Wed, Feb 10, 2021 at 08:38:42PM +0100, Peter Zijlstra wrote: > On Wed, Feb 10, 2021 at 07:22:03AM -0800, Dave Hansen wrote: > > On 2/10/21 12:05 AM, Peter Zijlstra wrote: > > >> +if (IS_ENABLED(CONFIG_NUMA)) > > >> +set_cpu_bug(c, X86_BUG_NUMA_SHARES_LLC); > > >> } > >

[PATCH] x86, sched: Allow NUMA nodes to share an LLC on Intel platforms

d Sapphire Rapids CPUs exhibit the same topology. Rather than maintain the quirk list, define a synthetic flag that directs the scheduler to allow this topology without warning for all Intel CPUs when NUMA is configured. Acked-by: Dave Hansen Signed-off-by: Alison Schofield Cc: Dave Hansen Cc: Ton

Re: [PATCH] Ability to read the MKTME status from userspace (patch v2)

On Thu, Jun 25, 2020 at 06:10:29PM -0300, Daniel Gutson wrote: > The intent of this patch is to provide visibility of the > MKTME status to userspace. This is an important factor for > firmware security related applilcations. > > Changes since v1: > *

Re: [PATCHv2 57/59] x86/mktme: Document the MKTME Key Service API

On Mon, Aug 05, 2019 at 07:58:37AM -0400, Ben Boeckel wrote: > On Wed, Jul 31, 2019 at 18:08:11 +0300, Kirill A. Shutemov wrote: > > + key = add_key("mktme", "name", "no-encrypt", strlen(options_CPU), > > + KEY_SPEC_THREAD_KEYRING); > > Should this be `type=no-encrypt` here?

Re: [PATCHv2 25/59] keys/mktme: Preparse the MKTME key payload

On Mon, Aug 05, 2019 at 07:58:19AM -0400, Ben Boeckel wrote: > On Wed, Jul 31, 2019 at 18:07:39 +0300, Kirill A. Shutemov wrote: > > From: Alison Schofield > > +/* Make sure arguments are correct for the TYPE of key requested */ > > +static int mktme_check_options(u32 *p

Re: [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call for MKTME

On Fri, Jun 14, 2019 at 01:51:37PM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:44:05PM +0300, Kirill A. Shutemov wrote: snip > > /* > > - * When pkey==NO_KEY we get legacy mprotect behavior here. > > + * do_mprotect_ext() supports the legacy mprotect behavior plus extensions > > + *

Re: [PATCH, RFC 47/62] mm: Restrict MKTME memory encryption to anonymous VMAs

On Fri, Jun 14, 2019 at 01:55:20PM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:44:07PM +0300, Kirill A. Shutemov wrote: > > From: Alison Schofield > > > > Memory encryption is only supported for mappings that are ANONYMOUS. > > Test the VMA's in an

Re: [PATCH, RFC 44/62] x86/mm: Set KeyIDs in encrypted VMAs for MKTME

On Fri, Jun 14, 2019 at 11:26:10AM -0700, Dave Hansen wrote: > On 6/14/19 10:33 AM, Alison Schofield wrote: > > Preserving the data across encryption key changes has not > > been a requirement. I'm not clear if it was ever considered > > and rejected. I believe that copying

Re: [PATCH, RFC 46/62] x86/mm: Keep reference counts on encrypted VMAs for MKTME

On Fri, Jun 14, 2019 at 01:54:24PM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:44:06PM +0300, Kirill A. Shutemov wrote: > > From: Alison Schofield > > > > The MKTME (Multi-Key Total Memory Encryption) Key Service needs > > a reference count on encrypted

Re: [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call for MKTME

On Fri, Jun 14, 2019 at 01:47:32PM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:44:05PM +0300, Kirill A. Shutemov wrote: > > diff --git a/fs/exec.c b/fs/exec.c > > index 2e0033348d8e..695c121b34b3 100644 > > --- a/fs/exec.c > > +++ b/fs/exec.c > > @@ -755,8 +755,8 @@ int

Re: [PATCH, RFC 44/62] x86/mm: Set KeyIDs in encrypted VMAs for MKTME

On Fri, Jun 14, 2019 at 01:44:08PM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:44:04PM +0300, Kirill A. Shutemov wrote: > > From: Alison Schofield > > > > MKTME architecture requires the KeyID to be placed in PTE bits 51:46. > > To create an enc

Re: [PATCH, RFC 26/62] keys/mktme: Move the MKTME payload into a cache aligned structure

On Fri, Jun 14, 2019 at 01:35:23PM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:43:46PM +0300, Kirill A. Shutemov wrote: > > > +/* Copy the payload to the HW programming structure and program this KeyID > > */ > > +static int mktme_program_keyid(int keyid, struct mktme_payload

Re: [PATCH, RFC 00/62] Intel MKTME enabling

On Wed, May 29, 2019 at 10:30:07AM +0300, Mike Rapoport wrote: > On Wed, May 08, 2019 at 05:43:20PM +0300, Kirill A. Shutemov wrote: > > = Intro = > > > > The patchset brings enabling of Intel Multi-Key Total Memory Encryption. > > It consists of changes into multiple subsystems: > > > > * Core

Re: [PATCH, RFC 57/62] x86/mktme: Overview of Multi-Key Total Memory Encryption

On Wed, May 29, 2019 at 10:21:48AM +0300, Mike Rapoport wrote: > On Wed, May 08, 2019 at 05:44:17PM +0300, Kirill A. Shutemov wrote: > > From: Alison Schofield > > > > Provide an overview of MKTME on Intel Platforms. > > > > Signed-off-by: Alison Schofield >

Re: [PATCH, RFC 43/62] syscall/x86: Wire up a system call for MKTME encryption keys

On Wed, May 29, 2019 at 10:21:37AM +0300, Mike Rapoport wrote: > On Wed, May 08, 2019 at 05:44:03PM +0300, Kirill A. Shutemov wrote: > > From: Alison Schofield > > > > encrypt_mprotect() is a new system call to support memory encryption. > > > > It takes the s

Re: [PATCH, RFC 48/62] selftests/x86/mktme: Test the MKTME APIs

Please ignore this patch. It includes an outdated draft from early testing. Other than showing our intent to deliver selftests, it is not out for review. Alison

Re: [PATCH] acpi/hmat: Update acpi_hmat_type enum with ACPI_HMAT_TYPE_PROXIMITY

On Thu, Apr 18, 2019 at 05:07:12PM +0200, Rafael J. Wysocki wrote: > On Thu, Apr 18, 2019 at 5:02 PM Keith Busch wrote: > > > > On Wed, Apr 17, 2019 at 11:13:10AM -0700, Alison Schofield wrote: > > > ACPI 6.3 changed the subtable "Memory Subsystem Address Rang

[PATCH] acpi/hmat: Update acpi_hmat_type enum with ACPI_HMAT_TYPE_PROXIMITY

e enum type to match the subtable and structure naming. Signed-off-by: Alison Schofield --- drivers/acpi/hmat/hmat.c | 4 ++-- include/acpi/actbl1.h| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/hmat/hmat.c b/drivers/acpi/hmat/hmat.c index b7824a0309f7.

[PATCH] selftests/vm/gup_benchmark.c: match gup struct to kernel

An expansion field was added to the kernel copy of this structure for future use. See mm/gup_benchmark.c. Add the same expansion field here, so that the IOCTL command decodes correctly. Otherwise, it fails with EINVAL. Signed-off-by: Alison Schofield --- tools/testing/selftests/vm

[PATCH] selftests/vm/gup_benchmark.c: match gup struct to kernel

An expansion field was added to the kernel copy of this structure for future use. See mm/gup_benchmark.c. Add the same expansion field here, so that the IOCTL command decodes correctly. Otherwise, it fails with EINVAL. Signed-off-by: Alison Schofield --- tools/testing/selftests/vm

Re: [PATCHv5 10/19] x86/mm: Implement page_keyid() using page_ext

On Mon, Jul 23, 2018 at 12:45:17PM +0300, Kirill A. Shutemov wrote: > On Wed, Jul 18, 2018 at 04:38:02PM -0700, Dave Hansen wrote: > > On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote: > > > Store KeyID in bits 31:16 of extended page flags. These bits are unused. > > > > I'd love a two sentence

Re: [PATCHv5 10/19] x86/mm: Implement page_keyid() using page_ext

On Mon, Jul 23, 2018 at 12:45:17PM +0300, Kirill A. Shutemov wrote: > On Wed, Jul 18, 2018 at 04:38:02PM -0700, Dave Hansen wrote: > > On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote: > > > Store KeyID in bits 31:16 of extended page flags. These bits are unused. > > > > I'd love a two sentence

[tip:x86/urgent] x86,sched: Allow topologies where NUMA nodes share an LLC

Commit-ID: 1340ccfa9a9afefdbab90d7935d4ed19817e37c2 Gitweb: https://git.kernel.org/tip/1340ccfa9a9afefdbab90d7935d4ed19817e37c2 Author: Alison Schofield <alison.schofi...@intel.com> AuthorDate: Fri, 6 Apr 2018 17:21:30 -0700 Committer: Thomas Gleixner <t...@linutronix.de> Com

[tip:x86/urgent] x86,sched: Allow topologies where NUMA nodes share an LLC

Commit-ID: 1340ccfa9a9afefdbab90d7935d4ed19817e37c2 Gitweb: https://git.kernel.org/tip/1340ccfa9a9afefdbab90d7935d4ed19817e37c2 Author: Alison Schofield AuthorDate: Fri, 6 Apr 2018 17:21:30 -0700 Committer: Thomas Gleixner CommitDate: Tue, 17 Apr 2018 15:39:55 +0200 x86,sched: Allow

[PATCH v5] x86,sched: allow topologies where NUMA nodes share an LLC

From: Alison Schofield <alison.schofi...@intel.com> Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one m

[PATCH v5] x86,sched: allow topologies where NUMA nodes share an LLC

From: Alison Schofield Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one memory controller and each slice is

Re: [PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

On Wed, Apr 04, 2018 at 12:00:45PM -0700, Alison Schofield wrote: > On Wed, Apr 04, 2018 at 11:42:11AM -0700, Tim Chen wrote: > > On 04/04/2018 10:38 AM, Alison Schofield wrote: > > > On Wed, Apr 04, 2018 at 10:24:49AM -0700, Tim Chen wrote: > > >> On 04/03/2018 02

Re: [PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

On Wed, Apr 04, 2018 at 12:00:45PM -0700, Alison Schofield wrote: > On Wed, Apr 04, 2018 at 11:42:11AM -0700, Tim Chen wrote: > > On 04/04/2018 10:38 AM, Alison Schofield wrote: > > > On Wed, Apr 04, 2018 at 10:24:49AM -0700, Tim Chen wrote: > > >> On 04/03/2018 02

Re: [PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

On Wed, Apr 04, 2018 at 11:42:11AM -0700, Tim Chen wrote: > On 04/04/2018 10:38 AM, Alison Schofield wrote: > > On Wed, Apr 04, 2018 at 10:24:49AM -0700, Tim Chen wrote: > >> On 04/03/2018 02:12 PM, Alison Schofield wrote: > >> > >>> + > >>> + /*

Re: [PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

On Wed, Apr 04, 2018 at 11:42:11AM -0700, Tim Chen wrote: > On 04/04/2018 10:38 AM, Alison Schofield wrote: > > On Wed, Apr 04, 2018 at 10:24:49AM -0700, Tim Chen wrote: > >> On 04/03/2018 02:12 PM, Alison Schofield wrote: > >> > >>> + > >>> + /*

Re: [PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

On Wed, Apr 04, 2018 at 10:24:49AM -0700, Tim Chen wrote: > On 04/03/2018 02:12 PM, Alison Schofield wrote: > > > + > > + /* > > +* topology_sane() considers LLCs that span NUMA nodes to be > > +* insane and will display a warning message. Bypass the ca

Re: [PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

On Wed, Apr 04, 2018 at 10:24:49AM -0700, Tim Chen wrote: > On 04/03/2018 02:12 PM, Alison Schofield wrote: > > > + > > + /* > > +* topology_sane() considers LLCs that span NUMA nodes to be > > +* insane and will display a warning message. Bypass the ca

[PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

From: Alison Schofield <alison.schofi...@intel.com> Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one m

[PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

From: Alison Schofield Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one memory controller and each slice is

Re: [PATCH v3] x86,sched: allow topologies where NUMA nodes share an LLC

On Wed, Mar 28, 2018 at 05:00:24PM -0700, Alison Schofield wrote: > From: Alison Schofield <alison.schofi...@intel.com> > > Intel's Skylake Server CPUs have a different LLC topology than previous > generations. When in Sub-NUMA-Clustering (SNC) mode, the package is > div

Re: [PATCH v3] x86,sched: allow topologies where NUMA nodes share an LLC

On Wed, Mar 28, 2018 at 05:00:24PM -0700, Alison Schofield wrote: > From: Alison Schofield > > Intel's Skylake Server CPUs have a different LLC topology than previous > generations. When in Sub-NUMA-Clustering (SNC) mode, the package is > divided into two "slices", each

[PATCH v3] x86,sched: allow topologies where NUMA nodes share an LLC

From: Alison Schofield <alison.schofi...@intel.com> Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one m

[PATCH v3] x86,sched: allow topologies where NUMA nodes share an LLC

From: Alison Schofield Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one memory controller and each slice is

Re: [PATCH v2] x86,sched: allow topologies where NUMA nodes share an LLC

On Thu, Mar 22, 2018 at 04:30:29PM -0700, Luck, Tony wrote: > On Thu, Mar 22, 2018 at 01:49:22PM -0700, Alison Schofield wrote: > > + if (!topology_same_node(c, o) && > > + (c->x86_vendor == X86_VENDOR_INTEL && > > +c->x86_model == IN

Re: [PATCH v2] x86,sched: allow topologies where NUMA nodes share an LLC

On Thu, Mar 22, 2018 at 04:30:29PM -0700, Luck, Tony wrote: > On Thu, Mar 22, 2018 at 01:49:22PM -0700, Alison Schofield wrote: > > + if (!topology_same_node(c, o) && > > + (c->x86_vendor == X86_VENDOR_INTEL && > > +c->x86_model == IN

Re: [PATCH v2] x86,sched: allow topologies where NUMA nodes share an LLC

On Thu, Mar 22, 2018 at 05:42:41PM -0700, Tim Chen wrote: > On 03/22/2018 01:49 PM, Alison Schofield wrote: > > > > +*/ > > + if (!topology_same_node(c, o) && > > + (c->x86_vendor == X86_VENDOR_INTEL && > > +c->x86_model

Re: [PATCH v2] x86,sched: allow topologies where NUMA nodes share an LLC

On Thu, Mar 22, 2018 at 05:42:41PM -0700, Tim Chen wrote: > On 03/22/2018 01:49 PM, Alison Schofield wrote: > > > > +*/ > > + if (!topology_same_node(c, o) && > > + (c->x86_vendor == X86_VENDOR_INTEL && > > +c->x86_model

[PATCH v2] x86,sched: allow topologies where NUMA nodes share an LLC

From: Alison Schofield <alison.schofi...@intel.com> Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one m

[PATCH v2] x86,sched: allow topologies where NUMA nodes share an LLC

From: Alison Schofield Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one memory controller and each slice is

Re: [Outreachy kernel] [PATCH] iio: adc: replace comma with a semicolon

On Thu, Mar 30, 2017 at 06:16:03PM +0530, Arushi Singhal wrote: > Replace a comma between expression statements by a semicolon. This > changes the semantics of the code, but given the current indentation > appears to be what is intended. Hi Arushi, Well, you've gotten a lot of comments on this

Re: [Outreachy kernel] [PATCH] iio: adc: replace comma with a semicolon

On Thu, Mar 30, 2017 at 06:16:03PM +0530, Arushi Singhal wrote: > Replace a comma between expression statements by a semicolon. This > changes the semantics of the code, but given the current indentation > appears to be what is intended. Hi Arushi, Well, you've gotten a lot of comments on this

Re: [Outreachy kernel] [PATCH 0/4] drivers: iio: Replace ternary operator with min macro

On Wed, Mar 29, 2017 at 06:03:07PM +0530, simran singhal wrote: > Use macro min() to get the minimum of two values for brevity and readability. > > simran singhal (4): > iio: common: st_sensors: Replace ternary operator with min macro > iio: imu: st_lsm6dsx: Replace ternary operator with min

Re: [Outreachy kernel] [PATCH 0/4] drivers: iio: Replace ternary operator with min macro

On Wed, Mar 29, 2017 at 06:03:07PM +0530, simran singhal wrote: > Use macro min() to get the minimum of two values for brevity and readability. > > simran singhal (4): > iio: common: st_sensors: Replace ternary operator with min macro > iio: imu: st_lsm6dsx: Replace ternary operator with min

Re: [Outreachy kernel] [PATCH] iio: accel: bma180: Set up buffer timestamps for non-zero values

On Wed, Mar 29, 2017 at 08:16:58AM -0700, Alison Schofield wrote: > On Wed, Mar 29, 2017 at 07:41:31PM +0530, simran singhal wrote: > > Use the iio_pollfunc_store_time parameter during triggered buffer set-up > > to get valid timestamps. > > > > Signed-off-by:

Re: [Outreachy kernel] [PATCH] iio: accel: bma180: Set up buffer timestamps for non-zero values

On Wed, Mar 29, 2017 at 08:16:58AM -0700, Alison Schofield wrote: > On Wed, Mar 29, 2017 at 07:41:31PM +0530, simran singhal wrote: > > Use the iio_pollfunc_store_time parameter during triggered buffer set-up > > to get valid timestamps. > > > > Signed-off-by: simran s

Re: [Outreachy kernel] [PATCH] iio: accel: bma180: Set up buffer timestamps for non-zero values

On Wed, Mar 29, 2017 at 07:41:31PM +0530, simran singhal wrote: > Use the iio_pollfunc_store_time parameter during triggered buffer set-up > to get valid timestamps. > > Signed-off-by: simran singhal Hi Simran, I guess you knew I'd recognize this one ;) My first

Re: [Outreachy kernel] [PATCH] iio: accel: bma180: Set up buffer timestamps for non-zero values

On Wed, Mar 29, 2017 at 07:41:31PM +0530, simran singhal wrote: > Use the iio_pollfunc_store_time parameter during triggered buffer set-up > to get valid timestamps. > > Signed-off-by: simran singhal Hi Simran, I guess you knew I'd recognize this one ;) My first thought were - "Wow that was a

Re: [Outreachy kernel] [PATCH v4] staging: iio: ade7753: Replace mlock with driver private lock

On Tue, Mar 28, 2017 at 10:55:17PM +0530, SIMRAN SINGHAL wrote: > On Fri, Mar 24, 2017 at 12:51 AM, Alison Schofield <amsfiel...@gmail.com> > wrote: > > On Fri, Mar 24, 2017 at 12:05:20AM +0530, simran singhal wrote: > >> The IIO subsystem is redefining iio_dev->ml

Re: [Outreachy kernel] [PATCH v4] staging: iio: ade7753: Replace mlock with driver private lock

On Tue, Mar 28, 2017 at 10:55:17PM +0530, SIMRAN SINGHAL wrote: > On Fri, Mar 24, 2017 at 12:51 AM, Alison Schofield > wrote: > > On Fri, Mar 24, 2017 at 12:05:20AM +0530, simran singhal wrote: > >> The IIO subsystem is redefining iio_dev->mlock to be used b

Re: [Outreachy kernel] [PATCH v4] staging: iio: ade7753: Replace mlock with driver private lock

On Fri, Mar 24, 2017 at 12:05:20AM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH v4] staging: iio: ade7753: Replace mlock with driver private lock

On Fri, Mar 24, 2017 at 12:05:20AM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH v3 0/2] Replace mlock with private lock and delete whitespaces

On Tue, Mar 21, 2017 at 11:33:54PM +0530, simran singhal wrote: > The patch series replaces mlock with a private lock for driver ad9834 and > Fix coding style issues related to white spaces. Hi Simran, I'm getting lost. Patchset Subject Line needs subsystem and driver. The comment above says

Re: [Outreachy kernel] [PATCH v3 0/2] Replace mlock with private lock and delete whitespaces

On Tue, Mar 21, 2017 at 11:33:54PM +0530, simran singhal wrote: > The patch series replaces mlock with a private lock for driver ad9834 and > Fix coding style issues related to white spaces. Hi Simran, I'm getting lost. Patchset Subject Line needs subsystem and driver. The comment above says

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

On Tue, Mar 21, 2017 at 10:52:46PM +0530, Arushi Singhal wrote: > On Tue, Mar 21, 2017 at 10:32 PM, Alison Schofield <amsfiel...@gmail.com> > wrote: > > > On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote: > > > > > > > >

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

On Tue, Mar 21, 2017 at 10:52:46PM +0530, Arushi Singhal wrote: > On Tue, Mar 21, 2017 at 10:32 PM, Alison Schofield > wrote: > > > On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote: > > > > > > > > > On Tue, 21 Mar 2017, Arushi Singhal wrot

Re: [Outreachy kernel] [PATCH v6] staging: Use buf_lock instead of mlock and Refactor code

On Tue, Mar 21, 2017 at 10:34:01PM +0530, SIMRAN SINGHAL wrote: > On Tue, Mar 21, 2017 at 10:18 PM, Alison Schofield <amsfiel...@gmail.com> > wrote: > > On Mon, Mar 20, 2017 at 01:36:21AM +0530, simran singhal wrote: > > > > Hi Simran, > > > > I going t

Re: [Outreachy kernel] [PATCH v6] staging: Use buf_lock instead of mlock and Refactor code

On Tue, Mar 21, 2017 at 10:34:01PM +0530, SIMRAN SINGHAL wrote: > On Tue, Mar 21, 2017 at 10:18 PM, Alison Schofield > wrote: > > On Mon, Mar 20, 2017 at 01:36:21AM +0530, simran singhal wrote: > > > > Hi Simran, > > > > I going to ask for a v7 without loo

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote: > > > On Tue, 21 Mar 2017, Arushi Singhal wrote: > > > On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield <amsfiel...@gmail.com> > > wrote: > > On Tue, Mar 21, 2017 at 07

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote: > > > On Tue, 21 Mar 2017, Arushi Singhal wrote: > > > On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield > > wrote: > > On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi Singhal wrote: > &g

Re: [Outreachy kernel] [PATCH v6] staging: Use buf_lock instead of mlock and Refactor code

On Mon, Mar 20, 2017 at 01:36:21AM +0530, simran singhal wrote: Hi Simran, I going to ask for a v7 without looking at the code ;) Subject line needs subsystem and driver. Subject and log message can be improved. > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core

Re: [Outreachy kernel] [PATCH v6] staging: Use buf_lock instead of mlock and Refactor code

On Mon, Mar 20, 2017 at 01:36:21AM +0530, simran singhal wrote: Hi Simran, I going to ask for a v7 without looking at the code ;) Subject line needs subsystem and driver. Subject and log message can be improved. > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi Singhal wrote: > Patchseries of IIO coding tasks This wouldn't be a patchset. Although they touch the same driver, the changes are unrelated. See more below... > > Arushi Singhal (2): > staging: ad7759: Replace mlock with driver private lock

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi Singhal wrote: > Patchseries of IIO coding tasks This wouldn't be a patchset. Although they touch the same driver, the changes are unrelated. See more below... > > Arushi Singhal (2): > staging: ad7759: Replace mlock with driver private lock

Re: [Outreachy kernel] [PATCH v2] staging: iio: ade7753: replace mlock with driver private lock

On Mon, Mar 13, 2017 at 10:01:07PM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH v2] staging: iio: ade7753: replace mlock with driver private lock

On Mon, Mar 13, 2017 at 10:01:07PM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH v3] staging: adis16060_core: Use private driver lock instead of mlock

On Mon, Mar 13, 2017 at 11:41:30PM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH v3] staging: adis16060_core: Use private driver lock instead of mlock

On Mon, Mar 13, 2017 at 11:41:30PM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH] staging: iio: ade7753: replace mlock with driver private lock

On Mon, Mar 13, 2017 at 09:28:34AM +0530, SIMRAN SINGHAL wrote: > On Mon, Mar 13, 2017 at 12:03 AM, Alison Schofield <amsfiel...@gmail.com> > wrote: > > On Sun, Mar 12, 2017 at 07:02:50PM +0530, simran singhal wrote: > >> The IIO subsystem is redefining iio_dev->ml

Re: [Outreachy kernel] [PATCH] staging: iio: ade7753: replace mlock with driver private lock

On Mon, Mar 13, 2017 at 09:28:34AM +0530, SIMRAN SINGHAL wrote: > On Mon, Mar 13, 2017 at 12:03 AM, Alison Schofield > wrote: > > On Sun, Mar 12, 2017 at 07:02:50PM +0530, simran singhal wrote: > >> The IIO subsystem is redefining iio_dev->mlock to be used b

Re: [Outreachy kernel] [PATCH] staging: iio: ade7753: replace mlock with driver private lock

On Sun, Mar 12, 2017 at 07:02:50PM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH] staging: iio: ade7753: replace mlock with driver private lock

On Sun, Mar 12, 2017 at 07:02:50PM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH] staging: adis16060_core: Use private driver lock instead of mlock

On Sun, Mar 12, 2017 at 06:40:52PM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH] staging: adis16060_core: Use private driver lock instead of mlock

On Sun, Mar 12, 2017 at 06:40:52PM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH] staging: adis16060_core: Use private driver lock instead of mlock

On Sun, Mar 12, 2017 at 06:40:52PM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH] staging: adis16060_core: Use private driver lock instead of mlock

On Sun, Mar 12, 2017 at 06:40:52PM +0530, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used

Re: [Outreachy kernel] [PATCH] staging: media: Remove unnecessary function and its call

On Sun, Mar 05, 2017 at 12:17:21PM +0530, simran singhal wrote: > The function atomisp_set_stop_timeout on being called, simply returns > back. The function hasn't been mentioned in the TODO and doesn't have > FIXME code around. Hence, atomisp_set_stop_timeout and its calls have been > removed. >

Re: [Outreachy kernel] [PATCH] staging: media: Remove unnecessary function and its call

On Sun, Mar 05, 2017 at 12:17:21PM +0530, simran singhal wrote: > The function atomisp_set_stop_timeout on being called, simply returns > back. The function hasn't been mentioned in the TODO and doesn't have > FIXME code around. Hence, atomisp_set_stop_timeout and its calls have been > removed. >

Re: [Outreachy kernel] [PATCH v3 4/6] staging: fbtft: Fix sparse warnings of incorrect type in assignment

On Sun, Mar 05, 2017 at 10:35:33AM +0530, simran singhal wrote: > This patch fixes the following sparse warnings: > > drivers/staging/fbtft/fbtft-io.c:74:29: warning: incorrect type in assignment > (different base types) > drivers/staging/fbtft/fbtft-io.c:74:29:expected unsigned long long >

Re: [Outreachy kernel] [PATCH v3 4/6] staging: fbtft: Fix sparse warnings of incorrect type in assignment

On Sun, Mar 05, 2017 at 10:35:33AM +0530, simran singhal wrote: > This patch fixes the following sparse warnings: > > drivers/staging/fbtft/fbtft-io.c:74:29: warning: incorrect type in assignment > (different base types) > drivers/staging/fbtft/fbtft-io.c:74:29:expected unsigned long long >

  1   2   3   4   >