[PATCH 10/14] mm/hmm: rename HMM_PFN_DEVICE_UNADDRESSABLE to HMM_PFN_DEVICE_PRIVATE

From: Jérôme Glisse Make naming consistent accross code, DEVICE_PRIVATE is the name use outside HMM code so use that one. Signed-off-by: Jérôme Glisse Cc: Evgeny Baskakov Cc: Ralph Campbell Cc: Mark Hairgrove Cc: John Hubbard --- include/linux/hmm.h | 4 ++-- mm/hmm.c| 2 +- 2

[PATCH 13/14] mm/hmm: change hmm_vma_fault() to allow write fault on page basis

From: Jérôme Glisse This change hmm_vma_fault() to not take a global write fault flag for a range but instead rely on caller to populate HMM pfns array with proper fault flag ie HMM_PFN_VALID if driver want read fault for that address or HMM_PFN_VALID and HMM_PFN_WRITE for write. Moreover by

[PATCH 14/14] mm/hmm: use device driver encoding for HMM pfn

From: Jérôme Glisse User of hmm_vma_fault() and hmm_vma_get_pfns() provide a flags array and pfn shift value allowing them to define their own encoding for HMM pfn that are fill inside the pfns array of the hmm_range struct. With this device driver can get pfn that match

[PATCH 12/14] mm/hmm: factor out pte and pmd handling to simplify hmm_vma_walk_pmd()

From: Jérôme Glisse No functional change, just create one function to handle pmd and one to handle pte (hmm_vma_handle_pmd() and hmm_vma_handle_pte()). Signed-off-by: Jérôme Glisse Cc: Evgeny Baskakov Cc: Ralph Campbell

[PATCH 14/14] mm/hmm: use device driver encoding for HMM pfn

From: Jérôme Glisse User of hmm_vma_fault() and hmm_vma_get_pfns() provide a flags array and pfn shift value allowing them to define their own encoding for HMM pfn that are fill inside the pfns array of the hmm_range struct. With this device driver can get pfn that match their own private

[PATCH 12/14] mm/hmm: factor out pte and pmd handling to simplify hmm_vma_walk_pmd()

From: Jérôme Glisse No functional change, just create one function to handle pmd and one to handle pte (hmm_vma_handle_pmd() and hmm_vma_handle_pte()). Signed-off-by: Jérôme Glisse Cc: Evgeny Baskakov Cc: Ralph Campbell Cc: Mark Hairgrove Cc: John Hubbard --- mm/hmm.c | 174

Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

> The phydrv->mdiodrv.flags can be accessible only after call to > of_phy_connect()/phy_connect(), You need to use a function like of_phy_find_device() to get the phydev, set the flag, and then call phy_connect_direct(). Andrew

Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

> The phydrv->mdiodrv.flags can be accessible only after call to > of_phy_connect()/phy_connect(), You need to use a function like of_phy_find_device() to get the phydev, set the flag, and then call phy_connect_direct(). Andrew

Re: [PATCH 2/2] usb: dwc3: add clock and resets

