[PATCH 1/1] i40iw: do not print unitialized variables in error message

i40iw_create_cqp() printed the contents of variables maj_err and min_err in an error message before they could be initialized (by calling dev->cqp_ops->cqp_create). Signed-off-by: Nicolas Iooss --- drivers/infiniband/hw/i40iw/i40iw_main.c | 3 +-- 1 file changed, 1

[PATCH] cpu_pm :Dummy cpu_pm_register_notifier should return error code.

The inline cpu_pm_register_notifier stub simply allows compilation on systems with CONFIG_CPU_PM disabled. The dummy cpu_pm_register_notifier does not register an trap_pm_init, r4k_tlb_init_pm and r4k_cache_init_pm at all.The inline cpu_pm_register_notifier should return to indicate lack of

[PATCH 1/2] net: ethernet: dwc_eth_qos: use phydev from struct net_device

The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by: Philippe Reynes ---

[PATCH 2/2] net: ethernet: dwc_eth_qos: use phy_ethtool_{get|set}_link_ksettings

There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/synopsys/dwc_eth_qos.c | 26 ++ 1 files changed, 2

Re: [PATCH] firmware: declare __{start,end}_builtin_fw as pointers

On 25 June 2016 at 17:04, Vegard Nossum wrote: > The test in this loop: > > for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) { > > was getting completely compiled out by my gcc, 7.0.0 20160520. The result > was that the loop was going beyond the end of

Re: [PATCH 1/8] tty: serial: fsl_lpuart: consider TX FIFO too in tx_empty

On Thu, Jun 09, 2016 at 08:40:32PM +0530, Bhuvanchandra DV wrote: > From: Stefan Agner > > Currently the tx_empty callback only considers the Transmit Complete > Flag (TC). The reference manual is not quite clear if the TC flag > covers the TX FIFO too. Debug prints on real

[PATCH v3 06/24] fs: jfs: Replace CURRENT_TIME_SEC by current_time()

jfs uses nanosecond granularity for filesystem timestamps. Only this assignment is not using nanosecond granularity. Use current_time() to get the right granularity. Signed-off-by: Deepa Dinamani Cc: Dave Kleikamp Cc:

[PATCH v3 10/24] fs: udf: Replace CURRENT_TIME with current_time()

CURRENT_TIME is not y2038 safe. CURRENT_TIME macro is also not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Logical Volume Integrity format is described to have the same timestamp format for "Recording Date and time" as the other

[PATCH v3 13/24] fs: cifs: Replace CURRENT_TIME by get_seconds

This is in preparation for the change that transitions filesystem timestamps to use 64 bit time and hence make them y2038 safe. CURRENT_TIME macro will be deleted before merging the aforementioned patch. Filesystems will use current_time() instead of CURRENT_TIME. Use ktime_get_real_seconds()

[PATCH v3 09/24] fs: btrfs: Use ktime_get_real_ts for root ctime

btrfs_root_item maintains the ctime for root updates. This is not part of vfs_inode. Since current_time() uses struct inode* as an argument as Linus suggested, this cannot be used to update root times unless, we modify the signature to use inode. Since btrfs uses nanosecond time granularity, it

[PATCH v3 14/24] fs: f2fs: Use ktime_get_real_seconds for sit_info times

CURRENT_TIME_SEC is not y2038 safe. Replace use of CURRENT_TIME_SEC with ktime_get_real_seconds in segment timestamps used by GC algorithm including the segment mtime timestamps. Signed-off-by: Deepa Dinamani Cc: Jaegeuk Kim Cc: Changman Lee

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Sat, Jun 25, 2016 at 4:19 PM, Andy Lutomirski wrote: > I rebased my series onto your tree and then rebased this thing onto my > series, tweaked it some, and split it up a bit. My version works a > bit differently (thread_info has a single element if the new option is >

Re: [RFC] kref: pin objects with dangerously high reference count

On 25 Jun 2016 at 3:13, Jann Horn wrote: > Since 2009 or so, PaX had reference count overflow mitigation code. My main > reasons for reinventing the wheel are: > > - PaX adds arch-specific code, both in the atomic_t operations and in >exception handlers. I'd like to keep the code as >

Re: [PATCH v2] libnvdimm, nfit: treat volatile virtual CD region as pmem

On Sat, Jun 25, 2016 at 5:21 AM, joeyli wrote: > iOn Fri, Jun 24, 2016 at 10:59:56AM -0700, Dan Williams wrote: >> On Fri, Jun 24, 2016 at 12:51 AM, Lee, Chun-Yi >> wrote: >> > This patch adds logic to treat volatile virtual CD region as pmem >> > region,

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

Hello! On Jun 17, 2016, at 12:29 AM, Al Viro wrote: > On Fri, Jun 17, 2016 at 12:09:19AM -0400, Oleg Drokin wrote: > >>So they both do d_drop(), the dentry is now unhashed, and they both >>dive into nfs_lookup(). >>There eventually they both call >> >> res =

Re: [patch V4 27/31] serial: use parity32 in max3100

On Wed, May 11, 2016 at 05:23:07PM +0800, zengzhao...@163.com wrote: > From: Zhaoxiu Zeng > > Signed-off-by: Zhaoxiu Zeng > Acked-by: Greg Kroah-Hartman > --- > drivers/tty/serial/max3100.c | 2 +- > 1 file changed, 1

[PATCH 1/2] ipc/sem.c: Fix complex_count vs. simple op race

Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a race: sem_lock has a fast path that allows parallel simple operations. There are two reasons why a simple operation cannot run in parallel: - a non-simple operations is ongoing (sma->sem_perm.lock held) - a complex operation is

[PATCH 2/2] ipc/sem: sem_lock with hysteresis

sysv sem has two lock modes: One with per-semaphore locks, one lock mode with a single big lock for the whole array. When switching from the per-semaphore locks to the big lock, all per-semaphore locks must be scanned for ongoing operations. The patch adds a hysteresis for switching from the big

[PATCH 0/2] ipc/sem.c: sem_lock fixes

Hi Andrew, Hi Peter, next version of the sem_lock() fixes / improvement: The patches are now vs. tip. Patch 1 is ready for merging, patch 2 is new and for discussion. Patch 1 fixes the race that was found by Felix. It also adds smp_mb() to fully synchronize WRITE_ONCE(status, 1);

Re: [PATCH 2/2] ipc/sem: sem_lock with hysteresis

On 06/21/2016 10:29 PM, Davidlohr Bueso wrote: On Sat, 18 Jun 2016, Manfred Spraul wrote: sysv sem has two lock modes: One with per-semaphore locks, one lock mode with a single big lock for the whole array. When switching from the per-semaphore locks to the big lock, all per-semaphore locks

Re: [PATCH] of_mdio: select fixed phy support unconditionally

On 06/24/16 02:24, Arnd Bergmann wrote: > Calling the fixed-phy functions when CONFIG_FIXED_PHY=m as a previous > change tried cannot work if the caller is in built-in code: > > drivers/of/built-in.o: In function `of_phy_register_fixed_link': > of_reserved_mem.c:(.text+0x85e0): undefined

Re: Freeing active kobject in pps_device_destruct

On 27 November 2015 at 05:30, Sasha Levin wrote: > Hi, > > Fuzzing with syzkaller on the latest -next kernel produced this error: > > [ 1167.390182] WARNING: CPU: 14 PID: 607 at lib/debugobjects.c:263 > debug_print_object+0x1c4/0x1e0() > (active state 0) object type:

[PATCH 2/5] PM / devfreq: make devfreq-event explicitly non-modular

The Kconfig currently controlling compilation of this code is: menuconfig PM_DEVFREQ_EVENT bool "DEVFREQ-Event device Support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the

[PATCH 1/5] PM / devfreq: make devfreq explicitly non-modular

The Kconfig currently controlling compilation of this code is: menuconfig PM_DEVFREQ bool "Generic Dynamic Voltage and Frequency Scaling (DVFS) support" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so

[PATCH 3/5] PM / devfreq: make exynos-bus ARM_EXYNOS_BUS_DEVFREQ tristate

The Kconfig currently controlling compilation of this code is: devfreq/Kconfig:config ARM_EXYNOS_BUS_DEVFREQ devfreq/Kconfig:bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver" ...meaning that it currently is not being built as a module by anyone. Rather than rip out the existing

[PATCH 4/5] PM / devfreq: make event/exynos-nocp DEVFREQ_EVENT_EXYNOS_NOCP tristate

The Kconfig currently controlling compilation of this code is: event/Kconfig:config DEVFREQ_EVENT_EXYNOS_NOCP event/Kconfig: bool "EXYNOS NoC (Network On Chip) Probe DEVFREQ event Driver" ...meaning that it currently is not being built as a module by anyone. Rather than rip out the existing

[PATCH 1/2] net: ethernet: r6040: use phydev from struct net_device

The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by: Philippe Reynes ---

[PATCH 2/2] net: ethernet: r6040: use phy_ethtool_{get|set}_link_ksettings

There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/rdc/r6040.c | 14 ++ 1 files changed, 2 insertions(+), 12

Re: [PATCH 4/4] tty/serial: atmel: enforce tasklet init and termination sequences

On Fri, Jun 17, 2016 at 12:05:49PM +0200, Nicolas Ferre wrote: > As some race conditions are identified in the termination process of tasklets, > enforce the atmel_shutdown() sequence. This way we make sure that no new > tasklets or software timer are scheduled during shutdown process. > > An

[PATCH] ARM: dts: vf-colibri: specify panel supply

The display panel is powered by the Carrier board's 3.3V rail. Signed-off-by: Stefan Agner --- arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi

Re: [PATCH v3 4/8] rtc: ac100: Add RTC driver for X-Powers AC100

Hi, A few comments, mostly about style. On 20/06/2016 at 10:52:14 +0800, Chen-Yu Tsai wrote : > +struct ac100_rtc_dev { > + struct rtc_device *rtc; > + struct device *dev; > + struct regmap *regmap; > + struct mutex mutex; I don't think that mutex is needed. Instead, you can

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sat, Jun 25, 2016 at 06:09:22PM +0200, Peter Zijlstra wrote: > On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote: > > > > > > int vpc = vcpu_preempt_count(); > > > > > > ... > > > > > > for (;;) { > > > > > > /* the big spin loop */ > > > > > > if

Re: 4.6.2 frequent crashes under memory + IO pressure

Johannes Stezenbach wrote: > On Thu, Jun 23, 2016 at 08:26:35PM +0900, Tetsuo Handa wrote: > > > > Since you think you saw OOM messages with the older kernels, I assume that > > the OOM > > killer was invoked on your 4.6.2 kernel. The OOM reaper in Linux 4.6 and > > Linux 4.7 > > will not help

Re: [PATCH 1/2] net: ethernet: ethoc: use phydev from struct net_device

On Sat, Jun 25, 2016 at 04:33:41PM +0200, Philippe Reynes wrote: > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phy in the private structure, and update the driver to use the > one contained in struct

[PATCH v3 01/24] vfs: Add current_time() api

current_fs_time() is used for inode timestamps. Change the signature of the function to take inode pointer instead of superblock as per Linus's suggestion. Also, move the api under vfs as per the discussion on the thread: https://lkml.org/lkml/2016/6/9/36 . As per Arnd's suggestion on the

[PATCH v3 05/24] fs: Replace current_fs_time() with current_time()

current_fs_time() uses struct super_block* as an argument. As per Linus's suggestion, this is changed to take struct inode* as a parameter instead. This is because the function is primarily meant for vfs inode timestamps. Also the function was renamed as per Arnd's suggestion. Change all calls to

[PATCH v3 12/24] fs: cifs: Replace CURRENT_TIME with ktime_get_real_ts()

This is in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make them y2038 safe. CURRENT_TIME macro will be deleted before merging the aforementioned patch. Filesystem times will use current_fs_time() instead of CURRENT_TIME. Use ktime_get_real_ts() here as

[PATCH v3 07/24] fs: ext4: Use current_time() for inode timestamps

CURRENT_TIME_SEC and CURRENT_TIME are not y2038 safe. current_time() will be transitioned to be y2038 safe along with vfs. current_time() returns timestamps according to the granularities set in the super_block. The granularity check in ext4_current_time() to call current_time() or

Re: [PATCH v2 1/2] staging: wilc1000: fix error handling in wilc_debugfs_init()

On 25/06/16 22:36, Greg KH wrote: > On Thu, Jun 23, 2016 at 01:36:17PM +0100, Luis de Bethencourt wrote: >> The common format to check if a function returned an error pointer is to >> use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors. >> >> Signed-off-by: Luis de Bethencourt

[PATCH v3 11/24] fs: cifs: Replace CURRENT_TIME by current_time()

CURRENT_TIME macro is not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Use current_time() instead. This is also in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make them y2038 safe. CURRENT_TIME macro

[RFC PATCH v2] MAINTAINERS: remove unreachable people that have left Atmel

When sending an email regarding a patch to wilc1000, you get the following automatic replies: "Sung_hoon Cho is no longer with Atmel Corporation." "Kang_hee Park is no longer with Atmel Corporation." "Dong_ho Shin is no longer with Atmel Corporation." "Bo_moon Kim is no longer with Atmel

Re: [PATCH 1/2] mn10300: use RTC_DRV_CMOS instead of CONFIG_RTC

On 01/06/2016 at 16:46:22 +0200, Arnd Bergmann wrote : > nn10300 has a dependency on mc146818_get_time/mc146818_set_time, > which we want to move from the mc146818rtc.h header into the > rtc subsystem, which in turn is not usable on mn10300. > > This changes mn10300 to use the modern rtc-cmos

[PATCH 0/4][RFC v2] x86, hotplug: Use hlt instead of mwait when resuming from hibernation

Currently it is reported that, when system is trying to resume from hibernation, the nonboot CPUs might be incorrectly woken up and hang there. The reason for this is because of inconsistent page tables across hibernation resume. To avoid this situation, use hlt instead of mwait to put nonboot

Re: [PATCH] locking/osq: Drop the overload of osq lock

> 在 2016年6月26日，00:13，Peter Zijlstra 写道： > > On Sat, Jun 25, 2016 at 06:09:22PM +0200, Peter Zijlstra wrote: >> That works here, but it would not work for the need_resched() in >> mutex_spin_on_owner() and mutex_optimistic_spin() which need equal >> treatment. >> >>

Re: [PATCH] locking/osq: Drop the overload of osq lock

> 在 2016年6月26日，00:45，Boqun Feng 写道： > > On Sat, Jun 25, 2016 at 06:15:40PM +0200, Peter Zijlstra wrote: >> On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote: >>> So on PPC, we have lppaca::yield_count to detect when an vcpu is >>> preempted, if the yield_count is

[PATCH 1/2] mm: CONFIG_ZONE_DEVICE stop depending on CONFIG_EXPERT

When it was first introduced CONFIG_ZONE_DEVICE depended on disabling CONFIG_ZONE_DMA, a configuration choice reserved for "experts". However, now that the ZONE_DMA conflict has been eliminated it no longer makes sense to require CONFIG_EXPERT. Reported-by: Eric Sandeen

[PATCH 0/2] ZONE_DEVICE cleanups

Minor cleanups for CONFIG_ZONE_DEVICE. Andrew, killing the CONFIG_EXPERT dependency might be worth applying for 4.7, but otherwise these can wait for 4.8. These have received a "build success" notification from the kbuild robot over 58 configs. Please apply, or ack and I'll queue them with the

[PATCH 2/2] mm: cleanup ifdef guards for vmem_altmap

Now that ZONE_DEVICE depends on SPARSEMEM_VMEMMAP we can simplify some ifdef guards to just ZONE_DEVICE. Reported-by: Vlastimil Babka Signed-off-by: Dan Williams --- include/linux/memremap.h |2 +- kernel/memremap.c|8 2 files

Re: [PATCH 3/3]nbd: make nbd device wait for its users

Hi On Fri, Jun 24, 2016 at 3:39 PM, Pranay Kr. Srivastava wrote: > When a timeout occurs or a recv fails, then > instead of abruplty killing nbd block device > wait for it's users to finish. > > This is more required when filesystem(s) like > ext2 or ext3 don't expect their

Re: [PATCH] capabilities: add capability cgroup controller

On Fri, Jun 24, 2016 at 6:15 AM, Andy Lutomirski wrote: > On Thu, Jun 23, 2016 at 6:14 PM, Topi Miettinen wrote: >> On 06/23/16 23:46, Andrew Morton wrote: >>> On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen >>> wrote: >>>

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sun, Jun 26, 2016 at 12:28:13AM +0800, Boqun Feng wrote: > On Sat, Jun 25, 2016 at 06:09:22PM +0200, Peter Zijlstra wrote: > > That works here, but it would not work for the need_resched() in > > mutex_spin_on_owner() and mutex_optimistic_spin() which need equal > > treatment. > > > > Because

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sun, Jun 26, 2016 at 01:27:51AM +0800, panxinhui wrote: > by the way I still think mutex_unlock has a big overload too. Do you mean overhead?

Re: [PATCH 08/13] pci: spread interrupt vectors in pci_alloc_irq_vectors

On Tue, Jun 14, 2016 at 09:59:01PM +0200, Christoph Hellwig wrote: > Set the affinity_mask before allocating vectors. > > Signed-off-by: Christoph Hellwig > --- > drivers/pci/msi.c | 26 -- > include/linux/pci.h | 1 + > 2 files changed, 25 insertions(+),

Re: [PATCH 1/4] ARM: dts: vf610-twr: Enable display controller

On 2016-06-24 12:44, Anthony Felice wrote: > This adds nodes to enable tcon0 and dcu0 for the Vybrid Tower. These > are used to drive the Vybrid Tower TWR-LCD-RGB display. Also, a node > for the nec nl4827hc19-05b panel on the TWR-LCD-RGB display has been > added. So my pixel clock polarity

{standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

Hi, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: da2f6aba4a21f8da3331e5251a117c52764da579 commit: de361e8bb9f666235d44ae9770238718be4f0483 MIPS: JZ4740: introduce CONFIG_MACH_INGENIC date: 1 year ago config:

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sat, Jun 25, 2016 at 09:20:25PM +0200, Peter Zijlstra wrote: > On Sun, Jun 26, 2016 at 01:27:56AM +0800, panxinhui wrote: > > >> Would that not have issues where the owner cpu is kept running but the > > >> spinner (ie. _this_ vcpu) gets preempted? I would think that in that > > >> case we too

Re: [PATCH 06/13] irq: add a helper spread an affinity mask for MSI/MSI-X vectors

On Tue, Jun 14, 2016 at 09:58:59PM +0200, Christoph Hellwig wrote: > This is lifted from the blk-mq code and adopted to use the affinity mask > concept just intruced in the irq handling code. > > Signed-off-by: Christoph Hellwig > --- > include/linux/interrupt.h | 11 + >

[PATCH 1/2] net: ethernet: sxgbe: use phydev from struct net_device

The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by: Philippe Reynes ---

[PATCH 2/2] net: ethernet: sxgbe: use phy_ethtool_{get|set}_link_ksettings

There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c | 21 +-- 1 files changed, 2

Re: [PATCH 2/4] input: touchscreen: crtouch_ts: Add driver

On 2016-06-24 12:44, Anthony Felice wrote: > Add driver for the Vybrid Tower CRTouch-based touchscreen. This is > required for the touchscreen on the TWR-LCD-RGB to work on the Vybrid > Tower platform. > > There is a known issue with this driver: rarely, SW1 on the TWR-LCD-RGB > module needs to

Re: [PATCH v2 1/2] staging: wilc1000: fix error handling in wilc_debugfs_init()

On Thu, Jun 23, 2016 at 01:36:17PM +0100, Luis de Bethencourt wrote: > The common format to check if a function returned an error pointer is to > use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors. > > Signed-off-by: Luis de Bethencourt > Reviewed-by:

Re: [PATCH v2 2/2] staging: wilc1000: fix error values in wilc_debugfs_init()

On Thu, Jun 23, 2016 at 01:36:18PM +0100, Luis de Bethencourt wrote: > If there was an error, returning -EINVAL is more appropriate than -1. > > Signed-off-by: Luis de Bethencourt > Reviewed-by: Julian Calaby > --- >

[PATCH] rtlwifi: Create _rtl_dbg_trace function to reduce RT_TRACE code size

This debugging macro can expand to a lot of code. Make it a function to reduce code size. (x86-64 defconfig w/ all rtlwifi drivers and allyesconfig) $ size drivers/net/wireless/realtek/rtlwifi/built-in.o* textdata bss dec hex filename 900083 2004991907 1102489 10d299

Re: [PATCH] orangefs: fix namespace handling

Your suggestions make sense to me, especially after looking at how other filesystems use init_user_ns... As far as kicking us out of the Kernel, good grief, I hope not, it was hard getting into the kernel! -Mike On Sat, Jun 25, 2016 at 12:29 AM, Eric W. Biederman wrote:

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 7:41 PM, Linus Torvalds wrote: > On Fri, Jun 24, 2016 at 2:34 PM, Andy Lutomirski wrote: >>> >>> So let me get the pure semantic patches done, and then for 4.8 when we >>> do the things that actually change real meaning

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

On Fri, Jun 24, 2016 at 4:38 AM, Florian Weimer wrote: > On 06/23/2016 09:56 AM, Andreas Schwab wrote: >> >> Andrew Pinski writes: >> >>> So the question becomes do we care enough about the incompatibles >>> between AARCH32 and AARCH64 to fix this and go

Re: [PATCH v2 2/5] input: pmic8xxx-pwrkey: Add support for pm8018 pwrkey

On Sat, Jun 25, 2016 at 10:34:04AM +0200, Neil Armstrong wrote: > On 06/25/2016 12:07 AM, Dmitry Torokhov wrote: > > On Fri, Jun 24, 2016 at 11:18:04AM +0200, Neil Armstrong wrote: > >> In order to support pwrkey for Qualcomm MDM9615 SoC, add support > >> for the pm8018 pwrkey in pmic8xxx-pwrkey.

Re: [PATCH 1/2] net: ethernet: macb: use phydev from struct net_device

From: Philippe Reynes Date: Wed, 22 Jun 2016 00:32:35 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one

Re: [PATCH 2/2] net: ethernet: macb: use phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Wed, 22 Jun 2016 00:32:36 +0200 > There are two generics functions phy_ethtool_{get|set}_link_ksettings, > so we can use them instead of defining the same code in the driver. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote: > > > > int vpc = vcpu_preempt_count(); > > > > ... > > > > for (;;) { > > > > /* the big spin loop */ > > > > if (need_resched() || vpc != vcpu_preempt_count()) > > So on PPC, we have

Re: [Nbd] [PATCH 3/3]nbd: make nbd device wait for its users

Hi Eric, On Fri, Jun 24, 2016 at 7:12 PM, Eric Blake wrote: > On 06/24/2016 04:09 AM, Pranay Kr. Srivastava wrote: >> When a timeout occurs or a recv fails, then >> instead of abruplty killing nbd block device > > s/abruplty/abruptly/ > >> wait for it's users to finish. > >

[PATCH 5/5] PM / devfreq: make event/exynos-ppmu DEVFREQ_EVENT_EXYNOS_PPMU tristate

The Kconfig currently controlling compilation of this code is: config DEVFREQ_EVENT_EXYNOS_PPMU bool "EXYNOS PPMU (Platform Performance Monitoring Unit) DEVFREQ event Driver" ...meaning that it currently is not being built as a module by anyone. Rather than rip out the existing modular code,

[PATCH v2 0/5] PM / devfreq: make module code usage consistent.

For anyone new to the underlying goal of this cleanup, we are trying to not use module support for code that can never be built as a module since: (1) it is easy to accidentally write unused module_exit and remove code (2) it can be misleading when reading the source, thinking it can be

[PATCH] MAINTAINERS: remove unreachable people that have left Atmel

When sending an email regarding a patch to wilc1000, you get the following automatic replies: "Sung_hoon Cho is no longer with Atmel Corporation." "Kang_hee Park is no longer with Atmel Corporation." "Dong_ho Shin is no longer with Atmel Corporation." "Bo_moon Kim is no longer with Atmel

[PATCH 2/4][RFC v2] PM / sleep: Introduce arch-specific hook for disable/enable nonboot cpus

There is requirement that we need to do some arch-specific operations before putting the nonboot CPUs offline/online. One of the requirements comes from the hibernation resume process on x86_64, we need to kick all the offlin-CPUs online and offline again, in order to put them in a safe state,

[PATCH 1/4][RFC v2] PM / sleep: Avoid accessing frozen_cpus if it is NULL

frozen_cpus might be NULL if the allocation in previous alloc_frozen_cpus failed, when CONFIG_CPUMASK_OFFSTACK is set. This patch avoid accessing this cpumask if it is NULL. Signed-off-by: Chen Yu --- kernel/cpu.c | 4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH 1/4][RFC v2] PM / sleep: Avoid accessing frozen_cpus if it is NULL

On Sun 2016-06-26 00:18:30, Chen Yu wrote: > frozen_cpus might be NULL if the allocation in previous > alloc_frozen_cpus failed, when CONFIG_CPUMASK_OFFSTACK > is set. > > This patch avoid accessing this cpumask if it is NULL. > > Signed-off-by: Chen Yu > --- >

Re: [PATCH v4 3/4] perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver

Hi Mark, On Thu, Jun 23, 2016 at 7:32 AM, Mark Rutland wrote: > > Hi, > > On Wed, Jun 22, 2016 at 11:06:58AM -0700, Tai Nguyen wrote: > > diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig > > index 04e2653..be597dd 100644 > > --- a/drivers/perf/Kconfig > > +++

[GIT PULL] SCSI fixes for 4.6-rc2

Two straightforward fixes. One is a concurrency issue only affecting SAS connected SATA drives, but which could hang the storage subsystem if it triggers (because the outstanding command count on error never goes back to zero) and the other is a SCSI_NO_TAG fallout from the switch to host wide

[PATCH v3 15/24] drivers: staging: lustre: Replace CURRENT_TIME with current_time()

CURRENT_TIME macro is not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Use current_time() instead. This is also in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make them y2038 safe. As part of the effort

[PATCH v3 02/24] fs: proc: Delete inode time initializations in proc_alloc_inode()

proc uses new_inode_pseudo() to allocate a new inode. This in turn calls the proc_inode_alloc() callback. But, at this point, inode is still not initialized with the super_block pointer which only happens just before alloc_inode() returns after the call to inode_init_always(). Also, the inode

[PATCH v3 20/24] block: Replace CURRENT_TIME with ktime_get_real_ts

CURRENT_TIME is not y2038 safe. The macro will be deleted and all the references to it will be replaced by ktime_get_* apis. struct timespec is also not y2038 safe. Retain timespec for timestamp representation here as ceph uses it internally everywhere. These references will be changed to use

Re: [PATCH] locking/osq: Drop the overload of osq lock

On Sat, Jun 25, 2016 at 11:21:30PM +0800, Boqun Feng wrote: > So on PPC, we have lppaca::yield_count to detect when an vcpu is > preempted, if the yield_count is even, the vcpu is running, otherwise it > is preempted(__spin_yield() is a user of this). > > Therefore it makes more sense we > >

[PATCH][RFC] cpufreq: Avoid warning during resume by return EAGAIN if cpufreq is unavailable

Previously we saw warning during resume on some platforms, which use acpi-cpufreq: smpboot: Booting Node 0 Processor 3 APIC 0x5 cache: parent cpu3 should not be sleeping CPU3 is up ACPI: Waking up from system sleep state S3 WARNING: CPU: 0 PID: 12546 at drivers/cpufreq/cpufreq.c:2173 Call Trace:

[RFC] perf record: missing buildid for callstack modules -- again

Hi folks! As mentioned by this discussion https://lkml.org/lkml/2016/1/7/661, perf does not record the build id for modules, which are hit on the way down the callstack. Sadly that issue is not completely fixed by the cmd argument --buildid-all. In my case, I have my own kernel module starting a

Re: [PATCH 3/4][RFC v2] PM / hibernate: introduce a flag to indicate resuming from hibernation

On Sun 2016-06-26 00:18:52, Chen Yu wrote: > Sometime we need to do some operations before resuming from > hibernation, so introduce a flag to indicate this stage. > > Signed-off-by: Chen Yu > --- > include/linux/suspend.h | 7 +++ > kernel/power/hibernate.c | 3 +++ >

Re: [PATCH 2/4][RFC v2] PM / sleep: Introduce arch-specific hook for disable/enable nonboot cpus

On Sun 2016-06-26 00:18:41, Chen Yu wrote: > There is requirement that we need to do some arch-specific > operations before putting the nonboot CPUs offline/online. > One of the requirements comes from the hibernation resume > process on x86_64, we need to kick all the offlin-CPUs > online and

Re: 4.6.2 frequent crashes under memory + IO pressure

On Sun, Jun 26, 2016 at 02:04:40AM +0900, Tetsuo Handa wrote: > It seems to me that somebody is using ALLOC_NO_WATERMARKS (with possibly > __GFP_NOWARN), but I don't know how to identify such callers. Maybe print > backtrace from __alloc_pages_slowpath() when ALLOC_NO_WATERMARKS is used? Wouldn't

Re: [PATCH 1/2] nbd: make nbd device wait for its users

On Fri, Jun 24, 2016 at 2:59 PM, Markus Pargmann wrote: > From: "Pranay Kr. Srivastava" > > When a timeout occurs or a recv fails, then instead of abruplty killing > nbd block device wait for it's users to finish. > > This is more required when

Re: [PATCH 3/3] x86/dumpstack: Add show_stack_regs() and use it

On Fri, Jun 24, 2016 at 1:30 AM, Borislav Petkov wrote: > From: Borislav Petkov > > Add a helper to dump supplied pt_regs and use it in the MSR exception > handling code to have precise stack traces pointing to the actual > function causing the MSR access exception

[PATCH v3 23/24] time: Delete current_fs_time() function

All uses of the current_fs_time() function have been replaced by other time interfaces. And, its use cases can be fulfilled by current_time() or ktime_get_* variants. Signed-off-by: Deepa Dinamani Cc: John Stultz Cc: Thomas Gleixner

[PATCH v3 08/24] fs: ubifs: Replace CURRENT_TIME_SEC with current_time

CURRENT_TIME_SEC is not y2038 safe. current_time() will be transitioned to use 64 bit time along with vfs in a separate patch. There is no plan to transition CURRENT_TIME_SEC to use y2038 safe time interfaces. current_time() returns timestamps according to the granularities set in the inode's

[PATCH v3 19/24] fs: nfs: Make nfs boot time y2038 safe

boot_time is represented as a struct timespec. struct timespec and CURRENT_TIME are not y2038 safe. Overall, the plan is to use timespec64 and ktime_t for all internal kernel representation of timestamps. CURRENT_TIME will also be removed. boot_time is used to construct the nfs client boot

[PATCH v3 22/24] fs: ceph: Replace current_fs_time for request stamp

The current_fs_time() api is being changed to use vfs struct inode* as an argument instead of struct super_block*. Set the new mds client request r_stamp field using ktime_get_real_ts() instead of using current_fs_time(). Also, since r_stamp is used as mtime on the server, use timespec_trunc()

[PATCH v3 21/24] libceph: Replace CURRENT_TIME with ktime_get_real_ts

CURRENT_TIME is not y2038 safe. The macro will be deleted and all the references to it will be replaced by ktime_get_* apis. struct timespec is also not y2038 safe. Retain timespec for timestamp representation here as ceph uses it internally everywhere. These references will be changed to use

[PATCH v3 24/24] time: Delete CURRENT_TIME_SEC

All uses of CURRENT_TIME_SEC macro have been replaced by other time functions. This macro is also not y2038 safe. And, all its use cases can be fulfilled by y2038 safe ktime_get_* variants. Signed-off-by: Deepa Dinamani Cc: John Stultz Cc: Thomas

[PATCH v3 16/24] fs: ocfs2: Use time64_t to represent orphan scan times

struct timespec is not y2038 safe. Use time64_t which is y2038 safe to represent orphan scan times. time64_t is sufficient here as only the seconds delta times are relevant. Also use appropriate time functions that return time in time64_t format. Time functions now return monotonic time instead

[PATCH v3 17/24] fs: ocfs2: Replace CURRENT_TIME with ktime_get_real_seconds()

CURRENT_TIME is not y2038 safe. Use y2038 safe ktime_get_real_seconds() here for timestamps. struct heartbeat_block's hb_seq and deletetion time are already 64 bits wide and accommodate times beyond y2038. Signed-off-by: Deepa Dinamani Cc: Mark Fasheh

[PATCH v3 18/24] audit: Use timespec64 to represent audit timestamps

struct timespec is not y2038 safe. Audit timestamps are recorded in string format into an audit buffer for a given context. These mark the entry timestamps for the syscalls. Use y2038 safe struct timespec64 to represent the times. The log strings can handle this transition as strings can hold upto

RE: regression caused by bb6ab52f2bef ("intel_pstate: Do not set utilization update hook too early")

On 2016.06.24 16:09 Rafael J. Wysocki wrote: > On Friday, June 17, 2016 04:09:33 PM Jisheng Zhang wrote: >> Dear all, >> >> If using acpi-cpufreq instead, v4.6, v4.6-rc3, v4.7-rc3 can't reproduce the >> issue. It seems >> only intel_pstate is impacted. > > Which is quite obvious, since the

  1   2   3   4   5   6   >