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 = d_splice_alias(inod
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 even, the vcpu is running, otherwise it
> > is preempted(__spin_yie
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
> ---
> kernel/cpu.c | 4
> 1 file c
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 offl
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 +++
> 2 files changed, 10 i
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 i
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 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/max3100.c b
> 在 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.
>>
>> Because those too we want to
> 在 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 even, the vcpu is runni
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
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 mus
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 sl
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 l
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);
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
Reported-by: Jeff Moyer
S
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 re
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 changed, 1 insertion(+), 9 deletions(-)
di
-#define INTR_STAT_OFS 0x0
-#define INTR_SET_OFS 0x8
-#define INTR_CLR_OFS 0x10
-
-#define MHU_LP_OFFSET 0x0
-#define MHU_HP_OFFSET 0x20
-#define MHU_SEC_OFFSET 0x200
-#define TX_REG_OFFSET 0x100
+#define INTR_SET_OFS 0x0
+#define INTR_STAT_OFS 0x4
+#define INTR_CLR_OFS 0x8
-#define M
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 filesystem(s) like ext2 or ext3 don't expect
> their
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
> > +++ b/drivers/perf/Kconfig
> > @@
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 reference
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.
>
> s/it's/its/
>
>>
>> Th
From: Randy Dunlap
Fix build errors when ACPI is not enabled by adding function stubs:
../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend':
../drivers/gpu/drm/i915/i915_drv.c:635:2: error: implicit declaration of
function 'intel_opregion_unregister' [-Werror=implicit-function-dec
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:
>>>
There are many basic ways to control processes, including capabil
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 buffer heads to
> disa
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: timer_list hint: delayed_work
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 t
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
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, C
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
mod
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 modular
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 mod
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 driver
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 that
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
---
drivers/net/ethernet
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 deletions(-)
diff --git a/dr
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?
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 tag
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 want to stop spinning.
> >>
> >
> do you mean that the spinner detect
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 support
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 w
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 +
> kernel/irq/Make
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
---
drivers/net/ethernet
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 insertions(+), 19 deleti
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(+), 2 deletions(-
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 atom
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 be
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 and not the stack frame of the
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 change
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 insertions(+), 24 deleti
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
---
drivers/net/ethernet
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 the builtin_fw array and
>
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 hardware have shown th
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: Julian Calaby
> ---
>
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
> ---
> drivers/staging/wilc1000/wilc_debugfs.c | 4 ++--
> 1 file changed, 2 insertio
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 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 cu
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 stru
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 verifie
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() to
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 stru
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 Gleixner
Acked-by: John Stultz
---
include/li
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
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 of
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
Cc: Joel Becker
Cc: ocfs2-de...@oss.oracl
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
---
include/linux/fs.h | 1 -
kernel/time/time.c | 14 -
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 supe
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() her
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 c
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
Cc: linux-f2fs-de...@lists.sourceforge.net
---
fs/f
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: jfs-discuss...@lists.sourceforge.net
Acked-by: Dave Kleikamp
---
fs/jfs/ioct
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 [a,c,m]timestamps
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
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 CURRENT_TIME_SE
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
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 will
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 thread,
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
Remove ad-hoc protocol message construction and call instead
tpm1_pcr_read().
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 3
Migrated into single tpm_gen_interrupt() function and cleaned up the
whole construction in general because it was starting to turn into a
train wreck.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 23 ++-
drivers/char/tpm/tpm.h | 2 --
drive
Gave more consistent name tpm1_pcr_read() as the TPM2 version is called
tpm2_pcr_read().
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 4 ++--
drivers/char/tpm/tpm-sysfs.c | 2 +-
drivers/char/tpm/tpm.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-
It is better to tpm_transmit_cmd() in tpm2_probe() in order to get
consistent command handling throughout the subsystem.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm2-cmd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/cha
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 transistion CURRENT_TIME_SEC to use
y2038 safe time interfaces.
current_time() will also be extended to use superblock
range checking parameters when r
Return error code from tpm_gen_interrupt() and fail tpm_tis family of
drivers on a system error. It doesn't make sense to continue if we
cannot even reach the TPM.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 6 +++---
drivers/char/tpm/tpm.h | 2 +-
drivers/cha
These commits update the subsystem consistently to use
tpm_transmit_cmd() throughout the subsystem the exception being
tpm_write() where it makes sense to use the raw interface because higher
level command handling is delegated to user space.
v2: Added commit that drops externs from all function d
Removed unnecessary externs from tpm.h.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm.h | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 8890df2..80b5fa4 100644
--- a/dri
The series is aimed at getting rid of CURRENT_TIME, CURRENT_TIME_SEC macros
and replacing current_fs_time() with current_time().
The macros are not y2038 safe. There is no plan to transition them into being
y2038 safe.
ktime_get_* api's can be used in their place. And, these are y2038 safe.
CURREN
CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_time() instead.
CURRENT_TIME is also not y2038 safe.
This is also in preparation for the patch that transitions
vfs timestamps to use 64 bit time and hence make the
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 Corporatio
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 Corporatio
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
dri
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:
> Jann Horn writes:
>
>
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
index a8a8e43..f900b
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 driv
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 we'll have a sane
>>> base. Ok?
>>
>> Works for me.
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 just worry about ILP32
>>> and LP64?
>>
>>
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
> set) but is otherwise mo
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: mi
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
>arc
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 commit
101 - 200 of 295 matches
Mail list logo