Hi Masahiro, I love your patch! Perhaps something to improve: [auto build test WARNING on v4.16-rc4] [also build test WARNING on next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [PATCH 2/2] usb: dwc3: add clock and resets

Hi Masahiro, I love your patch! Perhaps something to improve: [auto build test WARNING on v4.16-rc4] [also build test WARNING on next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [PATCH 13/22] signal: Move addr_lsb into the _sigfault union for clarity

On 03/16/2018 01:06 PM, Eric W. Biederman wrote: >> It does not revert cleanly so I reverted it manually. Patch doing that >> is attached. Should we do this, or is there a better option? > Please see: > 859d880cf544 ("signal: Correct the offset of si_pkey in struct siginfo") It would be really

Re: [PATCH 13/22] signal: Move addr_lsb into the _sigfault union for clarity

On 03/16/2018 01:06 PM, Eric W. Biederman wrote: >> It does not revert cleanly so I reverted it manually. Patch doing that >> is attached. Should we do this, or is there a better option? > Please see: > 859d880cf544 ("signal: Correct the offset of si_pkey in struct siginfo") It would be really

Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

On 03/16/2018 02:11 PM, Florian Fainelli wrote: > On March 16, 2018 11:42:21 AM PDT, Grygorii Strashko > wrote: >> >> >> On 03/16/2018 12:34 PM, Florian Fainelli wrote: >>> >>> >>> On 03/16/2018 10:22 AM, Andrew Lunn wrote: On Wed, Mar 14, 2018 at 05:26:22PM

Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

On 03/16/2018 02:11 PM, Florian Fainelli wrote: > On March 16, 2018 11:42:21 AM PDT, Grygorii Strashko > wrote: >> >> >> On 03/16/2018 12:34 PM, Florian Fainelli wrote: >>> >>> >>> On 03/16/2018 10:22 AM, Andrew Lunn wrote: On Wed, Mar 14, 2018 at 05:26:22PM -0500, Grygorii Strashko

[tip:perf/core] perf/core: Clear sibling list of detached events

Commit-ID: 24868367cdcac447232ebcb2aa06e1bf91291586 Gitweb: https://git.kernel.org/tip/24868367cdcac447232ebcb2aa06e1bf91291586 Author: Mark Rutland AuthorDate: Fri, 16 Mar 2018 12:51:40 + Committer: Thomas Gleixner CommitDate: Fri, 16 Mar

[tip:perf/core] perf/core: Clear sibling list of detached events

Commit-ID: 24868367cdcac447232ebcb2aa06e1bf91291586 Gitweb: https://git.kernel.org/tip/24868367cdcac447232ebcb2aa06e1bf91291586 Author: Mark Rutland AuthorDate: Fri, 16 Mar 2018 12:51:40 + Committer: Thomas Gleixner CommitDate: Fri, 16 Mar 2018 20:44:32 +0100 perf/core: Clear

[tip:perf/core] perf: Fix sibling iteration

Commit-ID: edb39592a5877bd91b2e6ee15194268f35b04892 Gitweb: https://git.kernel.org/tip/edb39592a5877bd91b2e6ee15194268f35b04892 Author: Peter Zijlstra AuthorDate: Thu, 15 Mar 2018 17:36:56 +0100 Committer: Thomas Gleixner CommitDate: Fri, 16

[tip:perf/core] perf: Fix sibling iteration

Commit-ID: edb39592a5877bd91b2e6ee15194268f35b04892 Gitweb: https://git.kernel.org/tip/edb39592a5877bd91b2e6ee15194268f35b04892 Author: Peter Zijlstra AuthorDate: Thu, 15 Mar 2018 17:36:56 +0100 Committer: Thomas Gleixner CommitDate: Fri, 16 Mar 2018 20:44:12 +0100 perf: Fix sibling

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 10:44 AM, David Laight wrote: > > I looked at the generated code for one of the constant sized VLA that > the compiler barfed at. > It seemed to subtract constants from %sp separately for the VLA. > So it looks like the compiler treats them as VLA

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 10:44 AM, David Laight wrote: > > I looked at the generated code for one of the constant sized VLA that > the compiler barfed at. > It seemed to subtract constants from %sp separately for the VLA. > So it looks like the compiler treats them as VLA even though it > knows

[PATCH 01/10] iommu/amd: take into account that alloc_dev_data() may return NULL

find_dev_data() does not check whether the return value alloc_dev_data() is NULL. This was okay once because the pointer was returned once as-is. Since commit df3f7a6e8e85 ("iommu/amd: Use is_attach_deferred call-back") the pointer may be used within find_dev_data() so a NULL check is required.

[PATCH 01/10] iommu/amd: take into account that alloc_dev_data() may return NULL

find_dev_data() does not check whether the return value alloc_dev_data() is NULL. This was okay once because the pointer was returned once as-is. Since commit df3f7a6e8e85 ("iommu/amd: Use is_attach_deferred call-back") the pointer may be used within find_dev_data() so a NULL check is required.

[PATCH 04/10] iommu/amd: split irq_lookup_table out of the amd_iommu_devtable_lock

The function get_irq_table() reads/writes irq_lookup_table while holding the amd_iommu_devtable_lock. It also modifies amd_iommu_dev_table[].data[2]. set_dte_entry() is using amd_iommu_dev_table[].data[0|1] (under the domain->lock) so it should be okay. The access to the iommu is serialized with

[PATCH 04/10] iommu/amd: split irq_lookup_table out of the amd_iommu_devtable_lock

The function get_irq_table() reads/writes irq_lookup_table while holding the amd_iommu_devtable_lock. It also modifies amd_iommu_dev_table[].data[2]. set_dte_entry() is using amd_iommu_dev_table[].data[0|1] (under the domain->lock) so it should be okay. The access to the iommu is serialized with

[PATCH 03/10] iommu/amd: split domain id out of amd_iommu_devtable_lock

domain_id_alloc() and domain_id_free() is used for id management. Those two function share a bitmap (amd_iommu_pd_alloc_bitmap) and set/clear bits based on id allocation. There is no need to share this with amd_iommu_devtable_lock, it can use its own lock for this operation. Signed-off-by:

[PATCH 03/10] iommu/amd: split domain id out of amd_iommu_devtable_lock

domain_id_alloc() and domain_id_free() is used for id management. Those two function share a bitmap (amd_iommu_pd_alloc_bitmap) and set/clear bits based on id allocation. There is no need to share this with amd_iommu_devtable_lock, it can use its own lock for this operation. Signed-off-by:

[PATCH 00/10 v2] iommu/amd: lock splitting & GFP_KERNEL allocation

The goal here is to make the memory allocation in get_irq_table() not with disabled interrupts and having as little raw_spin_lock as possible while having them if the caller is also holding one (like desc->lock during IRQ-affinity changes). I reverted one patch one patch in the iommu while

[PATCH 00/10 v2] iommu/amd: lock splitting & GFP_KERNEL allocation

The goal here is to make the memory allocation in get_irq_table() not with disabled interrupts and having as little raw_spin_lock as possible while having them if the caller is also holding one (like desc->lock during IRQ-affinity changes). I reverted one patch one patch in the iommu while

[PATCH 02/10] iommu/amd: turn dev_data_list into a lock less list

alloc_dev_data() adds new items to dev_data_list and search_dev_data() is searching for items in this list. Both protect the access to the list with a spinlock. There is no need to navigate forth and back within the list and there is also no deleting of a specific item. This qualifies the list to

[PATCH 02/10] iommu/amd: turn dev_data_list into a lock less list

alloc_dev_data() adds new items to dev_data_list and search_dev_data() is searching for items in this list. Both protect the access to the list with a spinlock. There is no need to navigate forth and back within the list and there is also no deleting of a specific item. This qualifies the list to

[PATCH 07/10] iommu/amd: use `table' instead `irt' as variable name in amd_iommu_update_ga()

The variable of type struct irq_remap_table is always named `table' except in amd_iommu_update_ga() where it is called `irt'. Make it consistent and name it also `table'. Signed-off-by: Sebastian Andrzej Siewior --- drivers/iommu/amd_iommu.c | 10 +- 1 file

[PATCH 08/10] iommu/amd: factor out setting the remap table for a devid

Setting the IRQ remap table for a specific devid (or its alias devid) includes three steps. Those three steps are always repeated each time this is done. Introduce a new helper function, move those steps there and use that function instead. The compiler can still decide if it is worth to inline.

[PATCH 07/10] iommu/amd: use `table' instead `irt' as variable name in amd_iommu_update_ga()

The variable of type struct irq_remap_table is always named `table' except in amd_iommu_update_ga() where it is called `irt'. Make it consistent and name it also `table'. Signed-off-by: Sebastian Andrzej Siewior --- drivers/iommu/amd_iommu.c | 10 +- 1 file changed, 5 insertions(+), 5

[PATCH 08/10] iommu/amd: factor out setting the remap table for a devid

Setting the IRQ remap table for a specific devid (or its alias devid) includes three steps. Those three steps are always repeated each time this is done. Introduce a new helper function, move those steps there and use that function instead. The compiler can still decide if it is worth to inline.

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 1:14 PM, Linus Torvalds wrote: > > It does not work with gcc-4.1.x, but works with gcc-4.4.x. > > I can't seem to see the errors any way, I wonder if > __builtin_choose_expr() simply didn't exist back then. No, that goes further back. It

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 1:14 PM, Linus Torvalds wrote: > > It does not work with gcc-4.1.x, but works with gcc-4.4.x. > > I can't seem to see the errors any way, I wonder if > __builtin_choose_expr() simply didn't exist back then. No, that goes further back. It seems to be -Wvla itself that

Re: [RFC PATCH] iio: adc: Add Xilinx AMS driver

On Thu, Mar 15, 2018 at 08:12:27PM +0530, Manish Narani wrote: > The AMS includes an ADC as well as on-chip sensors that can be used to > sample external voltages and monitor on-die operating conditions, such as > temperature and supply voltage levels. The AMS has two SYSMON blocks. > PL-SYSMON

Re: [RFC PATCH] iio: adc: Add Xilinx AMS driver

On Thu, Mar 15, 2018 at 08:12:27PM +0530, Manish Narani wrote: > The AMS includes an ADC as well as on-chip sensors that can be used to > sample external voltages and monitor on-die operating conditions, such as > temperature and supply voltage levels. The AMS has two SYSMON blocks. > PL-SYSMON

[PATCH 09/10] iommu/amd: drop the lock while allocating new irq remap table

The irq_remap_table is allocated while the iommu_table_lock is held with interrupts disabled. While this works it makes RT scream very loudly. >From looking at the call sites, all callers are in the early device initialisation (apic_bsp_setup(), pci_enable_device(), pci_enable_msi()) so make sense

[PATCH 10/10] iommu/amd: make amd_iommu_devtable_lock a spin_lock

Before commit 0bb6e243d7fb ("iommu/amd: Support IOMMU_DOMAIN_DMA type allocation") amd_iommu_devtable_lock had a read_lock() user but now there are none. In fact, after the mentioned commit we had only write_lock() user of the lock. Since there is no reason to keep it as writer lock, change its

[PATCH 09/10] iommu/amd: drop the lock while allocating new irq remap table

The irq_remap_table is allocated while the iommu_table_lock is held with interrupts disabled. While this works it makes RT scream very loudly. >From looking at the call sites, all callers are in the early device initialisation (apic_bsp_setup(), pci_enable_device(), pci_enable_msi()) so make sense

[PATCH 10/10] iommu/amd: make amd_iommu_devtable_lock a spin_lock

Before commit 0bb6e243d7fb ("iommu/amd: Support IOMMU_DOMAIN_DMA type allocation") amd_iommu_devtable_lock had a read_lock() user but now there are none. In fact, after the mentioned commit we had only write_lock() user of the lock. Since there is no reason to keep it as writer lock, change its

[PATCH 06/10] iommu/amd: remove the special case from get_irq_table()

get_irq_table() has a special ioapic argument. If set then it will pre-allocate / reserve the first 32 indexes. The argument is only once true and it would make get_irq_table() a little simpler if we would extract the special bits to the caller. Signed-off-by: Sebastian Andrzej Siewior

[PATCH 06/10] iommu/amd: remove the special case from get_irq_table()

get_irq_table() has a special ioapic argument. If set then it will pre-allocate / reserve the first 32 indexes. The argument is only once true and it would make get_irq_table() a little simpler if we would extract the special bits to the caller. Signed-off-by: Sebastian Andrzej Siewior ---

[PATCH 05/10] Revert "iommu/amd: Avoid locking get_irq_table() from atomic context"

This reverts commit df42a04b15f1 ("iommu/amd: Avoid locking get_irq_table() from atomic context"). Its goal is to avoid a warning/bug on RT. While I generally support that goal this change is colliding with larger rework which accomplishes the same goal but different. Cc: Scott Wood

[PATCH 05/10] Revert "iommu/amd: Avoid locking get_irq_table() from atomic context"

This reverts commit df42a04b15f1 ("iommu/amd: Avoid locking get_irq_table() from atomic context"). Its goal is to avoid a warning/bug on RT. While I generally support that goal this change is colliding with larger rework which accomplishes the same goal but different. Cc: Scott Wood

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 01:15:27PM -0700, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 1:12 PM, Al Viro wrote: > > > > That's C99, straight from N1256.pdf (C99-TC3)... > > I checked C90, since the error is > >ISO C90 forbids variable length array > > and I

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 01:15:27PM -0700, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 1:12 PM, Al Viro wrote: > > > > That's C99, straight from N1256.pdf (C99-TC3)... > > I checked C90, since the error is > >ISO C90 forbids variable length array > > and I didn't see anything there.

Re: [PATCH -next 00/22] remove in-kernel syscall invocations (part 2 == netdev)

On Fri, Mar 16, 2018 at 02:30:21PM -0400, David Miller wrote: > From: Dominik Brodowski > Date: Fri, 16 Mar 2018 18:05:52 +0100 > > > The rationale of this change is described in patch 1 of part 1[*] as > > follows: > > > > The syscall entry points to the kernel

Re: [PATCH -next 00/22] remove in-kernel syscall invocations (part 2 == netdev)

On Fri, Mar 16, 2018 at 02:30:21PM -0400, David Miller wrote: > From: Dominik Brodowski > Date: Fri, 16 Mar 2018 18:05:52 +0100 > > > The rationale of this change is described in patch 1 of part 1[*] as > > follows: > > > > The syscall entry points to the kernel defined by

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 1:12 PM, Al Viro wrote: > > That's C99, straight from N1256.pdf (C99-TC3)... I checked C90, since the error is ISO C90 forbids variable length array and I didn't see anything there. Admittedly I only found a draft copy.

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 1:12 PM, Al Viro wrote: > > That's C99, straight from N1256.pdf (C99-TC3)... I checked C90, since the error is ISO C90 forbids variable length array and I didn't see anything there. Admittedly I only found a draft copy. Linus

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 1:03 PM, Miguel Ojeda wrote: >> >> Kees - is there some online "gcc-4.4 checker" somewhere? This does >> seem to work with my gcc. I actually tested some of those files you >> pointed at now. > > I use this one: > > https://godbolt.org/

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 1:03 PM, Miguel Ojeda wrote: >> >> Kees - is there some online "gcc-4.4 checker" somewhere? This does >> seem to work with my gcc. I actually tested some of those files you >> pointed at now. > > I use this one: > > https://godbolt.org/ Well, my *test* code works on

Re: [PATCH v2] netns: send uevent messages

On 16.03.2018 15:50, Christian Brauner wrote: > This patch adds a receive method to NETLINK_KOBJECT_UEVENT netlink sockets > to allow sending uevent messages into the network namespace the socket > belongs to. > > Currently non-initial network namespaces are already isolated and don't > receive

Re: [PATCH v2] netns: send uevent messages

On 16.03.2018 15:50, Christian Brauner wrote: > This patch adds a receive method to NETLINK_KOBJECT_UEVENT netlink sockets > to allow sending uevent messages into the network namespace the socket > belongs to. > > Currently non-initial network namespaces are already isolated and don't > receive

Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

On 03/16/2018 02:54 PM, Andrew Lunn wrote: >> The phydrv->mdiodrv.flags can be accessible only after call to >> of_phy_connect()/phy_connect(), > > You need to use a function like of_phy_find_device() to get the > phydev, set the flag, and then call phy_connect_direct(). So, do you propose

Re: [PATCH 0/2] net: phy: relax error checking when creating sysfs link netdev->phydev

On 03/16/2018 02:54 PM, Andrew Lunn wrote: >> The phydrv->mdiodrv.flags can be accessible only after call to >> of_phy_connect()/phy_connect(), > > You need to use a function like of_phy_find_device() to get the > phydev, set the flag, and then call phy_connect_direct(). So, do you propose

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 12:27:23PM -0700, Linus Torvalds wrote: > But it sure isn't "variable" either as far as the standard is > concerned, because the standard doesn't even have that concept (it > uses "variable" for argument numbers and for variables). Huh? 6.7.5.2p4: If the size is not

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 12:27:23PM -0700, Linus Torvalds wrote: > But it sure isn't "variable" either as far as the standard is > concerned, because the standard doesn't even have that concept (it > uses "variable" for argument numbers and for variables). Huh? 6.7.5.2p4: If the size is not

[PATCH v2 2/9] Staging: iio: accel: adis16201: Remove unnecessary comments

Remove few unnecessary comments since the macro definitions clearly justify their purpose. Signed-off-by: Himanshu Jha --- v2: -reodered patch series. drivers/staging/iio/accel/adis16201.c | 36 --- 1 file changed, 36 deletions(-)

[PATCH v2 2/9] Staging: iio: accel: adis16201: Remove unnecessary comments

Remove few unnecessary comments since the macro definitions clearly justify their purpose. Signed-off-by: Himanshu Jha --- v2: -reodered patch series. drivers/staging/iio/accel/adis16201.c | 36 --- 1 file changed, 36 deletions(-) diff --git

[PATCH v2 3/9] Staging: iio: accel: adis16201: Add _REG suffix to reisters

Add a _REG suffix to distinguish between registers and the register bit fileds. Signed-off-by: Himanshu Jha --- v2: -reordered patch series. drivers/staging/iio/accel/adis16201.c | 84 +-- 1 file changed, 42 insertions(+), 42

[PATCH v2 3/9] Staging: iio: accel: adis16201: Add _REG suffix to reisters

Add a _REG suffix to distinguish between registers and the register bit fileds. Signed-off-by: Himanshu Jha --- v2: -reordered patch series. drivers/staging/iio/accel/adis16201.c | 84 +-- 1 file changed, 42 insertions(+), 42 deletions(-) diff --git

[PATCH v2 6/9] Staging: iio: accel: adis16201: Use sign_extend32 function

Use sign_extned32() for 32 bit sign extending rather than hard coding. Signed-off-by: Himanshu Jha --- v2: -no change in this patch. drivers/staging/iio/accel/adis16201.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

[PATCH v2 6/9] Staging: iio: accel: adis16201: Use sign_extend32 function

Use sign_extned32() for 32 bit sign extending rather than hard coding. Signed-off-by: Himanshu Jha --- v2: -no change in this patch. drivers/staging/iio/accel/adis16201.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/iio/accel/adis16201.c

[PATCH v2 5/9] Staging: iio: accel: adis16201: Add comments about units in read_raw()

Clarify the conversion and formation of resultant data in the adis16201_read_raw() with sufficient comments and remove the unnecessary comments. Signed-off-by: Himanshu Jha --- v2: -clarify voltage base conversions. drivers/staging/iio/accel/adis16201.c | 27

[PATCH v2 5/9] Staging: iio: accel: adis16201: Add comments about units in read_raw()

Clarify the conversion and formation of resultant data in the adis16201_read_raw() with sufficient comments and remove the unnecessary comments. Signed-off-by: Himanshu Jha --- v2: -clarify voltage base conversions. drivers/staging/iio/accel/adis16201.c | 27 ++- 1

[PATCH v2 8/9] Staging: iio: accel: adis16201: Adjust argument to match open parentheses

In adis16201_read_raw() adjust an argument to match an open parentheses using tabs and spaces. Signed-off-by: Himanshu Jha --- v2: -aligned perfectly to match open parentheses. drivers/staging/iio/accel/adis16201.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 8/9] Staging: iio: accel: adis16201: Adjust argument to match open parentheses

In adis16201_read_raw() adjust an argument to match an open parentheses using tabs and spaces. Signed-off-by: Himanshu Jha --- v2: -aligned perfectly to match open parentheses. drivers/staging/iio/accel/adis16201.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 7/9] Staging: iio: accel: adis16201: Prefer reverse christmas tree ordering

Prefer reverse christmas tree ordering of declarations to improve readability. Signed-off-by: Himanshu Jha --- v2: -no change in this patch. drivers/staging/iio/accel/adis16201.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v2 7/9] Staging: iio: accel: adis16201: Prefer reverse christmas tree ordering

Prefer reverse christmas tree ordering of declarations to improve readability. Signed-off-by: Himanshu Jha --- v2: -no change in this patch. drivers/staging/iio/accel/adis16201.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/iio/accel/adis16201.c

[PATCH v2 4/9] Staging: iio: accel: adis16201: Group register definitions

Group register definitions with its register field bits to improve readability and easy identification. A small comment is also added to denote the purpose/functionality of the grouped register definitions. Signed-off-by: Himanshu Jha --- v2: -reordered patch

[PATCH v2 4/9] Staging: iio: accel: adis16201: Group register definitions

Group register definitions with its register field bits to improve readability and easy identification. A small comment is also added to denote the purpose/functionality of the grouped register definitions. Signed-off-by: Himanshu Jha --- v2: -reordered patch series.

[PATCH v2 9/9] Staging: iio: accel: adis16201: Move adis16201 driver out of staging

Move the adis16201 driver out of staging directory and merge to the mainline IIO subsystem. Signed-off-by: Himanshu Jha --- v2: -no change in this patch. drivers/iio/accel/Kconfig | 12 ++ drivers/iio/accel/Makefile| 1 +

Re: [PATCH 13/22] signal: Move addr_lsb into the _sigfault union for clarity

Dave Hansen writes: > On 03/16/2018 12:00 PM, Dave Hansen wrote: >> On 01/15/2018 04:40 PM, Eric W. Biederman wrote: >>> The addr_lsb fields is only valid and available when the >>> signal is SIGBUS and the si_code is BUS_MCEERR_AR or BUS_MCEERR_AO. >>> Document this with

[PATCH v2 9/9] Staging: iio: accel: adis16201: Move adis16201 driver out of staging

Move the adis16201 driver out of staging directory and merge to the mainline IIO subsystem. Signed-off-by: Himanshu Jha --- v2: -no change in this patch. drivers/iio/accel/Kconfig | 12 ++ drivers/iio/accel/Makefile| 1 + drivers/iio/accel/adis16201.c |

Re: [PATCH 13/22] signal: Move addr_lsb into the _sigfault union for clarity

Dave Hansen writes: > On 03/16/2018 12:00 PM, Dave Hansen wrote: >> On 01/15/2018 04:40 PM, Eric W. Biederman wrote: >>> The addr_lsb fields is only valid and available when the >>> signal is SIGBUS and the si_code is BUS_MCEERR_AR or BUS_MCEERR_AO. >>> Document this with a comment and place the

[PATCH v2 1/9] Staging: iio: accel: adis16201: Rename few macro definitions

Rename the macro definitions with suitable names specifying their purpose. * ADIS16201_STARTUP_DELAY_MS: Remove the comment specifying the delay in microseconds and rename it with addtition of _MS suffix. * ADIS16201_MSC_CTRL_ACTIVE_DATA_RDY_HIGH: Rename the macro to make it similar to other

[PATCH v2 1/9] Staging: iio: accel: adis16201: Rename few macro definitions

Rename the macro definitions with suitable names specifying their purpose. * ADIS16201_STARTUP_DELAY_MS: Remove the comment specifying the delay in microseconds and rename it with addtition of _MS suffix. * ADIS16201_MSC_CTRL_ACTIVE_DATA_RDY_HIGH: Rename the macro to make it similar to other

[PATCH v2 0/9] Staging: iio: accel: adis16201 driver cleanup

The following patch series cleans up miscellaneous code fragments and then the driver is moved from staging to mainline IIO subsytem directory. Note that the last patch to move driver is *not* generated using '-M' flag, which is used for detecting renames, since it may help reviewers to suggest

[PATCH v2 0/9] Staging: iio: accel: adis16201 driver cleanup

The following patch series cleans up miscellaneous code fragments and then the driver is moved from staging to mainline IIO subsytem directory. Note that the last patch to move driver is *not* generated using '-M' flag, which is used for detecting renames, since it may help reviewers to suggest

Re: [PATCH v6 2/2] hwmon: (ucd9000) Add debugfs attributes to provide mfr_status

On 03/16/2018 02:59 PM, Guenter Roeck wrote: On Fri, Mar 16, 2018 at 02:25:59PM -0500, Eddie James wrote: From: Christopher Bostic Expose the gpiN_fault fields of mfr_status as individual debugfs attributes. This provides a way for users to be easily notified of

Re: [PATCH v6 2/2] hwmon: (ucd9000) Add debugfs attributes to provide mfr_status

On 03/16/2018 02:59 PM, Guenter Roeck wrote: On Fri, Mar 16, 2018 at 02:25:59PM -0500, Eddie James wrote: From: Christopher Bostic Expose the gpiN_fault fields of mfr_status as individual debugfs attributes. This provides a way for users to be easily notified of gpi faults. Also provide the

Re: [PATCH 4.14 000/109] 4.14.28-stable review

On 16 March 2018 at 20:52, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.28 release. > There are 109 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: [PATCH 4.14 000/109] 4.14.28-stable review

On 16 March 2018 at 20:52, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.28 release. > There are 109 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > >

Re: [PATCH -next 00/22] remove in-kernel syscall invocations (part 2 == netdev)

On Fri, Mar 16, 2018 at 11:30 AM, David Miller wrote: > > I imagine one of the things you'd like to do is declare that syscall > entries use a different (better) argument passing scheme. For > example, passing values in registers instead of on the stack. Actually, it's

Re: [PATCH -next 00/22] remove in-kernel syscall invocations (part 2 == netdev)

On Fri, Mar 16, 2018 at 11:30 AM, David Miller wrote: > > I imagine one of the things you'd like to do is declare that syscall > entries use a different (better) argument passing scheme. For > example, passing values in registers instead of on the stack. Actually, it's almost exactly the

Re: [PATCH][RFC] kernel.h: provide array iterator

Proper form for iteration over an array is below: int a[] = {1, 2, 3, 5}; for (int x: a) { ... } Your macro forces an iterator to be pointer which is uh-oh.

Re: [PATCH][RFC] kernel.h: provide array iterator

Proper form for iteration over an array is below: int a[] = {1, 2, 3, 5}; for (int x: a) { ... } Your macro forces an iterator to be pointer which is uh-oh.

Re: [PATCH 7/7] staging:iio:ade7854: Add proper error handling condition

On 03/16, Dan Carpenter wrote: > Generally, it's better to fix the bug in the existing code, and then > do the cleanup later. That way the fixes can be backported to stable > kernels more easily. Hummm... the backport argue make a lot of sense for me. I will generate a v2 with the bug fixes in

Re: [PATCH 7/7] staging:iio:ade7854: Add proper error handling condition

On 03/16, Dan Carpenter wrote: > Generally, it's better to fix the bug in the existing code, and then > do the cleanup later. That way the fixes can be backported to stable > kernels more easily. Hummm... the backport argue make a lot of sense for me. I will generate a v2 with the bug fixes in

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 8:27 PM, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 10:55 AM, Al Viro wrote: >> >> That's not them, that's C standard regarding ICE. > > Yes. The C standard talks about "integer constant expression". I know. >

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 8:27 PM, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 10:55 AM, Al Viro wrote: >> >> That's not them, that's C standard regarding ICE. > > Yes. The C standard talks about "integer constant expression". I know. > It's come up in this very thread before. > > The C

[tip:x86/pti] x86/microcode: Fix CPU synchronization routine

Commit-ID: bb8c13d61a629276a162c1d2b1a20a815cbcfbb7 Gitweb: https://git.kernel.org/tip/bb8c13d61a629276a162c1d2b1a20a815cbcfbb7 Author: Borislav Petkov AuthorDate: Wed, 14 Mar 2018 19:36:15 +0100 Committer: Thomas Gleixner CommitDate: Fri, 16 Mar 2018

[tip:x86/pti] x86/microcode: Fix CPU synchronization routine

Commit-ID: bb8c13d61a629276a162c1d2b1a20a815cbcfbb7 Gitweb: https://git.kernel.org/tip/bb8c13d61a629276a162c1d2b1a20a815cbcfbb7 Author: Borislav Petkov AuthorDate: Wed, 14 Mar 2018 19:36:15 +0100 Committer: Thomas Gleixner CommitDate: Fri, 16 Mar 2018 20:55:51 +0100 x86/microcode: Fix

[tip:x86/pti] x86/microcode: Attempt late loading only when new microcode is present

Commit-ID: 2613f36ed965d0e5a595a1d931fd3b480e82d6fd Gitweb: https://git.kernel.org/tip/2613f36ed965d0e5a595a1d931fd3b480e82d6fd Author: Borislav Petkov AuthorDate: Wed, 14 Mar 2018 19:36:14 +0100 Committer: Thomas Gleixner CommitDate: Fri, 16 Mar 2018

[tip:x86/pti] x86/microcode: Attempt late loading only when new microcode is present

Commit-ID: 2613f36ed965d0e5a595a1d931fd3b480e82d6fd Gitweb: https://git.kernel.org/tip/2613f36ed965d0e5a595a1d931fd3b480e82d6fd Author: Borislav Petkov AuthorDate: Wed, 14 Mar 2018 19:36:14 +0100 Committer: Thomas Gleixner CommitDate: Fri, 16 Mar 2018 20:55:51 +0100 x86/microcode:

Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs

On Fri 16 Mar 11:26 PDT 2018, Stephen Boyd wrote: > Quoting Bjorn Andersson (2018-03-07 11:02:49) > > On Tue 06 Mar 07:57 PST 2018, Lina Iyer wrote: > > > > > On Mon, Mar 05 2018 at 16:15 -0700, Bjorn Andersson wrote: > > > > On Mon 26 Feb 09:58 PST 2018, Lina Iyer wrote: > > > > > > As such I

Re: [PATCH v4 2/2] dt-bindings: introduce Command DB for QCOM SoCs

On Fri 16 Mar 11:26 PDT 2018, Stephen Boyd wrote: > Quoting Bjorn Andersson (2018-03-07 11:02:49) > > On Tue 06 Mar 07:57 PST 2018, Lina Iyer wrote: > > > > > On Mon, Mar 05 2018 at 16:15 -0700, Bjorn Andersson wrote: > > > > On Mon 26 Feb 09:58 PST 2018, Lina Iyer wrote: > > > > > > As such I

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