[PATCH 2/2] miscdevice: Use module_misc_device() macro

[PrasannaKumar Muralidharan]

This patch removes module_init()/module_exit() from driver code by using
module_misc_device() macro.

This patch removes print statements in module init method, so it is sent
as a separate patch. If print statements are necessary this patch can be
dropped entirely.

Signed-off-by: PrasannaKumar Muralidharan 
---
 arch/um/drivers/harddog_kern.c | 25 +
 drivers/bluetooth/hci_vhci.c   | 16 +---
 drivers/char/bfin-otp.c| 40 +---
 drivers/lightnvm/core.c| 19 +--
 4 files changed, 4 insertions(+), 96 deletions(-)

diff --git a/arch/um/drivers/harddog_kern.c b/arch/um/drivers/harddog_kern.c
index 2d0266d..3282787 100644
--- a/arch/um/drivers/harddog_kern.c
+++ b/arch/um/drivers/harddog_kern.c
@@ -175,27 +175,4 @@ static struct miscdevice harddog_miscdev = {
.name   = "watchdog",
.fops   = &harddog_fops,
 };
-
-static char banner[] __initdata = KERN_INFO "UML Watchdog Timer\n";
-
-static int __init harddog_init(void)
-{
-   int ret;
-
-   ret = misc_register(&harddog_miscdev);
-
-   if (ret)
-   return ret;
-
-   printk(banner);
-
-   return 0;
-}
-
-static void __exit harddog_exit(void)
-{
-   misc_deregister(&harddog_miscdev);
-}
-
-module_init(harddog_init);
-module_exit(harddog_exit);
+module_misc_device(harddog_miscdev);
diff --git a/drivers/bluetooth/hci_vhci.c b/drivers/bluetooth/hci_vhci.c
index 3ff229b..c4a75a1 100644
--- a/drivers/bluetooth/hci_vhci.c
+++ b/drivers/bluetooth/hci_vhci.c
@@ -377,21 +377,7 @@ static struct miscdevice vhci_miscdev = {
.fops   = &vhci_fops,
.minor  = VHCI_MINOR,
 };
-
-static int __init vhci_init(void)
-{
-   BT_INFO("Virtual HCI driver ver %s", VERSION);
-
-   return misc_register(&vhci_miscdev);
-}
-
-static void __exit vhci_exit(void)
-{
-   misc_deregister(&vhci_miscdev);
-}
-
-module_init(vhci_init);
-module_exit(vhci_exit);
+module_misc_device(vhci_miscdev);
 
 module_param(amp, bool, 0644);
 MODULE_PARM_DESC(amp, "Create AMP controller device");
diff --git a/drivers/char/bfin-otp.c b/drivers/char/bfin-otp.c
index 44660f1..35d46da 100644
--- a/drivers/char/bfin-otp.c
+++ b/drivers/char/bfin-otp.c
@@ -230,45 +230,7 @@ static struct miscdevice bfin_otp_misc_device = {
.name = DRIVER_NAME,
.fops = &bfin_otp_fops,
 };
-
-/**
- * bfin_otp_init - Initialize module
- *
- * Registers the device and notifier handler. Actual device
- * initialization is handled by bfin_otp_open().
- */
-static int __init bfin_otp_init(void)
-{
-   int ret;
-
-   stampit();
-
-   ret = misc_register(&bfin_otp_misc_device);
-   if (ret) {
-   pr_init(KERN_ERR PFX "unable to register a misc device\n");
-   return ret;
-   }
-
-   pr_init(KERN_INFO PFX "initialized\n");
-
-   return 0;
-}
-
-/**
- * bfin_otp_exit - Deinitialize module
- *
- * Unregisters the device and notifier handler. Actual device
- * deinitialization is handled by bfin_otp_close().
- */
-static void __exit bfin_otp_exit(void)
-{
-   stampit();
-
-   misc_deregister(&bfin_otp_misc_device);
-}
-
-module_init(bfin_otp_init);
-module_exit(bfin_otp_exit);
+module_misc_device(bfin_otp_misc_device);
 
 MODULE_AUTHOR("Mike Frysinger ");
 MODULE_DESCRIPTION("Blackfin OTP Memory Interface");
diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 9ebd2cf..c784ddc 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -1171,27 +1171,10 @@ static struct miscdevice _nvm_misc = {
.nodename   = "lightnvm/control",
.fops   = &_ctl_fops,
 };
+module_misc_device(_nvm_misc);
 
 MODULE_ALIAS_MISCDEV(MISC_DYNAMIC_MINOR);
 
-static int __init nvm_mod_init(void)
-{
-   int ret;
-
-   ret = misc_register(&_nvm_misc);
-   if (ret)
-   pr_err("nvm: misc_register failed for control device");
-
-   return ret;
-}
-
-static void __exit nvm_mod_exit(void)
-{
-   misc_deregister(&_nvm_misc);
-}
-
 MODULE_AUTHOR("Matias Bjorling ");
 MODULE_LICENSE("GPL v2");
 MODULE_VERSION("0.1");
-module_init(nvm_mod_init);
-module_exit(nvm_mod_exit);
-- 
2.5.0

Re: a81de5e161: BUG: unable to handle kernel paging request at ffffc90000647e38

[Andy Lutomirski]

On Sat, Aug 20, 2016 at 9:13 PM, kernel test robot
 wrote:
>
> FYI, we noticed the following commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack
> commit a81de5e16134480cc93596945601f19e1ace7723 ("[DEBUG] forcibly free 
> stacks immediately")
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp 
> 2 -m 1G
>
> caused below changes:
>

> [   22.412266]  [] do_task_stat+0x3cb/0x93d

To anyone watching this, I found and fixed the bug.  And Ingo, if
you're watching, this bug is not present in the set of patches I
emailed you a few days ago.

Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault

[Al Viro]

On Sun, Aug 21, 2016 at 06:54:02AM +0200, Jakub Jelinek wrote:
> On Sat, Aug 20, 2016 at 05:45:00PM -0700, Linus Torvalds wrote:

> If you plan to use setjmp/longjmp a lot, then it is certainly a major
> performance and compile time/memory problem.
> Older versions don't model it properly, and newer gccs emit abnormal edges
> from every longjmp or call that might longjmp to an artificial basic block
> and from there to every setjmp.
> Also note that gcc has/supports two setjmp kind of APIs, normal setjmp and
> slightly more lightweight __builtin_setjmp which saves fewer registers, and
> on some targets is/used to be used for EH instead of DWARF based ones.

It's not exactly setjmp/longjmp; what I had in mind was along the lines of

static inline bool start(void)
{
asm(
save enough state into current_thread_info()->something, with
1f for saved %rip
stac
res = true
2:
.section .text.fixup
1:  res = false
clac
jmp 2b
.previous
)
if (unlikely(!res))
asm clobber everything
return res;
}

and in unsafe_get_user() exception fixup (again, in .text.fixup section,
and invisible to gcc) jumping to common code that would pick saved state
from current_thread_info() and jump to saved location.

The uses would be along the lines of
if (!start())
goto fail;
unsafe_get_user(foo, &p1->foo);
unsafe_get_user(bar, &p1->bar);
...
asm clac

IOW, a bunch of branches hidden from gcc, with destination (in the same
function) dominating the source of each (via visible branches as well).

Originally I hoped to get away with saving just the %rip; Linus has pointed
out that stack pointer is also needed.  It's obviously much less generic
than setjmp/longjmp is.  Single per-thread jmp_buf rudiment, all "longjmp"
calls in the same function as "setjmp" one, pretty much not giving a damn
about any local variables we might've changed if the "longjmp" is taken,
etc.

The point of the exercise is to have the normal execution path containing
no error checks - just the data copying, with all exception handling happening
out-of-line...

Entropy sources (was: /dev/random - a new approach)

[Jeffrey Walton]

On Fri, Aug 19, 2016 at 1:20 PM, H. Peter Anvin  wrote:
> On 08/18/16 22:56, Herbert Xu wrote:
>> On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote:
>>>
>>> That really depends on the system.  We can't assume that people are
>>> using systems with a 100Hz clock interrupt.  More often than not
>>> people are using tickless kernels these days.  That's actually the
>>> problem with changing /dev/urandom to block until things are
>>> initialized.
>>
>> Couldn't we disable tickless until urandom has been seeded? In fact
>> perhaps we should accelerate the timer interrupt rate until it has
>> been seeded?
>>
>
> The biggest problem there is that the timer interrupt adds *no* entropy
> unless there is a source of asynchronicity in the system.  On PCs,
> traditionally the timer has been run from a completely different crystal
> (14.31818 MHz) than the CPU, which is the ideal situation, but if they
> are run off the same crystal and run in lockstep, there is very little
> if anything there.  On some systems, the timer may even *be* the only
> source of time, and the entropy truly is zero.

It seems like a networked computer should have an abundance on entropy
available from the network stack. Every common case I can come up with
includes a networked computer. If a handheld is outside of coverage,
then it probably does not have the randomness demands because it can't
communicate (i.e., TCP sequence numbers, key agreement, etc).

In fact, there are at least two papers that use bits from the network stack:

* When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities
and Hedging Deployed Cryptography,
http://pages.cs.wisc.edu/~rist/papers/sslhedge.pdf
* When Virtual is Harder than Real: Security Challenges in Virtual
Machine Based Computing Environments,
http://www.usenix.org/legacy/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf

As IoT gains traction the entropy available locally should increase
because these devices are chatty. I also expect gossip protocols to
play more of a role in the future. A network based attacker cannot
possibly monitor every conversation, especially when devices pair and
form adhoc networks. The network attacker probably won't see the
traffic on a local LAN segment either for headless servers.

When using network bits, it seems like the remaining problem is
extracting the entropy. I think Krawczyk (et al) have done a lot of
work in this area:

* Leftover Hash Lemma, Revisited, http://eprint.iacr.org/2011/088.pdf
* Cryptographic Extraction and Key Derivation: The HKDF Scheme,
http://eprint.iacr.org/2010/264.pdf

Jeff

Re: [Documentation] State of CPU controller in cgroup v2

[James Bottomley]

On Wed, 2016-08-17 at 13:18 -0700, Andy Lutomirski wrote:
> On Aug 5, 2016 7:07 PM, "Tejun Heo"  wrote:
[...]
> > 2. Disagreements and Arguments
> > 
> > There have been several lengthy discussion threads [3][4] on LKML
> > around the structural constraints of cgroup v2.  The two that 
> > affect the CPU controller are process granularity and no internal 
> > process constraint.  Both arise primarily from the need for common 
> > resource domain definition across different resources.
> > 
> > The common resource domain is a powerful concept in cgroup v2 that
> > allows controllers to make basic assumptions about the structural
> > organization of processes and controllers inside the cgroup 
> > hierarchy, and thus solve problems spanning multiple types of 
> > resources.  The prime example for this is page cache writeback: 
> > dirty page cache is regulated through throttling buffered writers 
> > based on memory availability, and initiating batched write outs to 
> > the disk based on IO capacity.  Tracking and controlling writeback 
> > inside a cgroup thus requires the direct cooperation of the memory 
> > and the IO controller.
> > 
> > This easily extends to other areas, such as CPU cycles consumed 
> > while performing memory reclaim or IO encryption.
> > 
> > 
> > 2-1. Contentious Restrictions
> > 
> > For controllers of different resources to work together, they must
> > agree on a common organization.  This uniform model across 
> > controllers imposes two contentious restrictions on the CPU 
> > controller: process granularity and the no-internal-process
> > constraint.
> > 
> > 
> >   2-1-1. Process Granularity
> > 
> >   For memory, because an address space is shared between all
> > threads
> >   of a process, the terminal consumer is a process, not a thread.
> >   Separating the threads of a single process into different memory
> >   control domains doesn't make semantical sense.  cgroup v2 ensures
> >   that all controller can agree on the same organization by
> > requiring
> >   that threads of the same process belong to the same cgroup.
> 
> I haven't followed all of the history here, but it seems to me that
> this argument is less accurate than it appears.  Linux, for better or
> for worse, has somewhat orthogonal concepts of thread groups
> (processes), mms, and file tables.  An mm has VMAs in it, and VMAs 
> can reference things (files, etc) that hold resources.  (Two mms can
> share resources by mapping the same thing or using fork().)  File 
> tables hold files, and files can use resources.  Both of these are, 
> at best, moderately good approximations of what actually holds 
> resources. Meanwhile, threads (tasks) do syscalls, take page faults, 
> *allocate* resources, etc.
> 
> So I think it's not really true to say that the "terminal consumer" 
> of anything is a process, not a thread.
> 
> While it's certainly easier to think about assigning processes to
> cgroups, and I certainly agree that, in the common case, it's the
> right thing to do, I don't see why requiring it is a good idea.  Can
> we turn this around: what actually goes wrong if cgroup v2 were to
> allow assigning individual threads if a user specifically requests
> it?

A similar point from a different consumer: from the unprivileged
containers point of view, I'm interested in a thread based interface as
well.  The principle utility of unprivileged containers is to allow
applications that wish to to use container properties (effectively to
become self-containerising).  Some that use the producer/consumer model
do use process pools (apache springs to mind instantly) but some use
thread pools.  It is useful to the latter to preserve the concept of a
thread as being the entity inhabiting the cgroup (but only where the
granularity of the cgroup permits threads to participate) so we can
easily modify them to be self containerising without forcing them to
switch back from a thread pool model to a process pool model.

I can see that process based is conceptually easier in v2 because you
begin with a process tree, but it would really be a pity to lose the
thread based controls we have now and permanently lose the ability to
create more as we find uses for them.  I can't really see how improving
"common resource domain" is a good tradeoff for this.

James

Re: [PATCH 2/2] net: ethernet: renesas: ravb: use new api ethtool_{get|set}_link_ksettings

[David Miller]

From: Philippe Reynes 
Date: Sat, 20 Aug 2016 00:52:19 +0200

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.

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

[David Miller]

From: Philippe Reynes 
Date: Sat, 20 Aug 2016 00:52:18 +0200

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

Applied.

Re: [PATCH] net: xilinx: emaclite: Fallback to random MAC address.

[David Miller]

From: Daniel Romell 
Date: Fri, 19 Aug 2016 14:12:01 +0200

> If the address configured in the device tree is invalid, the
> driver will fallback to using a random address from the locally
> administered range.
> 
> Signed-off-by: Daniel Romell 

Applied.

Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault

[Jakub Jelinek]

On Sat, Aug 20, 2016 at 05:45:00PM -0700, Linus Torvalds wrote:
> You have to save the stack pointer at the setjmp point too. And there
> might be other architecture-specific ABI rules for that. But you're
> right, it might be worth it.
> 
> I *would* be a bit worried about code generation issues.
> setjmp/longjmp is so seldom used that it's one of those things where
> it might be best to verify with some gcc person that it doesn't cause
> huge code-gen problems.
> 
> Adding Jakub just to check: Jakub, would a setjump/longjump kind of
> interface for exception handling going to cause us problems
> (performance or correctness) with gcc?

If you plan to use setjmp/longjmp a lot, then it is certainly a major
performance and compile time/memory problem.
Older versions don't model it properly, and newer gccs emit abnormal edges
from every longjmp or call that might longjmp to an artificial basic block
and from there to every setjmp.
Also note that gcc has/supports two setjmp kind of APIs, normal setjmp and
slightly more lightweight __builtin_setjmp which saves fewer registers, and
on some targets is/used to be used for EH instead of DWARF based ones.

Jakub

Re: [linux-sunxi] [PATCH 2/9] mfd: axp20x: Add support for AXP806 PMIC

[Julian Calaby]

Hi Chen-Yu,

On Sun, Aug 21, 2016 at 12:11 PM, Chen-Yu Tsai  wrote:
> The X-Powers AXP809 is a new PMIC that is paired with Allwinner's A80
> SoC, along with a master AXP809 PMIC.

The first "AXP809" should be "AXP806".

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

a81de5e161: BUG: unable to handle kernel paging request at ffffc90000647e38

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack
commit a81de5e16134480cc93596945601f19e1ace7723 ("[DEBUG] forcibly free stacks 
immediately")

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp 2 
-m 1G

caused below changes:


+--+++
|  | b3768b6fde | a81de5e161 |
+--+++
| boot_successes   | 4  | 8  |
| boot_failures| 1  | 4  |
| BUG:kernel_hang_in_early-boot_stage  | 1  ||
| BUG:unable_to_handle_kernel  | 0  | 4  |
| Oops | 0  | 4  |
| RIP:get_wchan| 0  | 4  |
| calltrace:SyS_read   | 0  | 4  |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 4  |
+--+++



 Starting RPC Remote Quota Server...
 Starting LSB: Load kernel image with kexec...
 Starting Getty on tty1...
[   22.394549] BUG: unable to handle kernel paging request at c9647e38
[   22.396728] IP: [] get_wchan+0x60/0xb5
[   22.412223] PGD 2bc9b067 PUD 2bcb0067 PMD 2a7fb067 PTE 0
[   22.412225] Oops:  [#1] SMP
[   22.412227] Modules linked in: acpi_cpufreq
[   22.412230] CPU: 0 PID: 2630 Comm: pidof Not tainted 
4.8.0-rc1-00017-ga81de5e #1
[   22.412231] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   22.412233] task: 8800110c4600 task.stack: c95d4000
[   22.412239] RIP: 0010:[]  [] 
get_wchan+0x60/0xb5
[   22.412240] RSP: 0018:c95d7c58  EFLAGS: 00010216
[   22.412241] RAX: c9647e38 RBX: 88003f74e300 RCX: 
[   22.412242] RDX: c9647ff0 RSI: 0286 RDI: 88003f16
[   22.412243] RBP: c95d7c88 R08:  R09: 
[   22.412244] R10: 88002a70d000 R11: 8800110c4600 R12: 88003f16
[   22.412245] R13:  R14: c9644000 R15: 880029c05b01
[   22.412247] FS:  7fe0f8b2b700() GS:88003880() 
knlGS:
[   22.412248] CS:  0010 DS:  ES:  CR0: 80050033
[   22.412249] CR2: c9647e38 CR3: 3f752000 CR4: 000406f0
[   22.412253] Stack:
[   22.412256]   88003f74e300 88003f16 

[   22.412258]  0a44 880029c05b01 c95d7d98 
8129eeed
[   22.412260]  880029c05b00 88003f662aa0 5a00 

[   22.412261] Call Trace:
[   22.412266]  [] do_task_stat+0x3cb/0x93d
[   22.412269]  [] proc_tgid_stat+0x14/0x16
[   22.412271]  [] proc_single_show+0x56/0x76
[   22.412274]  [] seq_read+0x171/0x333
[   22.412277]  [] __vfs_read+0x26/0xed
[   22.412281]  [] ? vm_mmap_pgoff+0x81/0xa7
[   22.412283]  [] vfs_read+0xa7/0x132
[   22.412285]  [] SyS_read+0x4e/0x88
[   22.412288]  [] entry_SYSCALL_64_fastpath+0x1f/0xbd
[   22.412306] Code: 41 55 41 54 53 51 4c 8b 77 10 4d 85 f6 75 04 31 c0 eb 5e 
48 8b 87 e0 09 00 00 49 8d 96 f0 3f 00 00 49 39 c6 77 e9 48 39 c2 72 e4 <4c> 8b 
20 48 89 fb 41 bf 11 00 00 00 4d 39 f4 72 d3 49 39 d4 48 
[   22.412309] RIP  [] get_wchan+0x60/0xb5
[   22.412310]  RSP 
[   22.412310] CR2: c9647e38
[   22.412313] ---[ end trace 397d4f30e4b22143 ]---
[   22.412315] Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -kernel 
/pkg/linux/x86_64-lkp/gcc-6/a81de5e16134480cc93596945601f19e1ace7723/vmlinuz-4.8.0-rc1-00017-ga81de5e
 -append 'ip=vm-kbuild-1G-5::dhcp root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-1G-5/boot-1-debian-x86_64-2015-02-07.cgz-a81de5e16134480cc93596945601f19e1ace7723-20160821-39118-ygsw4a-0.yaml
 ARCH=x86_64 kconfig=x86_64-lkp branch=linux-devel/devel-catchup-201608171102 
commit=a81de5e16134480cc93596945601f19e1ace7723 
BOOT_IMAGE=/pkg/linux/x86_64-lkp/gcc-6/a81de5e16134480cc93596945601f19e1ace7723/vmlinuz-4.8.0-rc1-00017-ga81de5e
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-1G/debian-x86_64-2015-02-07.cgz/x86_64-lkp/gcc-6/a81de5e16134480cc93596945601f19e1ace7723/0
 LKP_SERVER=inn debug apic=debug sysrq_always_enabled 
rcupdate.rcu_cpu_stall_timeout=100 panic=-1 softlockup_panic=1 
nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 
systemd.log_level=err ignore_loglevel earlyprintk=ttyS0,115200 
console=ttyS0,115200 console=tty0 vga=normal rw'  -initrd 
/fs/sdg1/initrd-vm-kbuild-1G-5 -m 1024 -smp 2 -device e1000,netdev=net0 -netdev 
user,id=net0,hostfwd=tcp::23004-:22 -boot order=nc -no-reboot -watchdog 
i6300esb

Re: runaway latency detection

[Steven Rostedt]

On August 20, 2016 3:04:43 PM EDT, Tracy Smith 


>Using ftace it is difficult to catch the latency since it can occur at
>any
>point during the cyclictest. It is an uncomfortable level of
>indeterminism
>without knowing the cause.
>
>Is there a way to trace random latency jumps on a single core using
>trace,
>or any other suggestion to isolate it? I know the functions and tasks
>running on the core using ftrace, but can't catch the random latency
>jumps.

Have you tried using the -b option of cyclictest?  It stops the tracing when it 
detects a latency. It shows what happened up to that point. I can discuss more 
about what to do later but I'll be traveling to LinuxCon tomorrow.

-- Steve


>
>Thx, Tracy
>On Aug 20, 2016 12:54 PM, "Nikolay Borisov" 
>wrote:
>
>>
>>
>> On 20.08.2016 20:03, T. Smith wrote:
>> > The goal is to isolate causes of indeterminism when using the
>PREEMPT_RT
>> kernel configuration with full preemption and to characterize latency
>and
>> jitter using ftrace, any recommendations?
>>
>> What hardware is it ? If it's x86 it's entirely possible you are
>seeing
>> SMI. Perhaps you should look into disabling those if you are on x86?
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH] staging: lustre: llite: don't clean in_data again

[Oleg Drokin]

Acked-by: Oleg Drokin 

On Aug 20, 2016, at 10:44 PM, Shawn Lin wrote:

> We have got a zero buffer for in_data as we use
> kzalloc here. So let's remove it anyway.
> 
> Signed-off-by: Shawn Lin 
> ---
> 
> drivers/staging/lustre/lustre/llite/file.c | 1 -
> 1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/lustre/llite/file.c 
> b/drivers/staging/lustre/lustre/llite/file.c
> index 50938bd..ec6b7ce 100644
> --- a/drivers/staging/lustre/lustre/llite/file.c
> +++ b/drivers/staging/lustre/lustre/llite/file.c
> @@ -3251,7 +3251,6 @@ void *ll_iocontrol_register(llioc_callback_t cb, int 
> count, unsigned int *cmd)
>   if (!in_data)
>   return NULL;
> 
> - memset(in_data, 0, sizeof(*in_data));
>   in_data->iocd_size = size;
>   in_data->iocd_cb = cb;
>   in_data->iocd_count = count;
> -- 
> 2.3.7
> 

Re: [PATCH] lib/Kconfig.debug: fix typo in select statement

[Kees Cook]

On Sat, Aug 20, 2016 at 11:20 AM, Paul E. McKenney
 wrote:
> On Sat, Aug 20, 2016 at 12:16:10PM +0200, Valentin Rothberg wrote:
>> Commit 484f29c7430b3 ("bug: Provide toggle for BUG on data corruption")
>> added a Kconfig select statement on CONFIG_DEBUG_LIST, but the CONFIG_
>> prefix is only used in Make and C(PP) syntax.  Remove the CONFIG_ prefix
>> to correctly select the Kconfig option DEBUG_LIST.
>>
>> Signed-off-by: Valentin Rothberg 
>
> Well, color me blind!
>
> Good catch, queued for review and testing.
>
> Kees, Steve, Rik, any objections?

Argh, thank you. Yes, this is correct.

Acked-by: Kees Cook 

-Kees

>
> Thanx, Paul
>
>> ---
>> I detected the issue with scripts/checkkconfigsymbols.py
>>
>>  lib/Kconfig.debug | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 5dea4d0a5a07..c2bbaae13d04 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -2009,7 +2009,7 @@ config TEST_STATIC_KEYS
>>
>>  config BUG_ON_DATA_CORRUPTION
>>   bool "Trigger a BUG when data corruption is detected"
>> - select CONFIG_DEBUG_LIST
>> + select DEBUG_LIST
>>   help
>> Select this option if the kernel should BUG when it encounters
>> data corruption in kernel memory structures when they get checked
>> --
>> 2.9.3
>>
>



-- 
Kees Cook
Nexus Security

[PATCH] lib/digsig: remove redundant clean out1 when verifying RSA

[Shawn Lin]

out1 is already set to zero when allocating by kzalloc, so
we could avoid this clean operation again.

Signed-off-by: Shawn Lin 
---

 lib/digsig.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/digsig.c b/lib/digsig.c
index 55b8b2f..d6a2aa4 100644
--- a/lib/digsig.c
+++ b/lib/digsig.c
@@ -156,7 +156,6 @@ static int digsig_verify_rsa(struct key *key,
 
len = mlen;
head = len - l;
-   memset(out1, 0, head);
memcpy(out1 + head, p, l);
 
kfree(p);
-- 
2.3.7

Re: [PATCH v6 0/5] /dev/random - a new approach

[Herbert Xu]

On Fri, Aug 19, 2016 at 10:20:18AM -0700, H. Peter Anvin wrote:
> On 08/18/16 22:56, Herbert Xu wrote:
> > On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote:
> >>
> >> That really depends on the system.  We can't assume that people are
> >> using systems with a 100Hz clock interrupt.  More often than not
> >> people are using tickless kernels these days.  That's actually the
> >> problem with changing /dev/urandom to block until things are
> >> initialized.
> > 
> > Couldn't we disable tickless until urandom has been seeded? In fact
> > perhaps we should accelerate the timer interrupt rate until it has
> > been seeded?
> > 
> 
> The biggest problem there is that the timer interrupt adds *no* entropy
> unless there is a source of asynchronicity in the system.  On PCs,
> traditionally the timer has been run from a completely different crystal
> (14.31818 MHz) than the CPU, which is the ideal situation, but if they
> are run off the same crystal and run in lockstep, there is very little
> if anything there.  On some systems, the timer may even *be* the only
> source of time, and the entropy truly is zero.

Sure, but that's orthorgonal to what Ted was talking about above.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH 2/9] mfd: axp20x: Add support for AXP806 PMIC

[Chen-Yu Tsai]

The X-Powers AXP809 is a new PMIC that is paired with Allwinner's A80
SoC, along with a master AXP809 PMIC.

This PMIC has a new register layout, and supports some functions not
seen in other X-Powers PMICs, such as master-slave mode, or having
multiple AXP806 PMICs on the same bus with address space extension,
or supporting both I2C and RSB mode. I2C has not been tested.

This patch adds support for the interrupts of the PMIC. A regulator
sub-device is enabled, but actual regulator support will come in a
later patch.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/mfd/axp20x-rsb.c   |  1 +
 drivers/mfd/axp20x.c   | 72 ++
 include/linux/mfd/axp20x.h | 60 ++
 3 files changed, 133 insertions(+)

diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index a407527bcd09..a732cb50bcff 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
 
 static const struct of_device_id axp20x_rsb_of_match[] = {
{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+   { .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
{ },
 };
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index fd80b0981f0f..96102753847f 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -38,6 +38,7 @@ static const char * const axp20x_model_names[] = {
"AXP221",
"AXP223",
"AXP288",
+   "AXP806",
"AXP809",
 };
 
@@ -129,6 +130,27 @@ static const struct regmap_access_table 
axp288_volatile_table = {
.n_yes_ranges   = ARRAY_SIZE(axp288_volatile_ranges),
 };
 
+static const struct regmap_range axp806_writeable_ranges[] = {
+   regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_DATACACHE(3)),
+   regmap_reg_range(AXP806_PWR_OUT_CTRL1, AXP806_CLDO3_V_CTRL),
+   regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ2_EN),
+   regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
+};
+
+static const struct regmap_range axp806_volatile_ranges[] = {
+   regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
+};
+
+static const struct regmap_access_table axp806_writeable_table = {
+   .yes_ranges = axp806_writeable_ranges,
+   .n_yes_ranges   = ARRAY_SIZE(axp806_writeable_ranges),
+};
+
+static const struct regmap_access_table axp806_volatile_table = {
+   .yes_ranges = axp806_volatile_ranges,
+   .n_yes_ranges   = ARRAY_SIZE(axp806_volatile_ranges),
+};
+
 static struct resource axp152_pek_resources[] = {
DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_RIS_EDGE, "PEK_DBR"),
DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
@@ -278,6 +300,15 @@ static const struct regmap_config axp288_regmap_config = {
.cache_type = REGCACHE_RBTREE,
 };
 
+static const struct regmap_config axp806_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .wr_table   = &axp806_writeable_table,
+   .volatile_table = &axp806_volatile_table,
+   .max_register   = AXP806_VREF_TEMP_WARN_L,
+   .cache_type = REGCACHE_RBTREE,
+};
+
 #define INIT_REGMAP_IRQ(_variant, _irq, _off, _mask)   \
[_variant##_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
 
@@ -409,6 +440,21 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG,5, 1),
 };
 
+static const struct regmap_irq axp806_regmap_irqs[] = {
+   INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV1,  0, 0),
+   INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV2,  0, 1),
+   INIT_REGMAP_IRQ(AXP806, DCDCA_V_LOW,0, 3),
+   INIT_REGMAP_IRQ(AXP806, DCDCB_V_LOW,0, 4),
+   INIT_REGMAP_IRQ(AXP806, DCDCC_V_LOW,0, 5),
+   INIT_REGMAP_IRQ(AXP806, DCDCD_V_LOW,0, 6),
+   INIT_REGMAP_IRQ(AXP806, DCDCE_V_LOW,0, 7),
+   INIT_REGMAP_IRQ(AXP806, PWROK_LONG, 1, 0),
+   INIT_REGMAP_IRQ(AXP806, PWROK_SHORT,1, 1),
+   INIT_REGMAP_IRQ(AXP806, WAKEUP, 1, 4),
+   INIT_REGMAP_IRQ(AXP806, PWROK_FALL, 1, 5),
+   INIT_REGMAP_IRQ(AXP806, PWROK_RISE, 1, 6),
+};
+
 static const struct regmap_irq axp809_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP809, ACIN_OVER_V,0, 7),
INIT_REGMAP_IRQ(AXP809, ACIN_PLUGIN,0, 6),
@@ -494,6 +540,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip 
= {
 
 };
 
+static const struct regmap_irq_chip axp806_regmap_irq_chip = {
+   .name   = "axp806",
+   .status_base= AXP20X_IRQ1_STATE,
+   .ack_base   = AXP20X_IRQ1_STATE,
+   .mask_base  = AXP20X_IRQ1_EN,
+   .mask_invert= true,
+   .init_ack_masked= true,

[PATCH 6/9] ARM: dts: sun9i: cubieboard4: Declare AXP809 SW regulator as unused

[Chen-Yu Tsai]

The AXP809's SW (switch) regulator is unused on the Cubieboard 4.
Add an empty node for it so that the OS can generate constraints.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts 
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 04b014603659..910b29f0f0b5 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -253,6 +253,10 @@
reg_rtc_ldo: rtc_ldo {
regulator-name = "vcc-rtc-vdd1v8-io";
};
+
+   sw {
+   /* unused */
+   };
};
};
 
-- 
2.9.3

[PATCH 9/9] ARM: dts: sun9i: a80-optimus: Disable EHCI1

[Chen-Yu Tsai]

EHCI1 provides an HSIC interface. This interface is exposed on the
board through two pins among the GPIO header.

With the PHY now powered up and responding, enabling the interface when
nothing is connected results in a lot of error messages:

usb 2-1: device descriptor read/64, error -71
usb 2-1: device descriptor read/64, error -71
usb 2-1: new high-speed USB device number 3 using ehci-platform
usb 2-1: device descriptor read/64, error -71
usb 2-1: device descriptor read/64, error -71
usb 2-1: new high-speed USB device number 4 using ehci-platform
usb 2-1: device not accepting address 4, error -71
usb 2-1: new high-speed USB device number 5 using ehci-platform
usb 2-1: device not accepting address 5, error -71
usb usb2-port1: unable to enumerate USB device

Disable it by default, but leave the entries in the board DTS.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts 
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index aeb4037c8768..536a7d1d678b 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -112,7 +112,8 @@
 };
 
 &ehci1 {
-   status = "okay";
+   /* Enable if HSIC peripheral is connected */
+   status = "disabled";
 };
 
 &ehci2 {
@@ -484,7 +485,8 @@
 
 &usbphy2 {
phy-supply = <®_bldo4>;
-   status = "okay";
+   /* Enable if HSIC peripheral is connected */
+   status = "disabled";
 };
 
 &usbphy3 {
-- 
2.9.3

[PATCH 1/9] mfd: axp20x: Add bindings for AXP806 PMIC

[Chen-Yu Tsai]

This patch adds the basic and regulator bindings for the X-Powers AXP809
PMIC.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 585a95546288..8f3ad9ab4637 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -10,7 +10,8 @@ axp809 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221", "x-powers,axp223", "x-powers,axp809"
+ "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
+ "x-powers,axp809"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -47,7 +48,6 @@ Optional properties for DCDC regulators:
  probably makes sense for HiFi audio related
  applications that aren't battery constrained.
 
-
 AXP202/AXP209 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
@@ -86,6 +86,30 @@ LDO_IO1  : LDO   : ips-supply
: GPIO 1
 RTC_LDO: LDO   : ips-supply: always on
 DRIVEVBUS  : Enable output : drivevbus-supply  : external regulator
 
+AXP806 regulators, type, and corresponding input supply names:
+
+RegulatorTypeSupply Name Notes
+---- -
+DCDCA  : DC-DC buck: vina-supply   : poly-phase capable
+DCDCB  : DC-DC buck: vinb-supply   : poly-phase capable
+DCDCC  : DC-DC buck: vinc-supply   : poly-phase capable
+DCDCD  : DC-DC buck: vind-supply   : poly-phase capable
+DCDCE  : DC-DC buck: vine-supply   : poly-phase capable
+ALDO1  : LDO   : aldoin-supply : shared supply
+ALDO2  : LDO   : aldoin-supply : shared supply
+ALDO3  : LDO   : aldoin-supply : shared supply
+BLDO1  : LDO   : bldoin-supply : shared supply
+BLDO2  : LDO   : bldoin-supply : shared supply
+BLDO3  : LDO   : bldoin-supply : shared supply
+BLDO4  : LDO   : bldoin-supply : shared supply
+CLDO1  : LDO   : cldoin-supply : shared supply
+CLDO2  : LDO   : cldoin-supply : shared supply
+CLDO3  : LDO   : cldoin-supply : shared supply
+SW : On/Off Switch : swin-supply
+
+Additionally, the AXP806 DC-DC regulators support poly-phase arrangements
+for higher output current. The possible groupings are: A+B, A+B+C, D+E.
+
 AXP809 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
-- 
2.9.3

[PATCH 8/9] ARM: dts: sun9i: cubieboard4: Add AXP806 PMIC device node and regulators

[Chen-Yu Tsai]

The AXP806 PMIC is the secondary PMIC. It provides various supply
voltages for the SoC and other peripherals. The PMIC's interrupt
line is connected to NMI pin of the SoC.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 112 
 1 file changed, 112 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts 
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 910b29f0f0b5..e38ac4fec10c 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -260,6 +260,118 @@
};
};
 
+   axp806: pmic@745 {
+   compatible = "x-powers,axp806";
+   reg = <0x745>;
+   interrupt-parent = <&nmi_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   bldoin-supply = <®_dcdce>;
+
+   regulators {
+   reg_s_aldo1: aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+   };
+
+   aldo2 {
+   /*
+* unused, but use a different name to
+* avoid name clash with axp809's aldo's
+*/
+   regulator-name = "s_aldo2";
+   };
+
+   aldo3 {
+   /*
+* unused, but use a different name to
+* avoid name clash with axp809's aldo's
+*/
+   regulator-name = "s_aldo3";
+   };
+
+   reg_bldo1: bldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <198>;
+   regulator-name = "vcc18-efuse-adc-display-csi";
+   };
+
+   reg_bldo2: bldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <198>;
+   regulator-name =
+   "vdd18-drampll-vcc18-pll-cpvdd";
+   };
+
+   bldo3 {
+   /* unused */
+   };
+
+   reg_bldo4: bldo4 {
+   regulator-min-microvolt = <108>;
+   regulator-max-microvolt = <132>;
+   regulator-name = "vcc12-hsic";
+   };
+
+   reg_cldo1: cldo1 {
+   /*
+* This was 3V in the original design, but
+* 3.3V is the recommended supply voltage
+* for the Ethernet PHY.
+*/
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-gmac-phy";
+   };
+
+   reg_cldo2: cldo2 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "afvcc-cam";
+   };
+
+   reg_cldo3: cldo3 {
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-io-wifi-codec-io2";
+   };
+
+   reg_dcdca: dcdca {
+   regulator-always-on;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-cpub";
+   };
+
+   reg_dcdcd: dcdcd {
+   regulator-always-on;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-vpu";
+   };
+
+   reg_dcdce: dcdce {
+   regulator-always-on;
+   regulator-min-microvolt = <210>;
+

[PATCH 5/9] ARM: dts: sun9i: a80-optimus: Declare AXP809 SW regulator as unused

[Chen-Yu Tsai]

The AXP809's SW (switch) regulator is unused on the A80 Optimus.
Add an empty node for it so that the OS can generate constraints.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts 
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index fd874ded890e..caf0091e71ba 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -325,6 +325,10 @@
reg_rtc_ldo: rtc_ldo {
regulator-name = "vcc-rtc-vdd1v8-io";
};
+
+   sw {
+   /* unused */
+   };
};
};
 
-- 
2.9.3

[PATCH 0/9] mfd: axp20x: Add support for AXP809 PMIC

[Chen-Yu Tsai]

Hi everyone,

This series adds support for X-Powers' AXP806 PMIC. This is the secondary
PMIC accompanying Allwinner's A80 SoC. For now, only the regulators are
supported. While the AXP806 supports standalone operation, no hardware
exists, so this will not be supported.

Patch 1 adds AXP806 to the axp20x bindings.

Patch 2 adds AXP806 support to the axp20x mfd driver.

Patch 3 fixes regulator output adjustment during regulator registration
so it doesn't fail if the higher or lower bounds of its voltage constraints
don't match up with the regulator's voltage granularity.

Patch 4 adds AXP806 support to the axp20x regulator driver.

Patch 5 adds the unused SW switch output of the AXP809 PMIC on the A80
Optimus board. This was accidentally left out of the AXP809 series.

Patch 6 adds the unused SW switch output of the AXP809 PMIC on the
Cubieboard 4. This was accidentally left out of the AXP809 series.

Patch 7 enables AXP809 support on the A80 Optimus board.

Patch 8 enables AXP809 support on the Cubieboard 4.

Patch 9 disables EHCI1 on the A80 Optimus board.


Regards
ChenYu

Chen-Yu Tsai (9):
  mfd: axp20x: Add bindings for AXP806 PMIC
  mfd: axp20x: Add support for AXP806 PMIC
  regulator: core: Try full range when adjusting regulators to
constraints
  regulator: axp20x: support AXP806 variant
  ARM: dts: sun9i: a80-optimus: Declare AXP809 SW regulator as unused
  ARM: dts: sun9i: cubieboard4: Declare AXP809 SW regulator as unused
  ARM: dts: sun9i: a80-optimus: Add AXP806 PMIC device node and
regulators
  ARM: dts: sun9i: cubieboard4: Add AXP806 PMIC device node and
regulators
  ARM: dts: sun9i: a80-optimus: Disable EHCI1

 Documentation/devicetree/bindings/mfd/axp20x.txt |  28 +-
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts  | 116 +
 arch/arm/boot/dts/sun9i-a80-optimus.dts  | 123 ++-
 drivers/mfd/axp20x-rsb.c |   1 +
 drivers/mfd/axp20x.c |  72 +
 drivers/regulator/axp20x-regulator.c | 117 +++--
 drivers/regulator/core.c |   8 +-
 include/linux/mfd/axp20x.h   |  60 +++
 8 files changed, 508 insertions(+), 17 deletions(-)

-- 
2.9.3

[PATCH 3/9] regulator: core: Try full range when adjusting regulators to constraints

[Chen-Yu Tsai]

Currently when we try to bring regulator in bounds of its constraints,
we pick either the minimum or maximum voltage as the target. This fails
if the regulator range is not continuous, and the target voltage is not
an exact value the regulator can achieve, i.e. the target is not aligned
to the step of the regulator.

Instead pass the full range of the constraints, and have the regulator
core work out a suitable voltage within.

Fixes: ("regulator: core: Ensure we are at least in bounds for our
 constraints")
Signed-off-by: Chen-Yu Tsai 
---
 drivers/regulator/core.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index db320e8fa865..86f69c92ce7a 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -897,13 +897,9 @@ static int machine_constraints_voltage(struct 
regulator_dev *rdev,
target_min = current_uV;
target_max = current_uV;
 
-   if (current_uV < rdev->constraints->min_uV) {
+   if (current_uV < rdev->constraints->min_uV ||
+   current_uV > rdev->constraints->max_uV) {
target_min = rdev->constraints->min_uV;
-   target_max = rdev->constraints->min_uV;
-   }
-
-   if (current_uV > rdev->constraints->max_uV) {
-   target_min = rdev->constraints->max_uV;
target_max = rdev->constraints->max_uV;
}
 
-- 
2.9.3

[PATCH 4/9] regulator: axp20x: support AXP806 variant

[Chen-Yu Tsai]

The X-Powers AXP806 PMIC has a new set of buck and LDO regulators, and
also a switch. The buck regulators support teaming into multi-phase
groups, with A+B, A+B+C, D+E groupings.

Some registers controlling DCDC converter work settings are at different
offsets. Deal with them as well.

Add support for this new variant.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/regulator/axp20x-regulator.c | 117 ---
 1 file changed, 110 insertions(+), 7 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 6d9ac76a772f..ac5d97b78dce 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,16 +244,64 @@ static const struct regulator_desc 
axp22x_drivevbus_regulator = {
.ops= &axp20x_ops_sw,
 };
 
-static const struct regulator_linear_range axp809_dcdc4_ranges[] = {
-   REGULATOR_LINEAR_RANGE(60, 0x0, 0x2f, 2),
-   REGULATOR_LINEAR_RANGE(180, 0x30, 0x38, 10),
+static const struct regulator_linear_range axp806_dcdca_ranges[] = {
+   REGULATOR_LINEAR_RANGE(60, 0x0, 0x32, 1),
+   REGULATOR_LINEAR_RANGE(112, 0x33, 0x47, 2),
+};
+
+static const struct regulator_linear_range axp806_dcdcd_ranges[] = {
+   REGULATOR_LINEAR_RANGE(60, 0x0, 0x2d, 2),
+   REGULATOR_LINEAR_RANGE(160, 0x2e, 0x3f, 10),
 };
 
-static const struct regulator_linear_range axp809_dldo1_ranges[] = {
+static const struct regulator_linear_range axp806_cldo2_ranges[] = {
REGULATOR_LINEAR_RANGE(70, 0x0, 0x1a, 10),
REGULATOR_LINEAR_RANGE(340, 0x1b, 0x1f, 20),
 };
 
+static const struct regulator_desc axp806_regulators[] = {
+   AXP_DESC_RANGES(AXP806, DCDCA, "dcdca", "vina", axp806_dcdca_ranges,
+   72, AXP806_DCDCA_V_CTRL, 0x7f, AXP806_PWR_OUT_CTRL1,
+   BIT(0)),
+   AXP_DESC(AXP806, DCDCB, "dcdcb", "vinb", 1000, 2550, 50,
+AXP806_DCDCB_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL1, BIT(1)),
+   AXP_DESC_RANGES(AXP806, DCDCC, "dcdcc", "vinc", axp806_dcdca_ranges,
+   72, AXP806_DCDCC_V_CTRL, 0x7f, AXP806_PWR_OUT_CTRL1,
+   BIT(2)),
+   AXP_DESC_RANGES(AXP806, DCDCD, "dcdcd", "vind", axp806_dcdcd_ranges,
+   64, AXP806_DCDCD_V_CTRL, 0x3f, AXP806_PWR_OUT_CTRL1,
+   BIT(3)),
+   AXP_DESC(AXP806, DCDCE, "dcdce", "vine", 1100, 3400, 100,
+AXP806_DCDCB_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL1, BIT(4)),
+   AXP_DESC(AXP806, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+AXP806_ALDO1_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL1, BIT(5)),
+   AXP_DESC(AXP806, ALDO2, "aldo2", "aldoin", 700, 3400, 100,
+AXP806_ALDO2_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL1, BIT(6)),
+   AXP_DESC(AXP806, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+AXP806_ALDO3_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL1, BIT(7)),
+   AXP_DESC(AXP806, BLDO1, "bldo1", "bldoin", 700, 1900, 100,
+AXP806_BLDO1_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(0)),
+   AXP_DESC(AXP806, BLDO2, "bldo2", "bldoin", 700, 1900, 100,
+AXP806_BLDO2_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(1)),
+   AXP_DESC(AXP806, BLDO3, "bldo3", "bldoin", 700, 1900, 100,
+AXP806_BLDO3_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(2)),
+   AXP_DESC(AXP806, BLDO4, "bldo4", "bldoin", 700, 1900, 100,
+AXP806_BLDO4_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(3)),
+   AXP_DESC(AXP806, CLDO1, "cldo1", "cldoin", 700, 3300, 100,
+AXP806_CLDO1_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2, BIT(4)),
+   AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp806_cldo2_ranges,
+   32, AXP806_CLDO2_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2,
+   BIT(5)),
+   AXP_DESC(AXP806, CLDO3, "cldo3", "cldoin", 700, 3300, 100,
+AXP806_CLDO3_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2, BIT(6)),
+   AXP_DESC_SW(AXP806, SW, "sw", "swin", AXP806_PWR_OUT_CTRL2, BIT(7)),
+};
+
+static const struct regulator_linear_range axp809_dcdc4_ranges[] = {
+   REGULATOR_LINEAR_RANGE(60, 0x0, 0x2f, 2),
+   REGULATOR_LINEAR_RANGE(180, 0x30, 0x38, 10),
+};
+
 static const struct regulator_desc axp809_regulators[] = {
AXP_DESC(AXP809, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
 AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(1)),
@@ -278,7 +326,7 @@ static const struct regulator_desc axp809_regulators[] = {
 AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
 AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
-   AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp809_dldo1_ranges,
+   AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp806_cldo2_ranges,

[PATCH 7/9] ARM: dts: sun9i: a80-optimus: Add AXP806 PMIC device node and regulators

[Chen-Yu Tsai]

The AXP806 PMIC is the secondary PMIC. It provides various supply
voltages for the SoC and other peripherals. The PMIC's interrupt
line is connected to NMI pin of the SoC.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 113 
 1 file changed, 113 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts 
b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index caf0091e71ba..aeb4037c8768 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -332,6 +332,118 @@
};
};
 
+   axp806: pmic@745 {
+   compatible = "x-powers,axp806";
+   reg = <0x745>;
+   interrupt-parent = <&nmi_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   bldoin-supply = <®_dcdce>;
+
+   regulators {
+   reg_s_aldo1: aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+   };
+
+   aldo2 {
+   /*
+* unused, but use a different name to
+* avoid name clash with axp809's aldo's
+*/
+   regulator-name = "s_aldo2";
+   };
+
+   aldo3 {
+   /*
+* unused, but use a different name to
+* avoid name clash with axp809's aldo's
+*/
+   regulator-name = "s_aldo3";
+   };
+
+   reg_bldo1: bldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <198>;
+   regulator-name = "vcc18-efuse-adc-display-csi";
+   };
+
+   reg_bldo2: bldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <162>;
+   regulator-max-microvolt = <198>;
+   regulator-name =
+   "vdd18-drampll-vcc18-pll-cpvdd";
+   };
+
+   bldo3 {
+   /* unused */
+   };
+
+   reg_bldo4: bldo4 {
+   regulator-min-microvolt = <108>;
+   regulator-max-microvolt = <132>;
+   regulator-name = "vcc12-hsic";
+   };
+
+   reg_cldo1: cldo1 {
+   /*
+* This was 3V in the original design, but
+* 3.3V is the recommended supply voltage
+* for the Ethernet PHY.
+*/
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-gmac-phy";
+   };
+
+   reg_cldo2: cldo2 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "afvcc-cam";
+   };
+
+   reg_cldo3: cldo3 {
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-io-wifi-codec-io2";
+   };
+
+   reg_dcdca: dcdca {
+   regulator-always-on;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-cpub";
+   };
+
+   reg_dcdcd: dcdcd {
+   regulator-always-on;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-vpu";
+   };
+
+   reg_dcdce: dcdce {
+   regulator-always-on;
+   regulator-min-microvolt = <210>;
+

Re: [PATCH 6/6] Add dockerfile

[Theodore Ts'o]

Ok, I've checked in a Dockerfile into the xfstests-bld repository, and
played with it some, and I have a couple of observations:

First of all, despite some work cleaning up the Dockerfile, the
resulting image is somewhere between 150% and 200% larger than what it
would be if we build root_fs.img outside of the Docker.  A bunch of
the wasted space is simply because we have to include a 47 MB
xfstests.tar.gz file which then has to get re-inserted into the
root_fs image via the --update-xfstests command line.

Secondly, as an automated build procedure, it's rather lacking in two
ways.  First, it doesn't do the gen-image step, and secondly it only
builds the 64-bit x86_64 binaries --- and I normally like to use the
32-bit i386 image, since that can be used to test 32-bit and 64-bit
binaries, and it also forces us to test the 32/64-bit ioctl compat
code.  So it's really only useful as a CI mechanism --- and in order
to use it I have to give Docker read/write access to my github
repositories.  I might consider creating a throwaway github repository
on bitbucket just for the CI effort, but it's not high on my priority
list, since it doesn't test the gen-image part of the build process.

Third, it's a bit more inconvenient to use than the comments in your
Dockerfile would imply.  The command:

docker run -i -t --privileged --rm dmonakhov/xfstests-bld \
   kvm-xfstests.sh --kernel /tmp/bzImage --update-files --update-xfstests-tar 
smoke

... won't work because the docker because the image won't have
/tmp/bzImage.  So you would need to add "-v /tmp/bzImage:/tmp/bzImage"
to the command line, making it even more unweildy.

BTW, with changes I've just commited, we can drop the --kernel since
we now default to ~/linux, and so the command would look like this:

docker run -i -t -rm -v /build/ext4:/root/linux --privileged \
tytso/xfstests-bld kvm-xfstests --update-files --update-xfstests smoke

So if I am going to publish something to the Docker Hub, it would an
addition to my current release process, where I would build the
root_fs using my existing Debian build chroots, and just create a
minimal tytso/kvm-xfstests image which would just have the needed
files, and would probably end up weighing in around 200-225 MB.  The
user wouldn't need to specify the --update-files and --update-xfstests
flags, and it would start faster.

On the other hand, I'm not at all convinced this is actually a great
way to run kvm-xfstests; for one thing, the log file is trapped inside
the Docker container, and so you would need to manually extract it in
order to keep a history of past test runs.  (This is also the
challenge of just sharding the test runs; collating the test results
becomes a big pain.)  And the whole concept of running a VM inside a
docker container reminds me a bit of the "Hitler uses Docker" rant at:
https://youtu.be/PivpCKEiQOQ?t=2m27s

I'm also not wild about encouraging people to run random Docker images
they download over the network with docker run --privileged.  That's
right up there with running with scissors, encouraging people to give
Docker read/write access to their github accounts, using the same
password across hundreds of web sites, etc.

If the real goal is to allow people to shard the tests so it can be
run across multiple VM's, it might be better to give kvm-xfstests some
options so a different set of disks are used and either a different
set of ports, or just network ports altogether.

Cheers,

- Ted

[PATCH] staging: lustre: llite: don't clean in_data again

[Shawn Lin]

We have got a zero buffer for in_data as we use
kzalloc here. So let's remove it anyway.

Signed-off-by: Shawn Lin 
---

 drivers/staging/lustre/lustre/llite/file.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/file.c 
b/drivers/staging/lustre/lustre/llite/file.c
index 50938bd..ec6b7ce 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -3251,7 +3251,6 @@ void *ll_iocontrol_register(llioc_callback_t cb, int 
count, unsigned int *cmd)
if (!in_data)
return NULL;
 
-   memset(in_data, 0, sizeof(*in_data));
in_data->iocd_size = size;
in_data->iocd_cb = cb;
in_data->iocd_count = count;
-- 
2.3.7

[PATCH] scsi: don't reinitialize adapter's req_table

[Shawn Lin]

req_table is allocate by kzalloc, so we don't need to
zero it again anyway.

Signed-off-by: Shawn Lin 
---

 drivers/scsi/esas2r/esas2r_init.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/scsi/esas2r/esas2r_init.c 
b/drivers/scsi/esas2r/esas2r_init.c
index 78ce4d61..d6e53ae 100644
--- a/drivers/scsi/esas2r/esas2r_init.c
+++ b/drivers/scsi/esas2r/esas2r_init.c
@@ -963,10 +963,6 @@ bool esas2r_init_adapter_struct(struct esas2r_adapter *a,
 
/* initialize the allocated memory */
if (test_bit(AF_FIRST_INIT, &a->flags)) {
-   memset(a->req_table, 0,
-  (num_requests + num_ae_requests +
-   1) * sizeof(struct esas2r_request *));
-
esas2r_targ_db_initialize(a);
 
/* prime parts of the inbound list */
-- 
2.3.7

[PATCH] scsi: not need to alloc zero buffer for local_atto_ioctl

[Shawn Lin]

We don't need to use kzalloc as we will always memset the
local_atto_ioctl later.

Signed-off-by: Shawn Lin 
---

 drivers/scsi/esas2r/esas2r_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/esas2r/esas2r_main.c 
b/drivers/scsi/esas2r/esas2r_main.c
index 2aca4d1..5092c82 100644
--- a/drivers/scsi/esas2r/esas2r_main.c
+++ b/drivers/scsi/esas2r/esas2r_main.c
@@ -194,7 +194,7 @@ static ssize_t write_hw(struct file *file, struct kobject 
*kobj,
int length = min(sizeof(struct atto_ioctl), count);
 
if (!a->local_atto_ioctl) {
-   a->local_atto_ioctl = kzalloc(sizeof(struct atto_ioctl),
+   a->local_atto_ioctl = kmalloc(sizeof(struct atto_ioctl),
  GFP_KERNEL);
if (a->local_atto_ioctl == NULL) {
esas2r_log(ESAS2R_LOG_WARN,
-- 
2.3.7

Re: [PATCH] wan-cosa: Use memdup_user() rather than duplicating its implementation

[David Miller]

From: Christophe JAILLET 
Date: Sat, 20 Aug 2016 10:42:54 +0200

> Le 20/08/2016 à 10:25, SF Markus Elfring a écrit :
>> @@ -875,16 +875,10 @@ static ssize_t cosa_write(struct file *file,
>>  if (count > COSA_MTU)
>>  count = COSA_MTU;
>>  
>> -/* Allocate the buffer */
>> -kbuf = kmalloc(count, GFP_KERNEL|GFP_DMA);
> In this case, 'memdup_user()' has a different meaning, as GFP_DMA will
> no more be used for this memory allocation.

Agreed, this transformation is not equivalent.

Markus, please do not make these changes so blindly.

Re: [PATCH 0/2] tun: Fine-tuning for update_filter()

[David Miller]

From: SF Markus Elfring 
Date: Sat, 20 Aug 2016 09:27:39 +0200

> A few update suggestions were taken into account
> from static source code analysis.

Series applied.

Re: [PATCH 2/3] hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()

[Julian Calaby]

Hi Marcus,

On Sun, Aug 21, 2016 at 2:46 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Sat, 20 Aug 2016 18:21:29 +0200
>
> Remove a jump label which is unneeded in this function at the end.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/net/wireless/intersil/hostap/hostap_ioctl.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c 
> b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
> index 4e271f9..5942917 100644
> --- a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
> +++ b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
> @@ -3835,14 +3835,12 @@ static int prism2_ioctl_priv_hostapd(local_info_t 
> *local, struct iw_point *p)
> }
>
> if (ret == 1 || !ap_ioctl) {
> -   if (copy_to_user(p->pointer, param, p->length)) {
> +   if (copy_to_user(p->pointer, param, p->length))
> ret = -EFAULT;
> -   goto out;
> -   } else if (ap_ioctl)
> +   else if (ap_ioctl)
> ret = 0;
> }
>
> - out:

Does this change make any difference to the compiled code?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault

[Al Viro]

On Sat, Aug 20, 2016 at 06:09:15PM -0700, H. Peter Anvin wrote:

> >Sorry for the bogus noise. I don't know why I was so convinced setjmp
> >needed special gcc semantics.
> >
> > Linus
> 
> I think the specific name setjmp() is magic in gcc.

It is; attribute equivalent is returns_twice.  I wonder if "explicitly
clobber everything if we got false" + asm volatile to prevent reordering
would suffice for our purposes, but that's really a question for gcc
folks...

Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault

[H. Peter Anvin]

On August 20, 2016 6:00:17 PM PDT, Linus Torvalds 
 wrote:
>On Sat, Aug 20, 2016 at 5:45 PM, Linus Torvalds
> wrote:
>>
>> So I slightly considered it, because gcc actually has support for
>that
>> kind of behavior thanks to setjmp/longjmp (and yes, the compiler
>> actually needs to know about the magic "this code can be entered a
>> second time from elsewhere" - it _used_ to be purely a library thing
>> back in the days of stupid compilers, but no more).
>
>Hmm. I may just be full of sh*t.
>
>I was pretty sure that there used to be a "setjmp" attribute that gcc
>used to make sure that "setjmp()" really could return twice, without
>bad things happening on the stack.
>
>But looking at the normal user space headers, I see nothing like that.
>It's just
>
>extern int setjmp (jmp_buf __env) __THROWNL;
>
>where __THROWNL just sets the __nothrow__ attribute, which shouldn't
>even matter in the kernel since we use -fno-exceptions.
>
>So my "setjmp does potentially bad things to the optimization of the
>function calling it" seems to have been just some drug-induced fever
>dream of mine.
>
>Sorry for the bogus noise. I don't know why I was so convinced setjmp
>needed special gcc semantics.
>
> Linus

I think the specific name setjmp() is magic in gcc.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [PATCH 1/3] dt/bindings: arm-pl330: add description of arm,pl330-periph-burst

[Shawn Lin]

Hi Vinod,

在 2016/8/19 10:45, Vinod Koul 写道:

On Wed, Aug 17, 2016 at 04:11:03PM +0800, Shawn Lin wrote:

Hi, Vinod and Lars-Peter

Ping.. Any better idea to share :)

On 2016/8/9 17:12, Shawn Lin wrote:

Hi Lars-Peter,

在 2016/8/9 16:39, Lars-Peter Clausen 写道:

On 08/05/2016 09:25 AM, Shawn Lin wrote:

Hi Vinod,

在 2016/8/5 11:34, Vinod Koul 写道:

On Fri, Aug 05, 2016 at 10:53:20AM +0800, Shawn Lin wrote:

This patch adds the "arm,pl330-periph-burst" for arm-pl330 to
support busrt mode.


why should this be DT property. Only reason I can think of if some hw
versions support this and some won't.


yes, if we want to support burst mode, both of the master(pl330) and
client(several peripherals) should implement it, otherwise it will
be broken when enabling.


As you said, it is up to the consumer peripheral whether it supports
BURST,
SINGLE or both. So this is a per client property, but you specify this
as a
a global property on the producer side.


Thanks for comment.

yup, but what is the proper way to add it ? :)


a) If pl330 support BURST as well as all the peripherals, we could
enable it.

b) If pl300 support BURST, but all the peripherals don't support it,
we could not enable it.

c) If pl300 support BURST, but not all the peripherals support it,
we also could not enable it.

the burst feature of peripheral IP may be vendor-specific, but the
common driver for this peripheral are used for many many vendors which
means we could not check all of this info. It's very likely to break
them... I couldn't figure out how many upstreamed peripheral drivers
who are using pl300 either.

So this check should be done by all this vendors but we could make
sure we don't break them before they check a), b), c), right?


Since support for BURST needs to be from peripheral too, we should have
that as a property for peripheral not for controller.

The peripheral drivers can communicate the burst to be used to pl330
using src_maxburst/dst_maxburst in dma_slave_config. We can use this
value to indicate the DMA should be single (a value of 0) or burst with
"burst" value.


Thanks for sharing this.

But this is really a difficult trade-off decision to add this new
property for pl330 only.

Burst mode was supported by Boojin Kim's patch by default(commit
848e9776fee42 ("dmaengine: pl330: support burst mode for dev-to-mem and
mem-to-dev transmit")).  But we found it will break SoCFPGA or
Exynos4412 reported by Dinh Nguyen and Bartlomiej Zolnierkiewicz[0].
So finally Caesar Wang contributed a patch, commit 0a18f9b268 ("
dmaengine: pl330: fix to support the burst mode") to fix it, but what
it actually did is to use single burst for any case, namely some kind
of regression for Boojin Kim's improvement.

So we can see these drivers which was broken by enabling burst mode
had already set src_maxburst/dst_maxburst. It looks to me so unfortunate
that the driver like 8250_dw.c was using so widely that we couldn't
set scr/dst_maxburst as this is really vendor specific for whether it
supports burst for 8250_dw or not..

So it is quite painful that we probably will get dozens of regression
reports when enabling burst mode by default. But without this, we have
been suffering from low performance quite a long time due to this
roadblock.

Two possible paths to land this patch are:
(1) Keep this property for pl330 only, so we have no chance to
break others and we could make the platforms enjoy it if adding this
property for their own dts.

(2) Figuer out all the broken platfroms if enabling burst and fix them
one by one for the src/dst_maxburst(maybe by enabling burst mode and
get regression reports). If we could not solve any one of them, then we
have to give up all the effort we do, and let this pain keep on
stalling people's expectation of better performance.


I would appreciate it if you could share your thought more, as I really 
want more platforms benefit from it(at least don't break them)  :)



[0] http://www.gossamer-threads.com/lists/linux/kernel/2374171






--
Best Regards
Shawn Lin

Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault

[Linus Torvalds]

On Sat, Aug 20, 2016 at 5:45 PM, Linus Torvalds
 wrote:
>
> So I slightly considered it, because gcc actually has support for that
> kind of behavior thanks to setjmp/longjmp (and yes, the compiler
> actually needs to know about the magic "this code can be entered a
> second time from elsewhere" - it _used_ to be purely a library thing
> back in the days of stupid compilers, but no more).

Hmm. I may just be full of sh*t.

I was pretty sure that there used to be a "setjmp" attribute that gcc
used to make sure that "setjmp()" really could return twice, without
bad things happening on the stack.

But looking at the normal user space headers, I see nothing like that. It's just

extern int setjmp (jmp_buf __env) __THROWNL;

where __THROWNL just sets the __nothrow__ attribute, which shouldn't
even matter in the kernel since we use -fno-exceptions.

So my "setjmp does potentially bad things to the optimization of the
function calling it" seems to have been just some drug-induced fever
dream of mine.

Sorry for the bogus noise. I don't know why I was so convinced setjmp
needed special gcc semantics.

 Linus

Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault

[Linus Torvalds]

On Sat, Aug 20, 2016 at 5:11 PM, Al Viro  wrote:
>
> Interesting...  BTW, how's this in the "really vile tricks" department?
>
> if (!uaccess_begin())
> goto fail;

So I slightly considered it, because gcc actually has support for that
kind of behavior thanks to setjmp/longjmp (and yes, the compiler
actually needs to know about the magic "this code can be entered a
second time from elsewhere" - it _used_ to be purely a library thing
back in the days of stupid compilers, but no more).

And I'm not saying it's wrong, but I'm not a huge fan of
setjmp/longjmp. Afaik it tends to make gcc generate potentially much
worse code in the function that uses setjmp.

That said, you have a really strong argument that I hadn't even thought about:

> AFAICS, it should avoid the problems with asm goto, right?

Yes. That was something I never even thought about. I just thought
"asm goto has some limitations, but they aren't _fundamental_, so
hopefully they get fixed". But they may not be fundamental, but it
will take a long time. If ever.

And you're right, using setjmp semantics would avoid all that and
"just work". Even for "get_user()" that needs to return a value.

Hmm.

You have to save the stack pointer at the setjmp point too. And there
might be other architecture-specific ABI rules for that. But you're
right, it might be worth it.

I *would* be a bit worried about code generation issues.
setjmp/longjmp is so seldom used that it's one of those things where
it might be best to verify with some gcc person that it doesn't cause
huge code-gen problems.

Adding Jakub just to check: Jakub, would a setjump/longjump kind of
interface for exception handling going to cause us problems
(performance or correctness) with gcc?

Linus

Re: [PATCH 1/8] hisi_sas: add internal abort core code

[zhangfei]

On 2016年08月10日 21:19, John Garry wrote:

Add core code for internal abort functionality.

The internal abort features allows the host controller
to abort commands which are still active in the
controller but have not yet been sent to the slave
device.

Typically a command only spends a relatively
short time in the controller when compared to the
amount of the time after it is sent to the slave
device.
Two modes of internal abort are supported:
- device
- individual command

For device, when the internal abort is issued all
commands in the host for that device are aborted.
For a single command, only that command is aborted
if it is still in the host.

In HW the internal abort command is executed
similar to any other sort of command, like SSP.

Signed-off-by: John Garry 
---
  drivers/scsi/hisi_sas/hisi_sas.h  |   3 +
  drivers/scsi/hisi_sas/hisi_sas_main.c | 154 ++
  2 files changed, 157 insertions(+)

diff --git a/drivers/scsi/hisi_sas/hisi_sas.h b/drivers/scsi/hisi_sas/hisi_sas.h
index 4731d32..4ae864d 100644
--- a/drivers/scsi/hisi_sas/hisi_sas.h
+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -146,6 +146,9 @@ struct hisi_sas_hw {
struct hisi_sas_slot *slot);
int (*prep_stp)(struct hisi_hba *hisi_hba,
struct hisi_sas_slot *slot);
+   int (*prep_abort)(struct hisi_hba *hisi_hba,
+ struct hisi_sas_slot *slot,
+ int device_id, int abort_flag, int tag_to_abort);


How about add comments to abort_flag and tag_to_abort.
As a result, not sure why differently calling in hisi_sas_abort_task
hisi_sas_internal_task_abort(hisi_hba, device, 1, tag);
hisi_sas_internal_task_abort(hisi_hba, device, 0, tag);

Thanks

Re: [PATCH 0/2] minor x86 PM source file cleanup

[Al Stone]

On 08/20/2016 04:55 AM, Pavel Machek wrote:
> On Fri 2016-08-19 17:24:00, Al Stone wrote:
>> Really minor patches: one to cleanup whitespace, the second just makes
>> the code a wee bit more maintainable by correcting some variable names
>> without changing functionality.
> 
> Acked-by: Pavel Machek 
> 
> (for both)
> 
>> Al Stone (2):
>>   x86: ACPI: remove extraneous white space after semicolon
>>   x86: ACPI: make variable names clearer in
>> acpi_parse_madt_lapic_entries()
>>
>>  arch/x86/kernel/acpi/boot.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
> 

Thanks, Pavel.

-- 
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---

Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault

[Al Viro]

On Sat, Aug 20, 2016 at 04:32:57PM -0700, Linus Torvalds wrote:

> Anyway, the asm coming out of gcc looks nasty, because it has all the
> ugly section stuiff and fixups for SMAP not existing on some CPU's
> etc. So the resulting fs/readdir.s file is hard to read. But if you
> look at the disassembly at the object file that hides all that (and
> shows what the end result actually is), the actual filldir user
> accesses end up looking beautiful, with no extra code anywhere. An
> exception just goes to the EFAULT handling directly.
> 
> Sadly, unsafe_get_user() looking as good does require gcc improvements
> that aren't imminent.
> 
> This patch is untested, although the earlier original pre-rebased
> version of it actually got a fair amount of testing on my machine
> (including the filldir use)

Interesting...  BTW, how's this in the "really vile tricks" department?

if (!uaccess_begin())
goto fail;
unsafe_...
...
uacess_end();

with uaccess_begin() along the lines of
p = ¤t_thread_info()->foo;
asm
.text:
STAC
*p = 1f
res = true;
2:;
.fixups:
1:res = false;
CLAC
jmp 2;
if (unlikely(res))
asm
clobber everything
res;
and exception handlers in unsafe_... jumping to the address found
in current_thread_info()->foo.  AFAICS, it should avoid the problems
with asm goto, right?  The branch target is tied to the entry into the
damn series, so it's not as if it could disappear; and path to a branch
cc(1) doesn't see passes through the chunk produced by that asm block
in uaccess_begin(), so if it looks unreachable without taking those branches
into account, it _is_ unreachable.

Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault

[Linus Torvalds]

On Fri, Aug 19, 2016 at 3:11 PM, Linus Torvalds
 wrote:
>>
>> (I have some experimental patches that actually use "asm goto" in
>> "unsafe_put_user()" to get that nice code generation, but they only
>> work if your gcc version supports "asm goto", which some older
>> versions of gcc does not)
>
> Since you actually are looking at the user access stuff, I'll just put
> them here.

Here's an updated patch that applies on current git and that actually
uses this for filldir() (but not signal handling).

It turns out that on Skylake, which supports SMAP, the clac/stac
instructions are quite slow, and doing them for each access makes
things insanely much slower than it could be. And "filldir" does the
user accesses one by one (except for the name copying), and is
actually somewhat common under some loads (ie the "find . -name XYZ"
kind of thing).

Anyway, the asm coming out of gcc looks nasty, because it has all the
ugly section stuiff and fixups for SMAP not existing on some CPU's
etc. So the resulting fs/readdir.s file is hard to read. But if you
look at the disassembly at the object file that hides all that (and
shows what the end result actually is), the actual filldir user
accesses end up looking beautiful, with no extra code anywhere. An
exception just goes to the EFAULT handling directly.

Sadly, unsafe_get_user() looking as good does require gcc improvements
that aren't imminent.

This patch is untested, although the earlier original pre-rebased
version of it actually got a fair amount of testing on my machine
(including the filldir use)

Linus
 arch/x86/include/asm/uaccess.h | 80 --
 fs/readdir.c   | 22 ++--
 2 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index a0ae610b9280..8d6b299522f1 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -204,19 +204,14 @@ __typeof__(__builtin_choose_expr(sizeof(x) > sizeof(0UL), 
0ULL, 0UL))
 
 
 #ifdef CONFIG_X86_32
-#define __put_user_asm_u64(x, addr, err, errret)   \
-   asm volatile("\n"   \
-"1:movl %%eax,0(%2)\n" \
-"2:movl %%edx,4(%2)\n" \
-"3:"   \
-".section .fixup,\"ax\"\n" \
-"4:movl %3,%0\n"   \
-"  jmp 3b\n"   \
-".previous\n"  \
-_ASM_EXTABLE(1b, 4b)   \
-_ASM_EXTABLE(2b, 4b)   \
-: "=r" (err)   \
-: "A" (x), "r" (addr), "i" (errret), "0" (err))
+#define __put_user_goto_u64(x, addr, label)\
+   asm volatile("\n"   \
+"1:movl %%eax,0(%2)\n" \
+"2:movl %%edx,4(%2)\n" \
+_ASM_EXTABLE(1b, %2l)  \
+_ASM_EXTABLE(2b, %2l)  \
+: : "A" (x), "r" (addr)\
+: : label)
 
 #define __put_user_asm_ex_u64(x, addr) \
asm volatile("\n"   \
@@ -231,8 +226,8 @@ __typeof__(__builtin_choose_expr(sizeof(x) > sizeof(0UL), 
0ULL, 0UL))
asm volatile("call __put_user_8" : "=a" (__ret_pu)  \
 : "A" ((typeof(*(ptr)))(x)), "c" (ptr) : "ebx")
 #else
-#define __put_user_asm_u64(x, ptr, retval, errret) \
-   __put_user_asm(x, ptr, retval, "q", "", "er", errret)
+#define __put_user_goto_u64(x, ptr, label) \
+   __put_user_goto(x, ptr, "q", "", "er", label)
 #define __put_user_asm_ex_u64(x, addr) \
__put_user_asm_ex(x, addr, "q", "", "er")
 #define __put_user_x8(x, ptr, __ret_pu) __put_user_x(8, x, ptr, __ret_pu)
@@ -293,23 +288,21 @@ extern void __put_user_8(void);
__builtin_expect(__ret_pu, 0);  \
 })
 
-#define __put_user_size(x, ptr, size, retval, errret)  \
+#define __put_user_size(x, ptr, size, label)   \
 do {   \
-   retval = 0; \
__chk_user_ptr(ptr);\
switch (size) { \
case 1: \
-   __put_user_asm(x, ptr, retval, "b", 

[PATCH] pcmcia: ds: fix suspend/resume

[Russell King]

PCMCIA suspend/resume no longer works since the commit mentioned below,
as the callbacks are no longer made.  Convert the driver to the new
dev_pm_ops, which restores the suspend/resume functionality.  Tested on
the arm arch Assabet platform with a pcnet_cs CF card.

Fixes: aa8e54b559479 ("PM / sleep: Go direct_complete if driver has no 
callbacks")
Signed-off-by: Russell King 
---
 drivers/pcmcia/ds.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/pcmcia/ds.c b/drivers/pcmcia/ds.c
index 489ea1098c96..69b5e811ea2b 100644
--- a/drivers/pcmcia/ds.c
+++ b/drivers/pcmcia/ds.c
@@ -977,7 +977,7 @@ static int pcmcia_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
 
 / runtime PM support ***/
 
-static int pcmcia_dev_suspend(struct device *dev, pm_message_t state);
+static int pcmcia_dev_suspend(struct device *dev);
 static int pcmcia_dev_resume(struct device *dev);
 
 static int runtime_suspend(struct device *dev)
@@ -985,7 +985,7 @@ static int runtime_suspend(struct device *dev)
int rc;
 
device_lock(dev);
-   rc = pcmcia_dev_suspend(dev, PMSG_SUSPEND);
+   rc = pcmcia_dev_suspend(dev);
device_unlock(dev);
return rc;
 }
@@ -1135,7 +1135,7 @@ ATTRIBUTE_GROUPS(pcmcia_dev);
 
 /* PM support, also needed for reset */
 
-static int pcmcia_dev_suspend(struct device *dev, pm_message_t state)
+static int pcmcia_dev_suspend(struct device *dev)
 {
struct pcmcia_device *p_dev = to_pcmcia_dev(dev);
struct pcmcia_driver *p_drv = NULL;
@@ -1410,6 +1410,9 @@ static struct class_interface pcmcia_bus_interface 
__refdata = {
.remove_dev = &pcmcia_bus_remove_socket,
 };
 
+static const struct dev_pm_ops pcmcia_bus_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(pcmcia_dev_suspend, pcmcia_dev_resume)
+};
 
 struct bus_type pcmcia_bus_type = {
.name = "pcmcia",
@@ -1418,8 +1421,7 @@ struct bus_type pcmcia_bus_type = {
.dev_groups = pcmcia_dev_groups,
.probe = pcmcia_device_probe,
.remove = pcmcia_device_remove,
-   .suspend = pcmcia_dev_suspend,
-   .resume = pcmcia_dev_resume,
+   .pm = &pcmcia_bus_pm_ops,
 };
 
 
-- 
2.1.0

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Rob Clark]

On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli  wrote:
> Cc'ing lkml too.
>
> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
>> Story time:
>> I was dreaming of a day were we can stop installing these headers,
>> thus making deprecation a bit easier process.
>> Yet after failing to convince Dave and Daniel on a number of occasions
>> I've accepted that those headers _are_ here to stay. And yes they
>> _are_ the UAPI, even though no applications are meant to use them but
>> the libdrm 'version'.
>> Thus any changes to the libdrm ones should be a mirror of the ones
>> here and libdrm should _not_ differ.
>
> Another day dream:
>
> Wouldn't it be nice if the uapi headers from Linux kernel would pass
> a simple quality check of compiling in userspace where they are meant to be
> used? Stand alone. Without magic tricks and additional libraries and their
> headers. Without glibc or any other libc implementation specific additions.
> The uapi headers define many parts of the Linux kernel API and ABI, and thus
> compiling them also without the 'official' GNU/Linux userspace libraries
> like glibc or libdrm does have some uses. For example API and ABI
> compatibility checks and API/ABI/system call fuzzers.
>
> Many headers required stdint.h types but Linux kernel headers do not
> define them in userspace, and then Linus has said that uapi headers
> should use the linux/types.h with double underscores. Thus my patches
> for fixing trivial compile errors turned into changing several stdint.h
> definitions to linux/types.h.

The problem is, for the most part, the driver specific gpu related
ioctl interfaces are not intended for general public consumption.
They have one consumer, ie. libdrm_$drivername (or perhaps mesa
directly).  They are complex interfaces, because GPUs are complex.
They are not intended to be used directly (or for the most part, even
indirectly) by random userspace applications.  And in fact the uapi
headers exported from kernel are not actually ever used.  (ie.
libdrm_$drivername uses it's own copy internally within libdrm.)

So Linus's argument against stdint types, as weak as it is, doesn't
even apply for gpu driver specific ioctls.

BR,
-R


> Yes, there have been some regressions in this work but to err is human.
> What is the actual problem and how can we (yes, including me) try to
> solve it?
>
> -Mikko
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

re

[Ali Saeed]

I need your assistance in executing a profitable project...

[PATCH 04/13] lustre: ->kss_scratch... are unused now

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
index d5efb42..84a915c 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
@@ -86,10 +86,6 @@ struct ksock_sched { /* per 
scheduler state */
int kss_nconns; /* # connections assigned to
 * this scheduler */
struct ksock_sched_info *kss_info;  /* owner of it */
-   union {
-   struct bio_vec  kss_scratch_bvec[LNET_MAX_IOV];
-   struct kvec kss_scratch_iov[LNET_MAX_IOV];
-   };
 };
 
 struct ksock_sched_info {
-- 
2.7.4

[PATCH 06/13] lustre: pass iov_iter to ->lnd_recv()

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/include/linux/lnet/lib-types.h  |  5 +---
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h|  3 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 32 --
 .../staging/lustre/lnet/klnds/socklnd/socklnd.h|  4 +--
 .../staging/lustre/lnet/klnds/socklnd/socklnd_cb.c | 21 ++
 drivers/staging/lustre/lnet/lnet/lib-move.c| 11 ++--
 drivers/staging/lustre/lnet/lnet/lo.c  | 24 
 7 files changed, 49 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h 
b/drivers/staging/lustre/include/linux/lnet/lib-types.h
index 7967b01..640ff72 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-types.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h
@@ -220,10 +220,7 @@ typedef struct lnet_lnd {
 * credit if the LND does flow control.
 */
int (*lnd_recv)(struct lnet_ni *ni, void *private, lnet_msg_t *msg,
-   int delayed, unsigned int niov,
-   struct kvec *iov, lnet_kiov_t *kiov,
-   unsigned int offset, unsigned int mlen,
-   unsigned int rlen);
+   int delayed, struct iov_iter *to, unsigned int rlen);
 
/*
 * lnet_parse() has had to delay processing of this message
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
index 078a0c3..f49483e 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
@@ -1034,5 +1034,4 @@ int  kiblnd_post_rx(struct kib_rx *rx, int credit);
 
 int  kiblnd_send(lnet_ni_t *ni, void *private, lnet_msg_t *lntmsg);
 int  kiblnd_recv(lnet_ni_t *ni, void *private, lnet_msg_t *lntmsg, int delayed,
-unsigned int niov, struct kvec *iov, lnet_kiov_t *kiov,
-unsigned int offset, unsigned int mlen, unsigned int rlen);
+struct iov_iter *to, unsigned int rlen);
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index 9eb1db6..1b20ae8 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -648,7 +648,7 @@ static int kiblnd_map_tx(lnet_ni_t *ni, struct kib_tx *tx, 
struct kib_rdma_desc
 
 static int
 kiblnd_setup_rd_iov(lnet_ni_t *ni, struct kib_tx *tx, struct kib_rdma_desc *rd,
-   unsigned int niov, struct kvec *iov, int offset, int nob)
+   unsigned int niov, const struct kvec *iov, int offset, int 
nob)
 {
struct kib_net *net = ni->ni_data;
struct page *page;
@@ -705,7 +705,7 @@ kiblnd_setup_rd_iov(lnet_ni_t *ni, struct kib_tx *tx, 
struct kib_rdma_desc *rd,
 
 static int
 kiblnd_setup_rd_kiov(lnet_ni_t *ni, struct kib_tx *tx, struct kib_rdma_desc 
*rd,
-int nkiov, lnet_kiov_t *kiov, int offset, int nob)
+int nkiov, const lnet_kiov_t *kiov, int offset, int nob)
 {
struct kib_net *net = ni->ni_data;
struct scatterlist *sg;
@@ -1719,8 +1719,7 @@ kiblnd_reply(lnet_ni_t *ni, struct kib_rx *rx, lnet_msg_t 
*lntmsg)
 
 int
 kiblnd_recv(lnet_ni_t *ni, void *private, lnet_msg_t *lntmsg, int delayed,
-   unsigned int niov, struct kvec *iov, lnet_kiov_t *kiov,
-   unsigned int offset, unsigned int mlen, unsigned int rlen)
+   struct iov_iter *to, unsigned int rlen)
 {
struct kib_rx *rx = private;
struct kib_msg *rxmsg = rx->rx_msg;
@@ -1730,10 +1729,9 @@ kiblnd_recv(lnet_ni_t *ni, void *private, lnet_msg_t 
*lntmsg, int delayed,
int post_credit = IBLND_POSTRX_PEER_CREDIT;
int rc = 0;
 
-   LASSERT(mlen <= rlen);
+   LASSERT(iov_iter_count(to) <= rlen);
LASSERT(!in_interrupt());
/* Either all pages or all vaddrs */
-   LASSERT(!(kiov && iov));
 
switch (rxmsg->ibm_type) {
default:
@@ -1749,16 +1747,16 @@ kiblnd_recv(lnet_ni_t *ni, void *private, lnet_msg_t 
*lntmsg, int delayed,
break;
}
 
-   if (kiov)
-   lnet_copy_flat2kiov(niov, kiov, offset,
+   if (to->type & ITER_BVEC)
+   lnet_copy_flat2kiov(to->nr_segs, to->bvec, 
to->iov_offset,
IBLND_MSG_SIZE, rxmsg,
offsetof(struct kib_msg, 
ibm_u.immediate.ibim_payload),
-   mlen);
+   iov_iter_count(to));
else
-   lnet_copy_flat2iov(niov, iov, offset,
+   lnet_copy_flat2iov(to->nr_segs, to->kvec, 
to->iov_offset,
  

[PATCH 02/13] ksocknal_lib_send_iov(): sendmsg doesn't bugger iovec...

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 .../lustre/lnet/klnds/socklnd/socklnd_lib.c| 38 ++
 1 file changed, 10 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
index 77bb29ff..8eb4a68 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
@@ -73,9 +73,9 @@ ksocknal_lib_zc_capable(struct ksock_conn *conn)
 int
 ksocknal_lib_send_iov(struct ksock_conn *conn, struct ksock_tx *tx)
 {
+   struct msghdr msg = {.msg_flags = MSG_DONTWAIT};
struct socket *sock = conn->ksnc_sock;
-   int nob;
-   int rc;
+   int nob, i;
 
if (*ksocknal_tunables.ksnd_enable_csum && /* checksum enabled */
conn->ksnc_proto == &ksocknal_protocol_v2x && /* V2.x connection  */
@@ -83,34 +83,16 @@ ksocknal_lib_send_iov(struct ksock_conn *conn, struct 
ksock_tx *tx)
!tx->tx_msg.ksm_csum)/* not checksummed  */
ksocknal_lib_csum_tx(tx);
 
-   /*
-* NB we can't trust socket ops to either consume our iovs
-* or leave them alone.
-*/
-   {
-#if SOCKNAL_SINGLE_FRAG_TX
-   struct kvec scratch;
-   struct kvec *scratchiov = &scratch;
-   unsigned int niov = 1;
-#else
-   struct kvec *scratchiov = conn->ksnc_scheduler->kss_scratch_iov;
-   unsigned int niov = tx->tx_niov;
-#endif
-   struct msghdr msg = {.msg_flags = MSG_DONTWAIT};
-   int i;
-
-   for (nob = i = 0; i < niov; i++) {
-   scratchiov[i] = tx->tx_iov[i];
-   nob += scratchiov[i].iov_len;
-   }
+   for (nob = i = 0; i < tx->tx_niov; i++)
+   nob += tx->tx_iov[i].iov_len;
 
-   if (!list_empty(&conn->ksnc_tx_queue) ||
-   nob < tx->tx_resid)
-   msg.msg_flags |= MSG_MORE;
+   if (!list_empty(&conn->ksnc_tx_queue) ||
+   nob < tx->tx_resid)
+   msg.msg_flags |= MSG_MORE;
 
-   rc = kernel_sendmsg(sock, &msg, scratchiov, niov, nob);
-   }
-   return rc;
+   iov_iter_kvec(&msg.msg_iter, WRITE | ITER_KVEC,
+ tx->tx_iov, tx->tx_niov, nob);
+   return sock_sendmsg(sock, &msg);
 }
 
 int
-- 
2.7.4

[PATCH 00/13] Lustre patches

[Oleg Drokin]

This is rebase of the previous set that got merged only half-way with
added signed-offs as requested.

I also added a patch to include James Simmons as a Lustre maintainer too
since he is performing a lot of work in the area.

Al Viro (7):
  ksocknal_lib_recv_iov(): recvmsg doesn't bugger iovec anymore...
  ksocknal_lib_send_iov(): sendmsg doesn't bugger iovec...
  ksocknal_lib_send_kiov(): sendmsg doesn't bugger iovec...
  lustre: ->kss_scratch... are unused now
  lustre: constify lib-move.c stuff
  lustre: pass iov_iter to ->lnd_recv()
  lustre: introduce lnet_copy_{k,}iov2iter(), kill
lnet_copy_{k,}iov2{k,}iov()

Emoly Liu (3):
  staging/lustre: Add spaces preferred around that '{+,-,*,/,|,<<,>>,&}'
  staging/lustre: Fix unnecessary parentheses around variables
  staging/lustre: Make alignment match open parenthesis

Oleg Drokin (3):
  staging/lustre: Always return EEXIST on mkdir for existing names
  staging/lustre: Remove unused cp_error from struct cl_page
  Add James Simmons as another Lustre maintainer

 MAINTAINERS|   1 +
 .../staging/lustre/include/linux/libcfs/libcfs.h   |   6 +-
 .../lustre/include/linux/libcfs/libcfs_debug.h |  10 +-
 .../staging/lustre/include/linux/lnet/lib-lnet.h   |  65 +---
 .../staging/lustre/include/linux/lnet/lib-types.h  |   5 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|   2 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h|   3 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c |  64 ++--
 .../staging/lustre/lnet/klnds/socklnd/socklnd.h|  10 +-
 .../staging/lustre/lnet/klnds/socklnd/socklnd_cb.c |  21 +-
 .../lustre/lnet/klnds/socklnd/socklnd_lib.c|  89 ++
 .../lustre/lnet/libcfs/linux/linux-crypto.c|   4 +-
 drivers/staging/lustre/lnet/lnet/lib-move.c| 329 +
 drivers/staging/lustre/lnet/lnet/lo.c  |  39 +--
 drivers/staging/lustre/lustre/include/cl_object.h  |   4 +-
 drivers/staging/lustre/lustre/include/lu_object.h  |   3 +-
 .../lustre/lustre/include/lustre/lustre_idl.h  |  42 +--
 .../lustre/lustre/include/lustre/lustre_user.h |   4 +-
 drivers/staging/lustre/lustre/include/lustre_fid.h |   2 +-
 .../staging/lustre/lustre/include/lustre_lite.h|   2 +-
 .../staging/lustre/lustre/include/obd_support.h|  13 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_extent.c   |   4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c|   8 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_internal.h |  17 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lib.c  |   8 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lock.c |  26 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c|  21 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_pool.c |   4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_request.c  |  14 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_resource.c |   5 +-
 drivers/staging/lustre/lustre/llite/dir.c  |   5 +-
 drivers/staging/lustre/lustre/llite/file.c |   4 +-
 drivers/staging/lustre/lustre/llite/llite_lib.c|  25 +-
 drivers/staging/lustre/lustre/llite/llite_mmap.c   |   4 +-
 drivers/staging/lustre/lustre/llite/lproc_llite.c  |  14 +-
 drivers/staging/lustre/lustre/llite/namei.c|  12 +-
 drivers/staging/lustre/lustre/llite/rw.c   |   9 +-
 drivers/staging/lustre/lustre/llite/rw26.c |   2 +-
 drivers/staging/lustre/lustre/llite/statahead.c|   3 +-
 drivers/staging/lustre/lustre/llite/super25.c  |   4 +-
 drivers/staging/lustre/lustre/llite/vvp_object.c   |   2 +-
 drivers/staging/lustre/lustre/llite/vvp_page.c |   4 +-
 drivers/staging/lustre/lustre/lov/lov_ea.c |   3 +-
 drivers/staging/lustre/lustre/lov/lov_obd.c|  22 +-
 drivers/staging/lustre/lustre/lov/lov_pool.c   |  18 +-
 drivers/staging/lustre/lustre/mdc/mdc_locks.c  |   5 +-
 drivers/staging/lustre/lustre/mdc/mdc_reint.c  |   5 +-
 drivers/staging/lustre/lustre/obdclass/cl_page.c   |   4 +-
 drivers/staging/lustre/lustre/obdclass/debug.c |   4 +-
 drivers/staging/lustre/lustre/obdclass/genops.c|   6 +-
 drivers/staging/lustre/lustre/obdclass/llog.c  |   2 +-
 .../lustre/lustre/obdclass/lustre_handles.c|   2 +-
 .../staging/lustre/lustre/obdclass/obd_config.c|  14 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |  10 +-
 drivers/staging/lustre/lustre/obdclass/obdo.c  |   6 +-
 .../staging/lustre/lustre/obdecho/echo_internal.h  |   4 +-
 drivers/staging/lustre/lustre/osc/osc_cache.c  |   6 +-
 .../staging/lustre/lustre/osc/osc_cl_internal.h|   2 +-
 drivers/staging/lustre/lustre/osc/osc_io.c |   2 +-
 drivers/staging/lustre/lustre/osc/osc_request.c|  14 +-
 drivers/staging/lustre/lustre/ptlrpc/import.c  |   6 +-
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c|   2 +-
 drivers/staging/lustre/lustre/ptlrpc/niobuf.c  |   3 +-
 .../staging/lustre/lustre/ptlrpc/pack_generic.c|  11 +-
 drivers/staging/lustre/lustre/ptlrp

[PATCH 03/13] ksocknal_lib_send_kiov(): sendmsg doesn't bugger iovec...

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 .../lustre/lnet/klnds/socklnd/socklnd_lib.c| 29 --
 1 file changed, 5 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
index 8eb4a68..6c95e98 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
@@ -106,10 +106,6 @@ ksocknal_lib_send_kiov(struct ksock_conn *conn, struct 
ksock_tx *tx)
/* Not NOOP message */
LASSERT(tx->tx_lnetmsg);
 
-   /*
-* NB we can't trust socket ops to either consume our iovs
-* or leave them alone.
-*/
if (tx->tx_msg.ksm_zc_cookies[0]) {
/* Zero copy is enabled */
struct sock *sk = sock->sk;
@@ -132,34 +128,19 @@ ksocknal_lib_send_kiov(struct ksock_conn *conn, struct 
ksock_tx *tx)
rc = tcp_sendpage(sk, page, offset, fragsize, msgflg);
}
} else {
-#if SOCKNAL_SINGLE_FRAG_TX || !SOCKNAL_RISK_KMAP_DEADLOCK
-   struct kvec scratch;
-   struct kvec *scratchiov = &scratch;
-   unsigned int niov = 1;
-#else
-#ifdef CONFIG_HIGHMEM
-#warning "XXX risk of kmap deadlock on multiple frags..."
-#endif
-   struct kvec *scratchiov = conn->ksnc_scheduler->kss_scratch_iov;
-   unsigned int niov = tx->tx_nkiov;
-#endif
struct msghdr msg = {.msg_flags = MSG_DONTWAIT};
int i;
 
-   for (nob = i = 0; i < niov; i++) {
-   scratchiov[i].iov_base = kmap(kiov[i].bv_page) +
-kiov[i].bv_offset;
-   nob += scratchiov[i].iov_len = kiov[i].bv_len;
-   }
+   for (nob = i = 0; i < tx->tx_nkiov; i++)
+   nob += kiov[i].bv_len;
 
if (!list_empty(&conn->ksnc_tx_queue) ||
nob < tx->tx_resid)
msg.msg_flags |= MSG_MORE;
 
-   rc = kernel_sendmsg(sock, &msg, (struct kvec *)scratchiov, 
niov, nob);
-
-   for (i = 0; i < niov; i++)
-   kunmap(kiov[i].bv_page);
+   iov_iter_bvec(&msg.msg_iter, WRITE | ITER_BVEC,
+ kiov, tx->tx_nkiov, nob);
+   rc = sock_sendmsg(sock, &msg);
}
return rc;
 }
-- 
2.7.4

[PATCH 07/13] lustre: introduce lnet_copy_{k,}iov2iter(), kill lnet_copy_{k,}iov2{k,}iov()

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: James Simmons 
Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/include/linux/lnet/lib-lnet.h   |  57 +---
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c |  37 ++-
 drivers/staging/lustre/lnet/lnet/lib-move.c| 314 -
 drivers/staging/lustre/lnet/lnet/lo.c  |  35 +--
 4 files changed, 86 insertions(+), 357 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h 
b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
index 1c5418e..a59c5e99c 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
@@ -613,65 +613,12 @@ int lnet_extract_kiov(int dst_niov, lnet_kiov_t *dst,
  int src_niov, const lnet_kiov_t *src,
  unsigned int offset, unsigned int len);
 
-void lnet_copy_iov2iov(unsigned int ndiov, const struct kvec *diov,
-  unsigned int doffset,
+void lnet_copy_iov2iter(struct iov_iter *to,
unsigned int nsiov, const struct kvec *siov,
unsigned int soffset, unsigned int nob);
-void lnet_copy_kiov2iov(unsigned int niov, const struct kvec *iov,
-   unsigned int iovoffset,
+void lnet_copy_kiov2iter(struct iov_iter *to,
 unsigned int nkiov, const lnet_kiov_t *kiov,
 unsigned int kiovoffset, unsigned int nob);
-void lnet_copy_iov2kiov(unsigned int nkiov, const lnet_kiov_t *kiov,
-   unsigned int kiovoffset,
-unsigned int niov, const struct kvec *iov,
-unsigned int iovoffset, unsigned int nob);
-void lnet_copy_kiov2kiov(unsigned int ndkiov, const lnet_kiov_t *dkiov,
-unsigned int doffset,
- unsigned int nskiov, const lnet_kiov_t *skiov,
- unsigned int soffset, unsigned int nob);
-
-static inline void
-lnet_copy_iov2flat(int dlen, void *dest, unsigned int doffset,
-  unsigned int nsiov, const struct kvec *siov, unsigned int 
soffset,
-  unsigned int nob)
-{
-   struct kvec diov = {/*.iov_base = */ dest, /*.iov_len = */ dlen};
-
-   lnet_copy_iov2iov(1, &diov, doffset,
- nsiov, siov, soffset, nob);
-}
-
-static inline void
-lnet_copy_kiov2flat(int dlen, void *dest, unsigned int doffset,
-   unsigned int nsiov, const lnet_kiov_t *skiov,
-   unsigned int soffset, unsigned int nob)
-{
-   struct kvec diov = {/* .iov_base = */ dest, /* .iov_len = */ dlen};
-
-   lnet_copy_kiov2iov(1, &diov, doffset,
-  nsiov, skiov, soffset, nob);
-}
-
-static inline void
-lnet_copy_flat2iov(unsigned int ndiov, const struct kvec *diov, unsigned int 
doffset,
-  int slen, void *src, unsigned int soffset, unsigned int nob)
-{
-   struct kvec siov = {/*.iov_base = */ src, /*.iov_len = */slen};
-
-   lnet_copy_iov2iov(ndiov, diov, doffset,
- 1, &siov, soffset, nob);
-}
-
-static inline void
-lnet_copy_flat2kiov(unsigned int ndiov, const lnet_kiov_t *dkiov,
-   unsigned int doffset, int slen, void *src,
-   unsigned int soffset, unsigned int nob)
-{
-   struct kvec siov = {/* .iov_base = */ src, /* .iov_len = */ slen};
-
-   lnet_copy_iov2kiov(ndiov, dkiov, doffset,
-  1, &siov, soffset, nob);
-}
 
 void lnet_me_unlink(lnet_me_t *me);
 
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index 1b20ae8..2581744 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -1499,6 +1499,7 @@ kiblnd_send(lnet_ni_t *ni, void *private, lnet_msg_t 
*lntmsg)
lnet_kiov_t *payload_kiov = lntmsg->msg_kiov;
unsigned int payload_offset = lntmsg->msg_offset;
unsigned int payload_nob = lntmsg->msg_len;
+   struct iov_iter from;
struct kib_msg *ibmsg;
struct kib_rdma_desc  *rd;
struct kib_tx *tx;
@@ -1518,6 +1519,17 @@ kiblnd_send(lnet_ni_t *ni, void *private, lnet_msg_t 
*lntmsg)
/* payload is either all vaddrs or all pages */
LASSERT(!(payload_kiov && payload_iov));
 
+   if (payload_kiov)
+   iov_iter_bvec(&from, ITER_BVEC | WRITE,
+ payload_kiov, payload_niov,
+ payload_nob + payload_offset);
+   else
+   iov_iter_kvec(&from, ITER_KVEC | WRITE,
+ payload_iov, payload_niov,
+ payload_nob + payload_offset);
+
+   iov_iter_advance(&from, payload_offset);
+
switch (type) {
default:
LBUG();
@@ -1637,17 +1649,8 @@ kiblnd_send(lnet_ni_t *n

[PATCH 12/13] staging/lustre: Remove unused cp_error from struct cl_page

[Oleg Drokin]

cp_error member is not really set anywhere, so kill
it and the only printing user of it too.

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/include/cl_object.h | 2 --
 drivers/staging/lustre/lustre/obdclass/cl_page.c  | 4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/cl_object.h 
b/drivers/staging/lustre/lustre/include/cl_object.h
index 78613a9..6d8f956 100644
--- a/drivers/staging/lustre/lustre/include/cl_object.h
+++ b/drivers/staging/lustre/lustre/include/cl_object.h
@@ -726,8 +726,6 @@ struct cl_page {
struct mutexcp_mutex;
/** Linkage of pages within cl_req. */
struct list_head   cp_flight;
-   /** Transfer error. */
-   int   cp_error;
 
/**
 * Page type. Only CPT_TRANSIENT is used so far. Immutable after
diff --git a/drivers/staging/lustre/lustre/obdclass/cl_page.c 
b/drivers/staging/lustre/lustre/obdclass/cl_page.c
index db2dc6b..d903f71 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_page.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_page.c
@@ -989,9 +989,9 @@ void cl_page_header_print(const struct lu_env *env, void 
*cookie,
  lu_printer_t printer, const struct cl_page *pg)
 {
(*printer)(env, cookie,
-  "page@%p[%d %p %d %d %d %p %p %#x]\n",
+  "page@%p[%d %p %d %d %p %p %#x]\n",
   pg, atomic_read(&pg->cp_ref), pg->cp_obj,
-  pg->cp_state, pg->cp_error, pg->cp_type,
+  pg->cp_state, pg->cp_type,
   pg->cp_owner, pg->cp_req, pg->cp_flags);
 }
 EXPORT_SYMBOL(cl_page_header_print);
-- 
2.7.4

[PATCH 10/13] staging/lustre: Fix unnecessary parentheses around variables

[Oleg Drokin]

From: Emoly Liu 

This patch fixes all checkpatch occurences of
"CHECK: Unnecessary parentheses around xxx"
in Lustre code.

Signed-off-by: Emoly Liu 
Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/lustre/include/lustre/lustre_user.h   |  2 +-
 drivers/staging/lustre/lustre/lov/lov_obd.c  |  4 ++--
 drivers/staging/lustre/lustre/lov/lov_pool.c | 16 
 drivers/staging/lustre/lustre/obdclass/genops.c  |  4 ++--
 drivers/staging/lustre/lustre/obdclass/llog.c|  2 +-
 drivers/staging/lustre/lustre/obdclass/lustre_handles.c  |  2 +-
 drivers/staging/lustre/lustre/obdclass/obd_config.c  |  2 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c   |  2 +-
 drivers/staging/lustre/lustre/osc/osc_request.c  |  2 +-
 drivers/staging/lustre/lustre/ptlrpc/pack_generic.c  |  6 +++---
 10 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
index 5fc0c5c..e077687 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
@@ -978,7 +978,7 @@ struct hsm_user_request {
 /** Return pointer to data field in a hsm user request */
 static inline void *hur_data(struct hsm_user_request *hur)
 {
-   return &(hur->hur_user_item[hur->hur_request.hr_itemcount]);
+   return &hur->hur_user_item[hur->hur_request.hr_itemcount];
 }
 
 /**
diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c 
b/drivers/staging/lustre/lustre/lov/lov_obd.c
index bc71e4f..52651c4 100644
--- a/drivers/staging/lustre/lustre/lov/lov_obd.c
+++ b/drivers/staging/lustre/lustre/lov/lov_obd.c
@@ -940,7 +940,7 @@ int lov_process_config_base(struct obd_device *obd, struct 
lustre_cfg *lcfg,
}
case LCFG_PARAM: {
struct lprocfs_static_vars lvars = { NULL };
-   struct lov_desc *desc = &(obd->u.lov.desc);
+   struct lov_desc *desc = &obd->u.lov.desc;
 
if (!desc) {
rc = -EINVAL;
@@ -1460,7 +1460,7 @@ static int lov_iocontrol(unsigned int cmd, struct 
obd_export *exp, int len,
}
 
desc = (struct lov_desc *)data->ioc_inlbuf1;
-   memcpy(desc, &(lov->desc), sizeof(*desc));
+   memcpy(desc, &lov->desc, sizeof(*desc));
 
uuidp = (struct obd_uuid *)data->ioc_inlbuf2;
genp = (__u32 *)data->ioc_inlbuf3;
diff --git a/drivers/staging/lustre/lustre/lov/lov_pool.c 
b/drivers/staging/lustre/lustre/lov/lov_pool.c
index 639e086..f8c8a36 100644
--- a/drivers/staging/lustre/lustre/lov/lov_pool.c
+++ b/drivers/staging/lustre/lustre/lov/lov_pool.c
@@ -61,7 +61,7 @@ void lov_pool_putref(struct pool_desc *pool)
LASSERT(hlist_unhashed(&pool->pool_hash));
LASSERT(list_empty(&pool->pool_list));
LASSERT(!pool->pool_debugfs_entry);
-   lov_ost_pool_free(&(pool->pool_obds));
+   lov_ost_pool_free(&pool->pool_obds);
kfree(pool);
}
 }
@@ -260,7 +260,7 @@ static int pool_proc_show(struct seq_file *s, void *v)
tgt = pool_tgt(iter->pool, iter->idx);
up_read(&pool_tgt_rw_sem(iter->pool));
if (tgt)
-   seq_printf(s, "%s\n", obd_uuid2str(&(tgt->ltd_uuid)));
+   seq_printf(s, "%s\n", obd_uuid2str(&tgt->ltd_uuid));
 
return 0;
 }
@@ -400,7 +400,7 @@ int lov_pool_new(struct obd_device *obd, char *poolname)
struct pool_desc *new_pool;
int rc;
 
-   lov = &(obd->u.lov);
+   lov = &obd->u.lov;
 
if (strlen(poolname) > LOV_MAXPOOLNAME)
return -ENAMETOOLONG;
@@ -471,7 +471,7 @@ int lov_pool_del(struct obd_device *obd, char *poolname)
struct lov_obd *lov;
struct pool_desc *pool;
 
-   lov = &(obd->u.lov);
+   lov = &obd->u.lov;
 
/* lookup and kill hash reference */
pool = cfs_hash_del_key(lov->lov_pools_hash_body, poolname);
@@ -503,7 +503,7 @@ int lov_pool_add(struct obd_device *obd, char *poolname, 
char *ostname)
unsigned int lov_idx;
int rc;
 
-   lov = &(obd->u.lov);
+   lov = &obd->u.lov;
 
pool = cfs_hash_lookup(lov->lov_pools_hash_body, poolname);
if (!pool)
@@ -517,7 +517,7 @@ int lov_pool_add(struct obd_device *obd, char *poolname, 
char *ostname)
if (!lov->lov_tgts[lov_idx])
continue;
if (obd_uuid_equals(&ost_uuid,
-   &(lov->lov_tgts[lov_idx]->ltd_uuid)))
+   &lov->lov_tgts[lov_idx]->ltd_uuid))
break;
}
/* test if ost found in lov */
@@ -547,7 +547,7 @@ int lov_pool_remove(struct obd_device *obd, char *poolname, 
char *ostname)
unsigned int lov_idx;
int rc = 0;
 
-   lov 

[PATCH 11/13] staging/lustre: Make alignment match open parenthesis

[Oleg Drokin]

From: Emoly Liu 

This patch fixes most of checkpatch occurences of
"CHECK: Alignment should match open parenthesis"
in Lustre code.

Signed-off-by: Emoly Liu 
Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/include/linux/libcfs/libcfs.h   |   6 +-
 .../lustre/include/linux/libcfs/libcfs_debug.h |  10 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|   2 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c |   5 +-
 .../staging/lustre/lnet/klnds/socklnd/socklnd.h|   2 +-
 .../lustre/lnet/libcfs/linux/linux-crypto.c|   4 +-
 drivers/staging/lustre/lustre/include/cl_object.h  |   2 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_extent.c   |   4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c|   4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_internal.h |  17 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lib.c  |   8 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lock.c |  26 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c|  21 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_pool.c |   4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_request.c  |  10 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_resource.c |   5 +-
 drivers/staging/lustre/lustre/llite/dir.c  |   3 +-
 drivers/staging/lustre/lustre/llite/llite_lib.c|   4 +-
 drivers/staging/lustre/lustre/llite/rw.c   |   4 +-
 drivers/staging/lustre/lustre/llite/statahead.c|   3 +-
 drivers/staging/lustre/lustre/llite/vvp_page.c |   4 +-
 drivers/staging/lustre/lustre/lov/lov_obd.c|   4 +-
 drivers/staging/lustre/lustre/mdc/mdc_locks.c  |   3 +-
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |   2 +-
 drivers/staging/lustre/lustre/osc/osc_cache.c  |   4 +-
 drivers/staging/lustre/lustre/ptlrpc/niobuf.c  |   3 +-
 .../staging/lustre/lustre/ptlrpc/pack_generic.c|   5 +-
 drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c|   5 +-
 drivers/staging/lustre/lustre/ptlrpc/sec_plain.c   |  18 +-
 drivers/staging/lustre/lustre/ptlrpc/service.c |  22 +-
 drivers/staging/lustre/lustre/ptlrpc/wiretest.c| 288 ++---
 31 files changed, 257 insertions(+), 245 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
index 3f6447c..3b92d38 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
@@ -138,8 +138,8 @@ struct lnet_debugfs_symlink_def {
 void lustre_insert_debugfs(struct ctl_table *table,
   const struct lnet_debugfs_symlink_def *symlinks);
 int lprocfs_call_handler(void *data, int write, loff_t *ppos,
- void __user *buffer, size_t *lenp,
- int (*handler)(void *data, int write,
- loff_t pos, void __user *buffer, int len));
+void __user *buffer, size_t *lenp,
+int (*handler)(void *data, int write, loff_t pos,
+   void __user *buffer, int len));
 
 #endif /* _LIBCFS_H */
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h 
b/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h
index 25adab1..b7bd6e8 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h
@@ -247,19 +247,19 @@ do {  
\
 #define LCONSOLE_EMERG(format, ...) CDEBUG(D_CONSOLE | D_EMERG, format, ## 
__VA_ARGS__)
 
 int libcfs_debug_msg(struct libcfs_debug_msg_data *msgdata,
-   const char *format1, ...)
+const char *format1, ...)
__printf(2, 3);
 
 int libcfs_debug_vmsg2(struct libcfs_debug_msg_data *msgdata,
- const char *format1,
- va_list args, const char *format2, ...)
+  const char *format1,
+  va_list args, const char *format2, ...)
__printf(4, 5);
 
 /* other external symbols that tracefile provides: */
 int cfs_trace_copyin_string(char *knl_buffer, int knl_buffer_nob,
-   const char __user *usr_buffer, int usr_buffer_nob);
+   const char __user *usr_buffer, int usr_buffer_nob);
 int cfs_trace_copyout_string(char __user *usr_buffer, int usr_buffer_nob,
-   const char *knl_buffer, char *append);
+const char *knl_buffer, char *append);
 
 #define LIBCFS_DEBUG_FILE_PATH_DEFAULT "/tmp/lustre-log"
 
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 4f5978b..e93dbeb 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -618,7 +618,7 @@ static int kiblnd_get_completion_vector(struct kib_conn 
*conn, int cpt)
 }
 
 struct kib_

[PATCH 09/13] staging/lustre: Add spaces preferred around that '{+,-,*,/,|,<<

[Oleg Drokin]

From: Emoly Liu 

This patch fixes all checkpatch occurences of
"CHECK: spaces preferred around that '{+,-,*,/,|,<<,>>,&}' (ctx:VxV)"
in Lustre code.

Signed-off-by: Emoly Liu 
Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/include/lu_object.h  |  3 +-
 .../lustre/lustre/include/lustre/lustre_idl.h  | 42 +++---
 .../lustre/lustre/include/lustre/lustre_user.h |  2 +-
 drivers/staging/lustre/lustre/include/lustre_fid.h |  2 +-
 .../staging/lustre/lustre/include/lustre_lite.h|  2 +-
 .../staging/lustre/lustre/include/obd_support.h| 13 +++
 drivers/staging/lustre/lustre/ldlm/ldlm_flock.c|  4 +--
 drivers/staging/lustre/lustre/ldlm/ldlm_request.c  |  4 +--
 drivers/staging/lustre/lustre/llite/dir.c  |  2 +-
 drivers/staging/lustre/lustre/llite/file.c |  4 +--
 drivers/staging/lustre/lustre/llite/llite_lib.c| 21 ++-
 drivers/staging/lustre/lustre/llite/llite_mmap.c   |  4 +--
 drivers/staging/lustre/lustre/llite/lproc_llite.c  | 14 
 drivers/staging/lustre/lustre/llite/namei.c|  4 +--
 drivers/staging/lustre/lustre/llite/rw.c   |  5 +--
 drivers/staging/lustre/lustre/llite/rw26.c |  2 +-
 drivers/staging/lustre/lustre/llite/super25.c  |  4 +--
 drivers/staging/lustre/lustre/llite/vvp_object.c   |  2 +-
 drivers/staging/lustre/lustre/lov/lov_ea.c |  3 +-
 drivers/staging/lustre/lustre/lov/lov_obd.c| 14 
 drivers/staging/lustre/lustre/lov/lov_pool.c   |  2 +-
 drivers/staging/lustre/lustre/mdc/mdc_locks.c  |  2 +-
 drivers/staging/lustre/lustre/mdc/mdc_reint.c  |  5 +--
 drivers/staging/lustre/lustre/obdclass/debug.c |  4 +--
 drivers/staging/lustre/lustre/obdclass/genops.c|  2 +-
 .../staging/lustre/lustre/obdclass/obd_config.c| 12 +++
 drivers/staging/lustre/lustre/obdclass/obd_mount.c |  6 ++--
 drivers/staging/lustre/lustre/obdclass/obdo.c  |  6 ++--
 .../staging/lustre/lustre/obdecho/echo_internal.h  |  4 +--
 drivers/staging/lustre/lustre/osc/osc_cache.c  |  2 +-
 .../staging/lustre/lustre/osc/osc_cl_internal.h|  2 +-
 drivers/staging/lustre/lustre/osc/osc_io.c |  2 +-
 drivers/staging/lustre/lustre/osc/osc_request.c| 12 ---
 drivers/staging/lustre/lustre/ptlrpc/import.c  |  6 ++--
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c|  2 +-
 drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c |  4 +--
 drivers/staging/lustre/lustre/ptlrpc/service.c |  2 +-
 37 files changed, 121 insertions(+), 105 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lu_object.h 
b/drivers/staging/lustre/lustre/include/lu_object.h
index 6e25c1b..1e8421c 100644
--- a/drivers/staging/lustre/lustre/include/lu_object.h
+++ b/drivers/staging/lustre/lustre/include/lu_object.h
@@ -1025,7 +1025,8 @@ enum lu_context_tag {
/**
 * Contexts usable in cache shrinker thread.
 */
-   LCT_SHRINKER  = LCT_MD_THREAD|LCT_DT_THREAD|LCT_CL_THREAD|LCT_NOREF
+   LCT_SHRINKER  = LCT_MD_THREAD | LCT_DT_THREAD | LCT_CL_THREAD |
+   LCT_NOREF
 };
 
 /**
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index 32471a6..7410a8a 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -1318,13 +1318,13 @@ void lustre_swab_ptlrpc_body(struct ptlrpc_body *pb);
 #define CLIENT_CONNECT_MDT_REQD (OBD_CONNECT_IBITS | OBD_CONNECT_FID | \
 OBD_CONNECT_FULL20)
 
-#define OBD_OCD_VERSION(major, minor, patch, fix) (((major)<<24) + \
- ((minor)<<16) + \
- ((patch)<<8) + (fix))
-#define OBD_OCD_VERSION_MAJOR(version) ((int)((version)>>24)&255)
-#define OBD_OCD_VERSION_MINOR(version) ((int)((version)>>16)&255)
-#define OBD_OCD_VERSION_PATCH(version) ((int)((version)>>8)&255)
-#define OBD_OCD_VERSION_FIX(version)   ((int)(version)&255)
+#define OBD_OCD_VERSION(major, minor, patch, fix) (((major) << 24) + \
+  ((minor) << 16) + \
+  ((patch) << 8) + (fix))
+#define OBD_OCD_VERSION_MAJOR(version) ((int)((version) >> 24) & 255)
+#define OBD_OCD_VERSION_MINOR(version) ((int)((version) >> 16) & 255)
+#define OBD_OCD_VERSION_PATCH(version) ((int)((version) >> 8) & 255)
+#define OBD_OCD_VERSION_FIX(version)   ((int)(version) & 255)
 
 /* This structure is used for both request and reply.
  *
@@ -2028,7 +2028,7 @@ void lustre_swab_generic_32s(__u32 *val);
 
 #define MDS_INODELOCK_MAXSHIFT 5
 /* This FULL lock is useful to take on unlink sort of operations */
-#define MDS_INODELOCK_FULL ((1<<(MDS_INODELOCK_MAXSHIFT+1))-1)
+#define MDS_INODELOCK_FULL ((1 << (MDS_INODELOCK_MAXSHIFT + 1)) - 1)
 
 /* NOTE: until Lustre 1.8.7/2.1.1 the fid

[PATCH 13/13] Add James Simmons as another Lustre maintainer

[Oleg Drokin]

James Simmons is also spendign a lot of efforts on
cleaning up staging tree Lustre code and also
helps to sync up all the missing changes from the other tree.

Signed-off-by: Oleg Drokin 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a306795..f277cfd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11154,6 +11154,7 @@ F:  drivers/staging/media/lirc/
 STAGING - LUSTRE PARALLEL FILESYSTEM
 M: Oleg Drokin 
 M: Andreas Dilger 
+M: James Simmons 
 L: lustre-de...@lists.lustre.org (moderated for non-subscribers)
 W: http://wiki.lustre.org/
 S: Maintained
-- 
2.7.4

[PATCH 05/13] lustre: constify lib-move.c stuff

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/include/linux/lnet/lib-lnet.h   | 28 +++---
 drivers/staging/lustre/lnet/lnet/lib-move.c| 20 
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h 
b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
index 513a822..1c5418e 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
@@ -605,34 +605,34 @@ void lnet_counters_reset(void);
 
 unsigned int lnet_iov_nob(unsigned int niov, struct kvec *iov);
 int lnet_extract_iov(int dst_niov, struct kvec *dst,
-int src_niov, struct kvec *src,
+int src_niov, const struct kvec *src,
  unsigned int offset, unsigned int len);
 
 unsigned int lnet_kiov_nob(unsigned int niov, lnet_kiov_t *iov);
 int lnet_extract_kiov(int dst_niov, lnet_kiov_t *dst,
- int src_niov, lnet_kiov_t *src,
+ int src_niov, const lnet_kiov_t *src,
  unsigned int offset, unsigned int len);
 
-void lnet_copy_iov2iov(unsigned int ndiov, struct kvec *diov,
+void lnet_copy_iov2iov(unsigned int ndiov, const struct kvec *diov,
   unsigned int doffset,
-   unsigned int nsiov, struct kvec *siov,
+   unsigned int nsiov, const struct kvec *siov,
unsigned int soffset, unsigned int nob);
-void lnet_copy_kiov2iov(unsigned int niov, struct kvec *iov,
+void lnet_copy_kiov2iov(unsigned int niov, const struct kvec *iov,
unsigned int iovoffset,
-unsigned int nkiov, lnet_kiov_t *kiov,
+unsigned int nkiov, const lnet_kiov_t *kiov,
 unsigned int kiovoffset, unsigned int nob);
-void lnet_copy_iov2kiov(unsigned int nkiov, lnet_kiov_t *kiov,
+void lnet_copy_iov2kiov(unsigned int nkiov, const lnet_kiov_t *kiov,
unsigned int kiovoffset,
-unsigned int niov, struct kvec *iov,
+unsigned int niov, const struct kvec *iov,
 unsigned int iovoffset, unsigned int nob);
-void lnet_copy_kiov2kiov(unsigned int ndkiov, lnet_kiov_t *dkiov,
+void lnet_copy_kiov2kiov(unsigned int ndkiov, const lnet_kiov_t *dkiov,
 unsigned int doffset,
- unsigned int nskiov, lnet_kiov_t *skiov,
+ unsigned int nskiov, const lnet_kiov_t *skiov,
  unsigned int soffset, unsigned int nob);
 
 static inline void
 lnet_copy_iov2flat(int dlen, void *dest, unsigned int doffset,
-  unsigned int nsiov, struct kvec *siov, unsigned int soffset,
+  unsigned int nsiov, const struct kvec *siov, unsigned int 
soffset,
   unsigned int nob)
 {
struct kvec diov = {/*.iov_base = */ dest, /*.iov_len = */ dlen};
@@ -643,7 +643,7 @@ lnet_copy_iov2flat(int dlen, void *dest, unsigned int 
doffset,
 
 static inline void
 lnet_copy_kiov2flat(int dlen, void *dest, unsigned int doffset,
-   unsigned int nsiov, lnet_kiov_t *skiov,
+   unsigned int nsiov, const lnet_kiov_t *skiov,
unsigned int soffset, unsigned int nob)
 {
struct kvec diov = {/* .iov_base = */ dest, /* .iov_len = */ dlen};
@@ -653,7 +653,7 @@ lnet_copy_kiov2flat(int dlen, void *dest, unsigned int 
doffset,
 }
 
 static inline void
-lnet_copy_flat2iov(unsigned int ndiov, struct kvec *diov, unsigned int doffset,
+lnet_copy_flat2iov(unsigned int ndiov, const struct kvec *diov, unsigned int 
doffset,
   int slen, void *src, unsigned int soffset, unsigned int nob)
 {
struct kvec siov = {/*.iov_base = */ src, /*.iov_len = */slen};
@@ -663,7 +663,7 @@ lnet_copy_flat2iov(unsigned int ndiov, struct kvec *diov, 
unsigned int doffset,
 }
 
 static inline void
-lnet_copy_flat2kiov(unsigned int ndiov, lnet_kiov_t *dkiov,
+lnet_copy_flat2kiov(unsigned int ndiov, const lnet_kiov_t *dkiov,
unsigned int doffset, int slen, void *src,
unsigned int soffset, unsigned int nob)
 {
diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c 
b/drivers/staging/lustre/lnet/lnet/lib-move.c
index 6a3f2e1..7d8d2d6 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
@@ -166,8 +166,8 @@ lnet_iov_nob(unsigned int niov, struct kvec *iov)
 EXPORT_SYMBOL(lnet_iov_nob);
 
 void
-lnet_copy_iov2iov(unsigned int ndiov, struct kvec *diov, unsigned int doffset,
- unsigned int nsiov, struct kvec *siov, unsigned int soffset,
+lnet_copy_iov2iov(unsigned int ndiov, const struct kvec *diov, unsigned int 
doffset,
+ unsigned int nsiov, const struct kvec *siov, un

[PATCH 08/13] staging/lustre: Always return EEXIST on mkdir for existing names

[Oleg Drokin]

if the name already exists, but we don't have write permissions
in the parent, force talking to the MDS to determine what
more sensical error code to return.
This also happens to fix matlab and other such programs that
assume that EEXIST is the only valid error code for mkdir of
an existing directory.

Signed-off-by: Oleg Drokin 
---
 drivers/staging/lustre/lustre/llite/namei.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index 09e1801..8350943 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -541,8 +541,12 @@ static struct dentry *ll_lookup_nd(struct inode *parent, 
struct dentry *dentry,
CDEBUG(D_VFSTRACE, "VFS Op:name=%pd, dir="DFID"(%p),flags=%u\n",
   dentry, PFID(ll_inode2fid(parent)), parent, flags);
 
-   /* Optimize away (CREATE && !OPEN). Let .create handle the race. */
-   if ((flags & LOOKUP_CREATE) && !(flags & LOOKUP_OPEN))
+   /* Optimize away (CREATE && !OPEN). Let .create handle the race.
+* but only if we have write permissions there, otherwise we need
+* to proceed with lookup. LU-4185
+*/
+   if ((flags & LOOKUP_CREATE) && !(flags & LOOKUP_OPEN) &&
+   (inode_permission(parent, MAY_WRITE | MAY_EXEC) == 0))
return NULL;
 
if (flags & (LOOKUP_PARENT|LOOKUP_OPEN|LOOKUP_CREATE))
-- 
2.7.4

[PATCH 01/13] ksocknal_lib_recv_iov(): recvmsg doesn't bugger iovec anymore...

[Oleg Drokin]

From: Al Viro 

Signed-off-by: Al Viro 
Signed-off-by: Oleg Drokin 
---
 .../lustre/lnet/klnds/socklnd/socklnd_lib.c| 22 +-
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
index fe7b9f9..77bb29ff 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
@@ -201,14 +201,7 @@ ksocknal_lib_eager_ack(struct ksock_conn *conn)
 int
 ksocknal_lib_recv_iov(struct ksock_conn *conn)
 {
-#if SOCKNAL_SINGLE_FRAG_RX
-   struct kvec scratch;
-   struct kvec *scratchiov = &scratch;
-   unsigned int niov = 1;
-#else
-   struct kvec *scratchiov = conn->ksnc_scheduler->kss_scratch_iov;
unsigned int niov = conn->ksnc_rx_niov;
-#endif
struct kvec *iov = conn->ksnc_rx_iov;
struct msghdr msg = {
.msg_flags = 0
@@ -220,20 +213,15 @@ ksocknal_lib_recv_iov(struct ksock_conn *conn)
int sum;
__u32 saved_csum;
 
-   /*
-* NB we can't trust socket ops to either consume our iovs
-* or leave them alone.
-*/
LASSERT(niov > 0);
 
-   for (nob = i = 0; i < niov; i++) {
-   scratchiov[i] = iov[i];
-   nob += scratchiov[i].iov_len;
-   }
+   for (nob = i = 0; i < niov; i++)
+   nob += iov[i].iov_len;
+
LASSERT(nob <= conn->ksnc_rx_nob_wanted);
 
-   rc = kernel_recvmsg(conn->ksnc_sock, &msg, scratchiov, niov, nob,
-   MSG_DONTWAIT);
+   iov_iter_kvec(&msg.msg_iter, READ | ITER_KVEC, iov, niov, nob);
+   rc = sock_recvmsg(conn->ksnc_sock, &msg, MSG_DONTWAIT);
 
saved_csum = 0;
if (conn->ksnc_proto == &ksocknal_protocol_v2x) {
-- 
2.7.4

Re: [PATCH 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

[Sergei Shtylyov]

Hello.

On 08/20/2016 11:32 PM, Randy Li wrote:


On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).

We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.

We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit) in chip, which does a more full
reset.  The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).

It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.

The original patches came from Doug Anderson .

Signed-off-by: Randy Li 
---
 drivers/usb/dwc2/core_intr.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index d85c5c9..c31c3fe 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c

[...]

@@ -379,6 +380,14 @@ static void dwc2_handle_wakeup_detected_intr(struct 
dwc2_hsotg *hsotg)
/* Restart the Phy Clock */
pcgcctl &= ~PCGCTL_STOPPCLK;
dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
+
+   /* It is a quirk in Rockchip RK3288, causing by
+* a hardware bug. This will propagate out and
+* eventually we'll re-enumerate the device.
+* Not great but the best we can do */


  The preferred multi-line comment style is this:

/*
 * bla
 * bla
 */

   Yours is close. :-)

[...]

MBR, Sergei

[PATCH 2/4] phy: rockchip-usb: use rockchip_usb_phy_reset to reset phy during wakeup

[Randy Li]

It is a hardware bug in RK3288, the only way to solve it is to
reset the phy.

Signed-off-by: Randy Li 
---
 drivers/phy/phy-rockchip-usb.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
index 2a7381f..734987f 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int enable_usb_uart;
 
@@ -64,6 +65,7 @@ struct rockchip_usb_phy {
struct clk_hw   clk480m_hw;
struct phy  *phy;
booluart_enabled;
+   struct reset_control *reset;
 };
 
 static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
@@ -144,9 +146,23 @@ static int rockchip_usb_phy_power_on(struct phy *_phy)
return clk_prepare_enable(phy->clk480m);
 }
 
+static int rockchip_usb_phy_reset(struct phy *_phy)
+{
+   struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+
+   if (phy->reset) {
+   reset_control_assert(phy->reset);
+   udelay(10);
+   reset_control_deassert(phy->reset);
+   }
+
+   return 0;
+}
+
 static const struct phy_ops ops = {
.power_on   = rockchip_usb_phy_power_on,
.power_off  = rockchip_usb_phy_power_off,
+   .reset  = rockchip_usb_phy_reset,
.owner  = THIS_MODULE,
 };
 
@@ -185,6 +201,10 @@ static int rockchip_usb_phy_init(struct 
rockchip_usb_phy_base *base,
return -EINVAL;
}
 
+   rk_phy->reset = of_reset_control_get(child, "phy-reset");
+   if (IS_ERR(rk_phy->reset))
+   rk_phy->reset = NULL;
+
rk_phy->reg_offset = reg_offset;
 
rk_phy->clk = of_clk_get_by_name(child, "phyclk");
-- 
2.7.4

[PATCH 1/4] phy: Add reset callback

[Randy Li]

The only use for this is for solving a hardware design problem in
usb of Rockchip RK3288.

Signed-off-by: Randy Li 
---
 include/linux/phy/phy.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index f08b672..4d34607 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -36,6 +36,7 @@ enum phy_mode {
  * @power_on: powering on the phy
  * @power_off: powering off the phy
  * @set_mode: set the mode of the phy
+ * @reset: reseting the phy
  * @owner: the module owner containing the ops
  */
 struct phy_ops {
@@ -44,6 +45,7 @@ struct phy_ops {
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
int (*set_mode)(struct phy *phy, enum phy_mode mode);
+   int (*reset)(struct phy *phy);
struct module *owner;
 };
 
-- 
2.7.4

[PATCH 4/4] ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

[Randy Li]

The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
has a hardware errata that causes everything to get confused when we get
a remote wakeup.  We'll use the reset that's in the CRU to reset the
port when it's in a bad state.

Note that we add the reset to both dwc2 controllers even though only one
has the errata in case we find some other use for this reset that's
unrelated to the current hardware errata.  Only the host port gets the
quirk property, though.

This patch came from Doug Anderson  originally.

Signed-off-by: Randy Li 
---
 arch/arm/boot/dts/rk3288.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 48ca4e4..646f49d 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -855,6 +855,8 @@
clocks = <&cru SCLK_OTGPHY0>;
clock-names = "phyclk";
#clock-cells = <0>;
+   resets = <&cru SRST_USBOTG_PHY>;
+   reset-names = "phy-reset";
};
 
usbphy1: usb-phy@334 {
@@ -871,6 +873,9 @@
clocks = <&cru SCLK_OTGPHY2>;
clock-names = "phyclk";
#clock-cells = <0>;
+   resets = <&cru SRST_USBHOST1_PHY>;
+   reset-names = "phy-reset";
+
};
};
};
-- 
2.7.4

[PATCH 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

[Randy Li]

On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).

We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.

We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit) in chip, which does a more full
reset.  The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).

It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.

The original patches came from Doug Anderson .

Signed-off-by: Randy Li 
---
 drivers/usb/dwc2/core_intr.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index d85c5c9..c31c3fe 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg 
*hsotg)
 static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
 {
int ret;
+   struct device_node *np = hsotg->dev->of_node;
 
/* Clear interrupt */
dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
@@ -379,6 +380,14 @@ static void dwc2_handle_wakeup_detected_intr(struct 
dwc2_hsotg *hsotg)
/* Restart the Phy Clock */
pcgcctl &= ~PCGCTL_STOPPCLK;
dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
+
+   /* It is a quirk in Rockchip RK3288, causing by
+* a hardware bug. This will propagate out and
+* eventually we'll re-enumerate the device. 
+* Not great but the best we can do */
+   if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
+   hsotg->phy->ops->reset(hsotg->phy);
+
mod_timer(&hsotg->wkp_timer,
  jiffies + msecs_to_jiffies(71));
} else {
-- 
2.7.4

[PATCH 0/4 v4] usb: dwc2: fix the usb host for host port at RK32

[Randy Li]

Hello All:
 This version would move reset into phy. I wanted to implement a hard
code version but I meet some problem with ioremap reset controller,
in order to keep my word, I offer this version this time.

Randy Li (4):
  phy: Add reset callback
  phy: rockchip-usb: use rockchip_usb_phy_reset to reset phy during
wakeup
  usb: dwc2: assert phy reset when waking up in rk3288 platform
  ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

 arch/arm/boot/dts/rk3288.dtsi  |  5 +
 drivers/phy/phy-rockchip-usb.c | 20 
 drivers/usb/dwc2/core_intr.c   |  9 +
 include/linux/phy/phy.h|  2 ++
 4 files changed, 36 insertions(+)

-- 
2.7.4

Re: [PATCH 6/6] Add dockerfile

[Theodore Ts'o]

On Sat, Aug 20, 2016 at 02:31:26PM +0300, Dmitry Monakhov wrote:
> > I'm not sure I see the advantage of doing this in a container, I
> > guess.  I just do in my standard laptop environment today.
> I can not because I laptop from famous thinkpad t430 series with
> flaky SSD which starts to return EIO after intensive load.
> https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T430s-Intel-SSD-520-180GB-issue/td-p/888083

Hmm, I never buy a Lenovo SSD; they're overpriced.  So I always get my
Thinkpads with a 500mb HDD, and then replace it with a Samsumg 840/850
EVO/PRO SSD.

> Also. What about RH/SUSE/Fedora or even Gentoo people? They are exit :)
> And if we give them just chance to try debian w/o complexities
> maybe they will become debian adepts.

You only need Debain to build the image.  If you are just using the
pre-built root_fs.img, you can just download it and go.

Speaking of which, that's one thing which I don't understand about
your Dockerfile.  In the build step you just download the prebuilt
root_fs.img from kernel.org.  There are comments in your Dockerfile which say:

# Fetch and build xfstests-bld
# In order to build root_image from scratch privileged operation are required,
# so it is impossible during build stage.
# One can make it like this:
# docker run -i -t --privileged --rm dmonakhov/xfstests-bld "cd 
kvm-xfstests/test-appliance && ./gen-image"
# During build stage we simply fetch image precreated by tytso@

... but while this will create a new root_fs.img file, as soon as
you're you're done the container will exit, and then the root_fs.img
file will be blown away, right?

The other thing I'll note here is that the Dockerfile is serving two
use cases.  One is to user Docker to do automated build testing.  The
other is for people who want to run multiple instances of kvm-xfstests
using the container services.

For the second, we don't really want to include all of the build
artifacts and build and source trees in Docker image that the users
will have to pull down over the network.  And using kvm-xfstests
--update-xfstests means a lot of extra wasted I/O, since we're
packaging up the tar file, then copying it into file, and then
unpacking it inside the guest VM, etc.

So for the second case, you'd really want to create a Docker image
which had the minimum packages needed to actually *run* the tests,
with the pre-installed root_fs image.

For the first case, all you need to do is to have the Dockerfile
create the xfstests.tar.gz file.  I suppose this could be used as a
poor man's build engine if you don't want to run the build on your
local machine.  What I do is my top-level config.custom has:

BUILD_ENV="schroot -c jessie64 --"
SUDO_ENV="schroot -c jessie64 -u root --"

That's my pristine build chroot, and so when I run ./do-all, what gets
executed is:

schroot -c jessie64 -- make clean
schroot -c jessie64 -- make
schroot -c jessie64 -- make tarball
cd kvm-xfstests/test-appliance
schroot -c jessie64 -u root -- ./gen-image

I'm pretty sure this is going to be faster than waiting for Docker to
build the image, and then for me to download the image and extract the
xfststs.tar.gz file.  (But then again, I have a fully working laptop
with functional SSD's not sourced by Lenovo :-).

- Ted

Re: [PATCH 2/2] net: ethernet: renesas: ravb: use new api ethtool_{get|set}_link_ksettings

[Sergei Shtylyov]

On 08/20/2016 01:52 AM, Philippe Reynes wrote:


The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 

[...]

Acked-by: Sergei Shtylyov 

   Sorry for missing the sh_eth patchset. :-<

MBR, Sergei

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

[Sergei Shtylyov]

Hello.

On 08/20/2016 01:52 AM, 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_dev in the private structure, and update the driver to use the
one contained in struct net_device.

Signed-off-by: Philippe Reynes 

[...]

Acked-by: Sergei Shtylyov 

MBR, Sergei

Re: [PATCH 0/3] hostap: Fine-tuning for a few functions

[Arend van Spriel]

On 20-08-16 18:43, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 20 Aug 2016 18:35:43 +0200
> 
> A few update suggestions were taken into account
> from static source code analysis.

Is it worth touching this old stuff especially when you are not making
any functional changes.

Regards,
Arend

> Markus Elfring (3):
>   Use memdup_user()
>   Delete an unnecessary jump label
>   Delete unnecessary variable initialisations
> 
>  .../net/wireless/intersil/hostap/hostap_ioctl.c| 36 
> --
>  1 file changed, 12 insertions(+), 24 deletions(-)
> 

hi

[Tjenarvi Tjenarvi]

good evening 

http://saydamyazilim.net/serve.php?temperature=s1m6nk9p7yw4nu





Tjenarvi Tjenarvi

Re: [Documentation] State of CPU controller in cgroup v2

[Andy Lutomirski]

On Sat, Aug 20, 2016 at 8:56 AM, Tejun Heo  wrote:
> Hello, Andy.
>
> On Wed, Aug 17, 2016 at 01:18:24PM -0700, Andy Lutomirski wrote:
>> >   2-1-1. Process Granularity
>> >
>> >   For memory, because an address space is shared between all threads
>> >   of a process, the terminal consumer is a process, not a thread.
>> >   Separating the threads of a single process into different memory
>> >   control domains doesn't make semantical sense.  cgroup v2 ensures
>> >   that all controller can agree on the same organization by requiring
>> >   that threads of the same process belong to the same cgroup.
>>
>> I haven't followed all of the history here, but it seems to me that
>> this argument is less accurate than it appears.  Linux, for better or
>> for worse, has somewhat orthogonal concepts of thread groups
>> (processes), mms, and file tables.  An mm has VMAs in it, and VMAs can
>> reference things (files, etc) that hold resources.  (Two mms can share
>> resources by mapping the same thing or using fork().)  File tables
>> hold files, and files can use resources.  Both of these are, at best,
>> moderately good approximations of what actually holds resources.
>> Meanwhile, threads (tasks) do syscalls, take page faults, *allocate*
>> resources, etc.
>>
>> So I think it's not really true to say that the "terminal consumer" of
>> anything is a process, not a thread.
>
> The terminal consumer is actually the mm context.  A task may be the
> allocating entity but not always for itself.
>
> This becomes clear whenever an entity is allocating memory on behalf
> of someone else - get_user_pages(), khugepaged, swapoff and so on (and
> likely userfaultfd too).  When a task is trying to add a page to a
> VMA, the task might not have any relationship with the VMA other than
> that it's operating on it for someone else.  The page has to be
> charged to whoever is responsible for the VMA and the only ownership
> which can be established is the containing mm_struct.

This surprises me a bit.  If I do access_process_vm(), then I would
have expected the charge to go the caller, not the mm being accessed.

What happens if a program calls read(2), though?  A page may be
inserted into page cache on behalf of an address_space without any
particular mm being involved.  There will usually be a calling task,
though.

But this is all very memcg-specific.  What about other cgroups?  I/O
is per-task, right?  Scheduling is definitely per-task.

>
> While a mm_struct technically may not map to a process, it is a very
> close approxmiation which is hardly ever broken in practice.
>
>> While it's certainly easier to think about assigning processes to
>> cgroups, and I certainly agree that, in the common case, it's the
>> right thing to do, I don't see why requiring it is a good idea.  Can
>> we turn this around: what actually goes wrong if cgroup v2 were to
>> allow assigning individual threads if a user specifically requests it?
>
> Consider the scenario where you have somebody faulting on behalf of a
> foreign VMA, but the thread who created and is actively using that VMA
> is in a different cgroup than the process leader.  Who are we going to
> charge?  All possible answers seem erratic.
>

Indeed, and this problem is probably not solvable in practice unless
you charge all involved cgroups.  But the caller's *mm* is entirely
irrelevant here, so I don't see how this implies that cgroups need to
keep tasks in the same process together.  The relevant entities are
the calling *task* and the target mm, and you're going to be
hard-pressed to ensure that they belong to the same cgroup, so I think
you need to be able handle weird cases in which there isn't an
obviously correct cgroup to charge.

>> >   there are other reasons to enforce process granularity.  One
>> >   important one is isolating system-level management operations from
>> >   in-process application operations.  The cgroup interface, being a
>> >   virtual filesystem, is very unfit for multiple independent
>> >   operations taking place at the same time as most operations have to
>> >   be multi-step and there is no way to synchronize multiple accessors.
>> >   See also [5] Documentation/cgroup-v2.txt, "R-2. Thread Granularity"
>>
>> I don't buy this argument at all.  System-level code is likely to
>> assign single process *trees*, which are a different beast entirely.
>> I.e. you fork, move the child into a cgroup, and that child and its
>> children stay in that cgroup.  I don't see how the thread/process
>> distinction matters.
>
> Good point on the multi-process issue, this is something which nagged
> me a bit while working on rgroup, although I have to point out that
> the issue here is one of not going far enough rather than the approach
> being wrong.  There are limitations to scoping it to individual
> processes but that doesn't negate the underlying problem or the
> usefulness of in-process control.
>
> For system-level and process-level operations to not step on each
> 

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Marek Olšák]

On Sat, Aug 20, 2016 at 8:28 PM, Marek Olšák  wrote:
> On Sat, Aug 20, 2016 at 8:08 PM, Mikko Rapeli  wrote:
>> Cc'ing lkml.
>>
>> On Sat, Aug 20, 2016 at 12:05:54PM +0200, Marek Olšák wrote:
>>> On Sat, Aug 20, 2016 at 12:54 AM, Emil Velikov  
>>> wrote:
>>> > On 19 August 2016 at 15:26, Christian König  
>>> > wrote:
>>> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>>> >>>
>>> >>> From: Marek Olšák 
>>> >>>
>>> >>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>>> >>>
>>> >>> See the comment in the code. Basically, don't do cleanups in this 
>>> >>> header.
>>> >>>
>>> >>> Signed-off-by: Marek Olšák 
>>> >>
>>> >>
>>> >> I completely agree with you that this was a bad move, but I fear that we
>>> >> will run into opposition with that.
>>> >>
>>> > Please check the facts before introducing RATHER ANNOYING AND HARD TO
>>> > READ COMMENT IN ALL CAPS.
>>> >
>>> > Story time:
>>> > I was dreaming of a day were we can stop installing these headers,
>>> > thus making deprecation a bit easier process.
>>> > Yet after failing to convince Dave and Daniel on a number of occasions
>>> > I've accepted that those headers _are_ here to stay. And yes they
>>> > _are_ the UAPI, even though no applications are meant to use them but
>>> > the libdrm 'version'.
>>> > Thus any changes to the libdrm ones should be a mirror of the ones
>>> > here and libdrm should _not_ differ.
>>> >
>>> > But let's ignore all that and imagine that those headers are _not_
>>> > UAPI. That gives us even greater reason to _not_ use the uintx_t types
>>> > but the kernel __uX ones. The series that did these changes had a fair
>>> > few references why we want that.
>>> >
>>> > Yes, I can imagine that the situation isn't ideal, and/or not that
>>> > clear. Then again a check with git log should have straightened things
>>> > out.
>>> > If not _please_ help us improve this (documentation and/or others).
>>> >
>>> >
>>> > And last but not least, please share with up what inspired this -
>>> > (build/runtime) regression, attempted sync with libdrm, other ?
>>>
>>> Syncing with libdrm became difficult. I'd like the diff between kernel
>>> and libdrm to be as small as possible.
>>>
>>> We must take into account that the uapi headers can potentially be
>>> implemented by a different OS. That's why they are in libdrm and
>>> that's why nobody should make random changes to them in the kernel
>>> tree. Do not think like a kernel developer isolated in Linux and just
>>> consider the broader use case. If you do, you'll realize that it
>>> simply doesn't make sense to use the __uX types here.
>>
>> When libdrm is combined with Linux kernel, then libdrm should be using
>> the uapi headers from the kernel. For various reasons there are embedded
>> kernel header copies in libdrm, glibc and basically everywhere but there
>> should not be need for that.
>
> You quoted what I had written but you didn't read it.

Here's why libdrm can't use the uapi headers: It would break the very
common use case and that is building the latest userspace driver stack
on top of an old kernel. The userspace needs the latest headers, not
the installed ones. Only then is it fully compatible both ways.

Marek

[RESEND PATCH v2 3/4] ARM64: dts: meson-gxbb: Add Meson GXBB PWM Controller nodes

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index e502c24..e3f4d36 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -153,6 +153,27 @@
status = "disabled";
};
 
+   pwm_ab: pwm@8550 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x08550 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_cd: pwm@8650 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x08650 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_ef: pwm@86c0 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x086c0 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
uart_C: serial@8700 {
compatible = "amlogic,meson-uart";
reg = <0x0 0x8700 0x0 0x14>;
@@ -212,6 +233,13 @@
clocks = <&xtal>;
status = "disabled";
};
+
+   pwm_ab_AO: pwm@550 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x0550 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
};
 
periphs: periphs@c8834000 {
-- 
1.9.1

[RESEND PATCH v2 2/4] dt-bindings: pwm: Add bindings for Meson PWM Controller

[Neil Armstrong]

Add bindings for the Amlogic PWM Controller in Meson8b and GXBB SoCs.

Signed-off-by: Neil Armstrong 
---
 Documentation/devicetree/bindings/pwm/pwm-meson.txt | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-meson.txt

diff --git a/Documentation/devicetree/bindings/pwm/pwm-meson.txt 
b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
new file mode 100644
index 000..e06aed0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
@@ -0,0 +1,21 @@
+Amlogic Meson PWM Controller
+=
+
+Required properties:
+- compatible: Shall contain "amlogic,meson8b-pwm" or "amlogic,meson-gxbb-pwm".
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
+  the cells format.
+
+Optional properties:
+- clocks: Could contain one or two parents clocks phandle for each of the two 
pwm channels.
+- clock-names: Could contain at least the "clkin0" and/or "clkin1" names.
+
+Example:
+pwm_ab: pwm@8550 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x08550 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   clocks = <&xtal>, <&xtal>;
+   clock-names = "clkin0", "clkin1";
+}
-- 
1.9.1

[RESEND PATCH v2 0/4] pwm: Add Amlogic Meson SoC PWM Controller

[Neil Armstrong]

Add support for the PWM controller found in Amlogic Meson SoCs.
This controller provides a dual PWM output with 4 selectable clock source
and a two level divider to achieve a better PWM range.

Currently Meson8b and GXBB SoCs are supported.

Changes since v1 at 
http://lkml.kernel.org/r/1466173784-15625-1-git-send-email-narmstr...@baylibre.com
 :
- fix meson8b dtsi

Neil Armstrong (4):
  pwm: Add support for Meson PWM Controller
  dt-bindings: pwm: Add bindings for Meson PWM Controller
  ARM64: dts: meson-gxbb: Add Meson GXBB PWM Controller nodes
  ARM: dts: meson8b: Add Meson8b PWM Controller nodes

 .../devicetree/bindings/pwm/pwm-meson.txt  |  21 +
 arch/arm/boot/dts/meson8b.dtsi |  21 +
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|  28 ++
 drivers/pwm/Kconfig|   9 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-meson.c| 491 +
 6 files changed, 571 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-meson.txt
 create mode 100644 drivers/pwm/pwm-meson.c

-- 
1.9.1

[RESEND PATCH v2 4/4] ARM: dts: meson8b: Add Meson8b PWM Controller nodes

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/meson8b.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index fc4080d..41fd536 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -162,6 +162,27 @@
reg = <0xc1108000 0x4>, <0xc1104000 0x460>;
};
 
+   pwm_ab: pwm@8550 {
+   compatible = "amlogic,meson8b-pwm";
+   reg = <0xc1108550 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_cd: pwm@8650 {
+   compatible = "amlogic,meson8b-pwm";
+   reg = <0xc1108650 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_ef: pwm@86c0 {
+   compatible = "amlogic,meson8b-pwm";
+   reg = <0xc11086c0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
pinctrl_cbus: pinctrl@c1109880 {
compatible = "amlogic,meson8b-cbus-pinctrl";
reg = <0xc1109880 0x10>;
-- 
1.9.1

[RESEND PATCH v2 1/4] pwm: Add support for Meson PWM Controller

[Neil Armstrong]

Add support for the PWM controller found in the Amlogic SoCs.
This driver supports the Meson8b and GXBB SoCs.

Signed-off-by: Neil Armstrong 
---
 drivers/pwm/Kconfig |   9 +
 drivers/pwm/Makefile|   1 +
 drivers/pwm/pwm-meson.c | 491 
 3 files changed, 501 insertions(+)
 create mode 100644 drivers/pwm/pwm-meson.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 80a566a..bf01288 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -262,6 +262,15 @@ config PWM_LPSS_PLATFORM
  To compile this driver as a module, choose M here: the module
  will be called pwm-lpss-platform.
 
+config PWM_MESON
+   tristate "Amlogic Meson PWM driver"
+   depends on ARCH_MESON
+   help
+ The platform driver for Amlogic Meson PWM controller.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-meson.
+
 config PWM_MTK_DISP
tristate "MediaTek display PWM driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index feef1dd..1194c54 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
 obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o
 obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o
 obj-$(CONFIG_PWM_LPSS_PLATFORM)+= pwm-lpss-platform.o
+obj-$(CONFIG_PWM_MESON)+= pwm-meson.o
 obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
 obj-$(CONFIG_PWM_MXS)  += pwm-mxs.o
 obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
new file mode 100644
index 000..9e7ecf5
--- /dev/null
+++ b/drivers/pwm/pwm-meson.c
@@ -0,0 +1,491 @@
+/*
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ * Copyright (C) 2014 Amlogic, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ * The full GNU General Public License is included in this distribution
+ * in the file called COPYING.
+ *
+ * BSD LICENSE
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ * Copyright (C) 2014 Amlogic, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_PWM_A  0x0
+#define REG_PWM_B  0x4
+#define PWM_HIGH_SHIFT 16
+
+#define REG_MISC_AB0x8
+#define MISC_B_CLK_EN  BIT(23)
+#define MISC_A_CLK_EN  BIT(15)
+#define MISC_CLK_DIV_MASK  0x7f
+#define MISC_B_CLK_DIV_SHIFT   16
+#define MISC_A_CLK_DIV_SHIFT   8
+#define MISC_B_CLK_SEL_SHIFT   6
+#define MISC_A_CLK_SEL_SHIFT   4
+#define MISC_CLK_SEL_WIDTH 2
+#defi

Re: [PATCH] Try to support analog audio codec at firefly reload

[John Keeping]

On Tue, Aug 16, 2016 at 04:42:06AM +0800, Randy Li wrote:
>   This patch could enabled the es8328 codec at firefly reload board,
> but it doesn't not really work. I disable the mute of channel 
> Left mix and Right mix in alsamixer, I could hear the noise from
> my headphone, but it never be a music. 
>   I just send this patch here to see whether somebody could figure
> out what is wrong, I am really not familiar with sound.

Have you tried adding an mclk-fs setting to the simple-audio-card?  You
probably want to set it to 256, which will allow 44.1kHz, 48kHz, 88.2kHz
and 96kHz at the codec.  This will give more functionality than pinning
the clock to a specific rate.

For the Rock2 Square, I write a machine driver for the sound because the
headphone GPIO setup cannot be made to work with simple-audio-card; I
found the Firefly Reload schematic and it looks like the configuration
hardware is very similar.  It's a bit of a mess but you can find it on
Github [1] if you want to take a look.

[1] https://github.com/johnkeeping/linux/tree/topic/audio

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Marek Olšák]

On Sat, Aug 20, 2016 at 8:08 PM, Mikko Rapeli  wrote:
> Cc'ing lkml.
>
> On Sat, Aug 20, 2016 at 12:05:54PM +0200, Marek Olšák wrote:
>> On Sat, Aug 20, 2016 at 12:54 AM, Emil Velikov  
>> wrote:
>> > On 19 August 2016 at 15:26, Christian König  
>> > wrote:
>> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>> >>>
>> >>> From: Marek Olšák 
>> >>>
>> >>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>> >>>
>> >>> See the comment in the code. Basically, don't do cleanups in this header.
>> >>>
>> >>> Signed-off-by: Marek Olšák 
>> >>
>> >>
>> >> I completely agree with you that this was a bad move, but I fear that we
>> >> will run into opposition with that.
>> >>
>> > Please check the facts before introducing RATHER ANNOYING AND HARD TO
>> > READ COMMENT IN ALL CAPS.
>> >
>> > Story time:
>> > I was dreaming of a day were we can stop installing these headers,
>> > thus making deprecation a bit easier process.
>> > Yet after failing to convince Dave and Daniel on a number of occasions
>> > I've accepted that those headers _are_ here to stay. And yes they
>> > _are_ the UAPI, even though no applications are meant to use them but
>> > the libdrm 'version'.
>> > Thus any changes to the libdrm ones should be a mirror of the ones
>> > here and libdrm should _not_ differ.
>> >
>> > But let's ignore all that and imagine that those headers are _not_
>> > UAPI. That gives us even greater reason to _not_ use the uintx_t types
>> > but the kernel __uX ones. The series that did these changes had a fair
>> > few references why we want that.
>> >
>> > Yes, I can imagine that the situation isn't ideal, and/or not that
>> > clear. Then again a check with git log should have straightened things
>> > out.
>> > If not _please_ help us improve this (documentation and/or others).
>> >
>> >
>> > And last but not least, please share with up what inspired this -
>> > (build/runtime) regression, attempted sync with libdrm, other ?
>>
>> Syncing with libdrm became difficult. I'd like the diff between kernel
>> and libdrm to be as small as possible.
>>
>> We must take into account that the uapi headers can potentially be
>> implemented by a different OS. That's why they are in libdrm and
>> that's why nobody should make random changes to them in the kernel
>> tree. Do not think like a kernel developer isolated in Linux and just
>> consider the broader use case. If you do, you'll realize that it
>> simply doesn't make sense to use the __uX types here.
>
> When libdrm is combined with Linux kernel, then libdrm should be using
> the uapi headers from the kernel. For various reasons there are embedded
> kernel header copies in libdrm, glibc and basically everywhere but there
> should not be need for that.

You quoted what I had written but you didn't read it.

>
> What exact problems did you now encounter with libdrm? Did something fail
> to compile on Linux or other OS'es?

Read the thread again. I described the problem clearly.

Marek

Re: [PATCH] lib/Kconfig.debug: fix typo in select statement

[Paul E. McKenney]

On Sat, Aug 20, 2016 at 12:16:10PM +0200, Valentin Rothberg wrote:
> Commit 484f29c7430b3 ("bug: Provide toggle for BUG on data corruption")
> added a Kconfig select statement on CONFIG_DEBUG_LIST, but the CONFIG_
> prefix is only used in Make and C(PP) syntax.  Remove the CONFIG_ prefix
> to correctly select the Kconfig option DEBUG_LIST.
> 
> Signed-off-by: Valentin Rothberg 

Well, color me blind!

Good catch, queued for review and testing.

Kees, Steve, Rik, any objections?

Thanx, Paul

> ---
> I detected the issue with scripts/checkkconfigsymbols.py
> 
>  lib/Kconfig.debug | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 5dea4d0a5a07..c2bbaae13d04 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -2009,7 +2009,7 @@ config TEST_STATIC_KEYS
> 
>  config BUG_ON_DATA_CORRUPTION
>   bool "Trigger a BUG when data corruption is detected"
> - select CONFIG_DEBUG_LIST
> + select DEBUG_LIST
>   help
> Select this option if the kernel should BUG when it encounters
> data corruption in kernel memory structures when they get checked
> -- 
> 2.9.3
> 

Re: [PATCH v6 0/3] virtually mapped stacks

[Andy Lutomirski]

On Thu, Aug 11, 2016 at 2:35 AM, Andy Lutomirski  wrote:
> Andy Lutomirski (3):
>   fork: Add generic vmalloced stack support
>   dma-api: Teach the "DMA-from-stack" check about vmapped stacks
>   x86/mm/64: Enable vmapped stacks


Hi Ingo-

Is this a good format for this series?  Is there anything I need to do?

Re: [PATCH v2 1/4] dt-bindings: vendor-prefixes: Add Sierra Wireless

[Neil Armstrong]

On 08/19/2016 03:48 PM, Rob Herring wrote:
> On Thu, Aug 18, 2016 at 03:11:18PM +0200, Neil Armstrong wrote:
>> Add Sierra Wireless as swi vendor prefix.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 1992aa9..5a8881f 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -254,6 +254,7 @@ starry   Starry Electronic Technology (ShenZhen) Co., LTD
>>  startek Startek
>>  ste ST-Ericsson
>>  stericsson  ST-Ericsson
>> +swi Sierra Wireless
> 
> swir is the stock ticker. Can you use that?

I hoped to use swi since they use is a lot, bet swir is indeed more coherent.

> 
> This is going to have some conflicts with some sorting fixes, so I plan 
> to pick up this patch separately.

OK/\.

> 
> Rob
> 
Thanks,
Neil

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Mikko Rapeli]

Cc'ing lkml.

On Sat, Aug 20, 2016 at 12:05:54PM +0200, Marek Olšák wrote:
> On Sat, Aug 20, 2016 at 12:54 AM, Emil Velikov  
> wrote:
> > On 19 August 2016 at 15:26, Christian König  wrote:
> >> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
> >>>
> >>> From: Marek Olšák 
> >>>
> >>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
> >>>
> >>> See the comment in the code. Basically, don't do cleanups in this header.
> >>>
> >>> Signed-off-by: Marek Olšák 
> >>
> >>
> >> I completely agree with you that this was a bad move, but I fear that we
> >> will run into opposition with that.
> >>
> > Please check the facts before introducing RATHER ANNOYING AND HARD TO
> > READ COMMENT IN ALL CAPS.
> >
> > Story time:
> > I was dreaming of a day were we can stop installing these headers,
> > thus making deprecation a bit easier process.
> > Yet after failing to convince Dave and Daniel on a number of occasions
> > I've accepted that those headers _are_ here to stay. And yes they
> > _are_ the UAPI, even though no applications are meant to use them but
> > the libdrm 'version'.
> > Thus any changes to the libdrm ones should be a mirror of the ones
> > here and libdrm should _not_ differ.
> >
> > But let's ignore all that and imagine that those headers are _not_
> > UAPI. That gives us even greater reason to _not_ use the uintx_t types
> > but the kernel __uX ones. The series that did these changes had a fair
> > few references why we want that.
> >
> > Yes, I can imagine that the situation isn't ideal, and/or not that
> > clear. Then again a check with git log should have straightened things
> > out.
> > If not _please_ help us improve this (documentation and/or others).
> >
> >
> > And last but not least, please share with up what inspired this -
> > (build/runtime) regression, attempted sync with libdrm, other ?
> 
> Syncing with libdrm became difficult. I'd like the diff between kernel
> and libdrm to be as small as possible.
> 
> We must take into account that the uapi headers can potentially be
> implemented by a different OS. That's why they are in libdrm and
> that's why nobody should make random changes to them in the kernel
> tree. Do not think like a kernel developer isolated in Linux and just
> consider the broader use case. If you do, you'll realize that it
> simply doesn't make sense to use the __uX types here.

When libdrm is combined with Linux kernel, then libdrm should be using
the uapi headers from the kernel. For various reasons there are embedded
kernel header copies in libdrm, glibc and basically everywhere but there
should not be need for that.

What exact problems did you now encounter with libdrm? Did something fail
to compile on Linux or other OS'es?

-Mikko

Re: [PATCH v2 1/2] ARM: dts: Add MDM9615 dtsi

[Neil Armstrong]

On 08/18/2016 08:08 PM, Stephen Boyd wrote:
> On 08/18, Neil Armstrong wrote:
>> +
>> +/dts-v1/;
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/ {
>> +model = "Qualcomm MDM9615";
>> +compatible = "qcom,mdm9615";
>> +interrupt-parent = <&intc>;
>> +
>> +cpus {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +interrupts = ;
> 
> What's this interrupt for? 0x304 seems wrong as well, because 0x3
> would mean two CPUs and this is a SPI and not a PPI?
Bad copy paste

> 
>> +
>> +cpu0: cpu@0 {
>> +compatible = "arm,cortex-a5";
>> +device_type = "cpu";
>> +next-level-cache = <&L2>;
>> +};
>> +};
>> +
>> +cpu-pmu {
>> +compatible = "arm,cortex-a5-pmu";
>> +interrupts = ;
>> +};
>> +
>> +clocks {
>> +cxo_board {
>> +compatible = "fixed-clock";
>> +#clock-cells = <0>;
>> +clock-frequency = <1920>;
>> +clock-output-names = "cxo_board";
> 
> This is unnecessary as it's the same name as the node name.
> 
>> +};
>> +};
>> +
>> +soc: soc {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +compatible = "simple-bus";
>> +
>> +L2: l2-cache {
>> +compatible = "arm,pl310-cache";
>> +reg = <0x0204 0x1000>;
>> +arm,data-latency = <2 2 0>;
>> +cache-unified;
>> +cache-level = <2>;
>> +};
>> +
>> +intc: interrupt-controller@200 {
>> +compatible = "qcom,msm-qgic2";
>> +interrupt-controller;
>> +#interrupt-cells = <3>;
>> +reg = <0x0200 0x1000>,
>> +  <0x02002000 0x1000>;
>> +};
>> +
>> +timer@200a000 {
>> +compatible = "qcom,kpss-timer", "qcom,msm-timer";
>> +interrupts = ,
>> + ,
>> + ;
> 
> 0x101 for all those flags?

Bad copy paste

> 
>> +reg = <0x0200a000 0x100>;
>> +clock-frequency = <2700>,
>> +  <32768>;
>> +cpu-offset = <0x8>;
>> +};
>> +
>> +msmgpio: pinctrl@80 {
>> +compatible = "qcom,mdm9615-pinctrl", "syscon";
> 
> What's the syscon for?

Leftover for USB HSIC calibration registers

> 
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +interrupts = ;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +reg = <0x80 0x4000>;
>> +};
>> +
>> +gcc: clock-controller@90 {
>> +compatible = "qcom,gcc-mdm9615";
>> +#clock-cells = <1>;
>> +#reset-cells = <1>;
>> +reg = <0x90 0x4000>;
>> +};
>> +
>> +lcc: clock-controller@2800 {
>> +compatible = "qcom,lcc-mdm9615";
>> +reg = <0x2800 0x1000>;
>> +#clock-cells = <1>;
>> +#reset-cells = <1>;
>> +};
>> +
>> +l2cc: clock-controller@2011000 {
>> +compatible = "syscon";
>> +reg = <0x02011000 0x1000>;
>> +};
>> +
>> +rng@1a50 {
>> +compatible = "qcom,prng";
>> +reg = <0x1a50 0x200>;
>> +clocks = <&gcc PRNG_CLK>;
>> +clock-names = "core";
>> +assigned-clocks = <&gcc PRNG_CLK>;
>> +assigned-clock-rates = <3200>;
>> +};
>> +
>> +vsdcc_fixed: vsdcc-regulator {
>> +compatible = "regulator-fixed";
>> +regulator-name = "SDCC Power";
>> +regulator-min-microvolt = <270>;
>> +regulator-max-microvolt = <270>;
>> +regulator-always-on;
>> +};
> 
> This should go into the root under a "regulators" node.

Done.
> 
>> +
>> +gsbi2: gsbi@1610 {
>> +compatible = "qcom,gsbi-v1.0.0";
>> +cell-index = <2>;
>> +reg = <0x1610 0x100>;
>> +clocks = <&gcc GSBI2_H_CLK>;
>> +clock-names = "iface";
>> +status = "disabled";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> + 

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Mikko Rapeli]

Cc'ing lkml.

On Fri, Aug 19, 2016 at 09:18:24PM -0500, Ken Phillis Jr wrote:
> On Fri, Aug 19, 2016 at 8:46 PM, Rob Clark  wrote:
> 
> > perhaps, but if the target audience for driver specific APIs is
> > libdrm/mesa, which already uses stdint types, then I fail to see the
> > point..
> >
> > It is a bit difference scenario for some of the core kms ioctls which
> > are not driver specific..  but most of the driver specific gpu related
> > ioctls tend to be rather complex and not intended for use by something
> > other than libdrm/mesa.
> >
> > BR,
> > -R
> >
> 
> I personally do not see the reason to break user space API in the first
> place.
> I know for a fact that the include file ( linux/types.h ) mentioned by the
> patch
> supports C99 integer data types since Linux Kernel Version 2.2.0. This makes
> the patch that got reverted completely meaningless since the only reason to
> make this change in the first place would be if the developer intends on
> backporting the driver to kernels older than version 2.2.0.

In userspace linux/types.h does not provide these integer data types to avoid
conflict with libc ones.

Thus several uapi headers fail to compile in userspace. Fix is to either
include libc side stdint.h in userspace but that was rejected by kernel
developers including Linus who are in favor of kernel specific double
underscore types.

-Mikko

[GIT PULL] parisc architecture fixes for 4.8-rc3

[Helge Deller]

Hi Linus,

Please pull two fixes for the parisc architecture for kernel 4.8-rc3 from 
  git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
parisc-4.8-2

The first patch ensures that the high-res cr16 clocksource (which was added in
kernel 4.7) gets choosen as default clocksource for parisc.

The second patch moves the #define of EREFUSED down inside errno.h and thus
unbreaks building the gccgo compiler.

Thanks,
Helge


Helge Deller (2):
  parisc: Fix automatic selection of cr16 clocksource
  parisc: Fix order of EREFUSED define in errno.h

 arch/parisc/include/uapi/asm/errno.h |  4 ++--
 arch/parisc/kernel/processor.c   |  8 
 arch/parisc/kernel/time.c| 12 
 3 files changed, 2 insertions(+), 22 deletions(-)

Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Mikko Rapeli]

Cc'ing lkml too.

On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
> Story time:
> I was dreaming of a day were we can stop installing these headers,
> thus making deprecation a bit easier process.
> Yet after failing to convince Dave and Daniel on a number of occasions
> I've accepted that those headers _are_ here to stay. And yes they
> _are_ the UAPI, even though no applications are meant to use them but
> the libdrm 'version'.
> Thus any changes to the libdrm ones should be a mirror of the ones
> here and libdrm should _not_ differ.

Another day dream:

Wouldn't it be nice if the uapi headers from Linux kernel would pass
a simple quality check of compiling in userspace where they are meant to be
used? Stand alone. Without magic tricks and additional libraries and their
headers. Without glibc or any other libc implementation specific additions.
The uapi headers define many parts of the Linux kernel API and ABI, and thus
compiling them also without the 'official' GNU/Linux userspace libraries
like glibc or libdrm does have some uses. For example API and ABI
compatibility checks and API/ABI/system call fuzzers.

Many headers required stdint.h types but Linux kernel headers do not
define them in userspace, and then Linus has said that uapi headers
should use the linux/types.h with double underscores. Thus my patches
for fixing trivial compile errors turned into changing several stdint.h
definitions to linux/types.h.

Yes, there have been some regressions in this work but to err is human.
What is the actual problem and how can we (yes, including me) try to
solve it?

-Mikko

Re: runaway latency detection

[Nikolay Borisov]

On 20.08.2016 20:03, T. Smith wrote:
> The goal is to isolate causes of indeterminism when using the PREEMPT_RT 
> kernel configuration with full preemption and to characterize latency and 
> jitter using ftrace, any recommendations?

What hardware is it ? If it's x86 it's entirely possible you are seeing
SMI. Perhaps you should look into disabling those if you are on x86?

[PATCH] s390/tape: Use memdup_user() rather than duplicating its implementation

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 19:25:34 +0200

Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/s390/char/tape_3590.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/s390/char/tape_3590.c b/drivers/s390/char/tape_3590.c
index d3d1936..e352047 100644
--- a/drivers/s390/char/tape_3590.c
+++ b/drivers/s390/char/tape_3590.c
@@ -312,15 +312,10 @@ static int tape_3592_ioctl_kekl_set(struct tape_device 
*device,
return -ENOSYS;
if (!crypt_enabled(device))
return -EUNATCH;
-   ext_kekls = kmalloc(sizeof(*ext_kekls), GFP_KERNEL);
-   if (!ext_kekls)
-   return -ENOMEM;
-   if (copy_from_user(ext_kekls, (char __user *)arg, sizeof(*ext_kekls))) {
-   rc = -EFAULT;
-   goto out;
-   }
+   ext_kekls = memdup_user((char __user *)arg, sizeof(*ext_kekls));
+   if (IS_ERR(ext_kekls))
+   return PTR_ERR(ext_kekls);
rc = tape_3592_kekl_set(device, ext_kekls);
-out:
kfree(ext_kekls);
return rc;
 }
-- 
2.9.3

Moving GPIO interrupts and IPIs to a core other than 0

[T. Smith]

On the 4.1.8-rt8+gdb51baf SMP PREMPT RT kernel, GPIO interrupts are assigned to 
core 0 as are the following IPI interrupts:

Arch_timer
Rescheduling Interrupt
Function call interrupt

Trying to assign GPIO interrupts to core 2 for example, or trying to reassign 
or move IPI interrupts running on core 0 to some other core does not seem 
possible since attempting to move these was unsuccessful. Successfully moved 
other ISRs and tasks to other cores with no problem.

1.  How does one control GPIO ISR affinity when GPIOs interrupts always appear 
to run on Core 0? How do we assign GPIO interrupts to any core other than 
Core#0. 

2.  It looks like the existing GPIO driver does not support assigning 
interrupts to any other core than CPU0, is this correct?

3.  If so, why are GPIO interrupts assigned only to Core#0?

4.  There are virtual GPIO interrupts and GPIO hardware interrupts, can either 
or both interrupts be assigned to a specific core other than Core#0?

5.  Is it possible to isolate a given CPU core from the following IPI 
interrupts, and if so, how do we isolate CPU0 from the following IPI 
interrupts.  If not, why are these always serviced on boot core 0? Arch_timer, 
Rescheduling Interrupt, Function call interrupt

Creating the GPIO interrupt:

root:~# echo 498 > /sys/class/gpio/export
root:~# echo falling > /sys/class/gpio/gpio498/edge
root:~# cat /proc/interrupts

   CPU0 CPU1   CPU2   CPU3
[] 
66:00  0  0 GIC 106
Level174.jr
67:00  0  0 mpc8xxx-gpio   18
Edge gpiolib
IPI0:  3226 4833   4237  4170   Recheduling interrupts
IPI1:17   21 1923   Function call interrupts

Setting GPIO affinity doesn’t work:

root:~# echo 1 > /proc/irq/67/smp_affinity_list-sh: echo: write error: 
Input/output error

Setting eMMC interrupt affinity works just fine:

root:~# echo 1 > /proc/irq/12/smp_affinity_list
root:~# cat /proc/interrupts

CPU0 CPU1   CPU2   CPU3
[] 
1:00  0  0 GIC 29
Edgearch_timer
2:   35475  3933628975   38803 GIC 30
Edgearch_timer
11 9   0  0   0GIC 75 Levelfsl-ifc
12:   3370 14 0   0GIC 94 Levelmmc0
[...]

thx, Tracy

runaway latency detection

[T. Smith]

Trying to isolate PREEMPT_RT (full preemption) runaway latency conditions seen 
when using the cyclictest on the 4.1.8 SMP PREEMPT_RT kernel.  Seen average 
latency of 3uS, but runaway or outlier max latency seems indeterminate.  Noted 
72uS with one run of the cyclictest for example. Is this a known issue, the 
cause understood, and is there a patch for this?  

The goal is to isolate causes of indeterminism when using the PREEMPT_RT kernel 
configuration with full preemption and to characterize latency and jitter using 
ftrace, any recommendations?

[PATCH 3/3] hostap: Delete unnecessary initialisations for the variable "ret"

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 18:23:14 +0200

The local variable "ret" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning of four functions.

Signed-off-by: Markus Elfring 
---
 drivers/net/wireless/intersil/hostap/hostap_ioctl.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c 
b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
index 5942917..c37b0bb 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
@@ -2895,7 +2895,7 @@ static int prism2_ioctl_priv_monitor(struct net_device 
*dev, int *i)
 {
struct hostap_interface *iface;
local_info_t *local;
-   int ret = 0;
+   int ret;
u32 mode;
 
iface = netdev_priv(dev);
@@ -3035,7 +3035,7 @@ static int ap_mac_cmd_ioctl(local_info_t *local, int *cmd)
 static int prism2_ioctl_priv_download(local_info_t *local, struct iw_point *p)
 {
struct prism2_download_param *param;
-   int ret = 0;
+   int ret;
 
if (p->length < sizeof(struct prism2_download_param) ||
p->length > 1024 || !p->pointer)
@@ -3791,7 +3791,7 @@ static int prism2_ioctl_scan_req(local_info_t *local,
 static int prism2_ioctl_priv_hostapd(local_info_t *local, struct iw_point *p)
 {
struct prism2_hostapd_param *param;
-   int ret = 0;
+   int ret;
int ap_ioctl = 0;
 
if (p->length < sizeof(struct prism2_hostapd_param) ||
@@ -3954,7 +3954,7 @@ int hostap_ioctl(struct net_device *dev, struct ifreq 
*ifr, int cmd)
struct iwreq *wrq = (struct iwreq *) ifr;
struct hostap_interface *iface;
local_info_t *local;
-   int ret = 0;
+   int ret;
 
iface = netdev_priv(dev);
local = iface->local;
-- 
2.9.3

[PATCH 2/3] hostap: Delete an unnecessary jump label in prism2_ioctl_priv_hostapd()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 18:21:29 +0200

Remove a jump label which is unneeded in this function at the end.

Signed-off-by: Markus Elfring 
---
 drivers/net/wireless/intersil/hostap/hostap_ioctl.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c 
b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
index 4e271f9..5942917 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
@@ -3835,14 +3835,12 @@ static int prism2_ioctl_priv_hostapd(local_info_t 
*local, struct iw_point *p)
}
 
if (ret == 1 || !ap_ioctl) {
-   if (copy_to_user(p->pointer, param, p->length)) {
+   if (copy_to_user(p->pointer, param, p->length))
ret = -EFAULT;
-   goto out;
-   } else if (ap_ioctl)
+   else if (ap_ioctl)
ret = 0;
}
 
- out:
kfree(param);
return ret;
 }
-- 
2.9.3

[PATCH 1/3] hostap: Use memdup_user() rather than duplicating its implementation

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 18:19:43 +0200

Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 .../net/wireless/intersil/hostap/hostap_ioctl.c| 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c 
b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
index 3e5fa78..4e271f9 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
@@ -3041,14 +3041,9 @@ static int prism2_ioctl_priv_download(local_info_t 
*local, struct iw_point *p)
p->length > 1024 || !p->pointer)
return -EINVAL;
 
-   param = kmalloc(p->length, GFP_KERNEL);
-   if (param == NULL)
-   return -ENOMEM;
-
-   if (copy_from_user(param, p->pointer, p->length)) {
-   ret = -EFAULT;
-   goto out;
-   }
+   param = memdup_user(p->pointer, p->length);
+   if (IS_ERR(param))
+   return PTR_ERR(param);
 
if (p->length < sizeof(struct prism2_download_param) +
param->num_areas * sizeof(struct prism2_download_area)) {
@@ -3803,14 +3798,9 @@ static int prism2_ioctl_priv_hostapd(local_info_t 
*local, struct iw_point *p)
p->length > PRISM2_HOSTAPD_MAX_BUF_SIZE || !p->pointer)
return -EINVAL;
 
-   param = kmalloc(p->length, GFP_KERNEL);
-   if (param == NULL)
-   return -ENOMEM;
-
-   if (copy_from_user(param, p->pointer, p->length)) {
-   ret = -EFAULT;
-   goto out;
-   }
+   param = memdup_user(p->pointer, p->length);
+   if (IS_ERR(param))
+   return PTR_ERR(param);
 
switch (param->cmd) {
case PRISM2_SET_ENCRYPTION:
-- 
2.9.3

[PATCH 0/3] hostap: Fine-tuning for a few functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 20 Aug 2016 18:35:43 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Use memdup_user()
  Delete an unnecessary jump label
  Delete unnecessary variable initialisations

 .../net/wireless/intersil/hostap/hostap_ioctl.c| 36 --
 1 file changed, 12 insertions(+), 24 deletions(-)

-- 
2.9.3

Re: Memory (skb) leak in kernel 4.8-rc2

[Larry Finger]

On 08/20/2016 01:01 AM, Marcel Holtmann wrote:

Hi Larry,

I can not see a leak. Maybe Johan has an idea.


Marcel and Johan,

The hardware in question is an Intel device with USB ID 8087:07dc, which is part 
of an Intel Wireless 7260.


The kmemleak backtraces for the two kinds of leaks are:

unreferenced object 0x8801e182e000 (size 1024):
  comm "hardirq", pid 0, jiffies 4312467853 (age 61.716s)
  hex dump (first 32 bytes):
00 84 82 e1 01 88 ff ff 0e 04 01 10 20 00 20 00   . .
05 06 02 00 00 05 00 00 40 00 40 00 00 00 00 00  @.@.
  backtrace:
[] kmemleak_alloc+0x4a/0xa0
[] __kmalloc_node_track_caller+0x178/0x270
[] __kmalloc_reserve.isra.35+0x31/0x90
[] __alloc_skb+0x7e/0x280
[] btusb_recv_intr+0x12b/0x170 [btusb]
[] btusb_intr_complete+0xc5/0x130 [btusb]
[] __usb_hcd_giveback_urb+0x85/0x110 [usbcore]
[] usb_hcd_giveback_urb+0x3f/0x130 [usbcore]
[] handle_tx_event+0x4ca/0x13c0 [xhci_hcd]
[] xhci_irq+0x272/0xa30 [xhci_hcd]
[] xhci_msi_irq+0x11/0x20 [xhci_hcd]
[] __handle_irq_event_percpu+0x3f/0x1d0
[] handle_irq_event_percpu+0x23/0x60
[] handle_irq_event+0x3c/0x60
[] handle_edge_irq+0x9b/0x160
[] handle_irq+0x20/0x30

unreferenced object 0x88010ccbd200 (size 256):
  comm "kworker/u17:2", pid 684, jiffies 4312467853 (age 61.716s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
1e c6 5f 75 10 90 6c 14 00 00 00 00 00 00 00 00  .._u..l.
  backtrace:
[] kmemleak_alloc+0x4a/0xa0
[] kmem_cache_alloc+0xc4/0x1f0
[] skb_clone+0x4c/0xa0
[] hci_event_packet+0xb8/0x30b0 [bluetooth]
[] hci_rx_work+0x18d/0x380 [bluetooth]
[] process_one_work+0x14b/0x430
[] worker_thread+0x12b/0x490
[] kthread+0xc9/0xe0
[] ret_from_fork+0x1f/0x40
[] 0x

I will attempt a bisection.

Larry

Linux 4.7.2

[Greg KH]

I'm announcing the release of the 4.7.2 kernel.

All users of the 4.7 kernel series must upgrade.

The updated 4.7.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.7.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/module-signing.txt|6 
 Makefile|2 
 arch/arc/include/asm/pgtable.h  |2 
 arch/arc/mm/dma.c   |3 
 arch/arm/boot/dts/arm-realview-pbx-a9.dts   |9 
 arch/arm/boot/dts/sun4i-a10-a1000.dts   |1 
 arch/arm/boot/dts/sun4i-a10-hackberry.dts   |1 
 arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts  |1 
 arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts|1 
 arch/arm/boot/dts/tegra124-jetson-tk1.dts   |4 
 arch/arm/configs/aspeed_g4_defconfig|2 
 arch/arm/configs/aspeed_g5_defconfig|2 
 arch/arm/mm/dma-mapping.c   |   62 +
 arch/arm64/Kconfig  |2 
 arch/arm64/boot/dts/rockchip/rk3368.dtsi|2 
 arch/arm64/kernel/debug-monitors.c  |1 
 arch/arm64/kernel/hibernate.c   |   82 +-
 arch/arm64/kernel/smp.c |   10 
 arch/arm64/kernel/vmlinux.lds.S |4 
 arch/arm64/kvm/hyp/sysreg-sr.c  |8 
 arch/arm64/kvm/inject_fault.c   |   12 
 arch/arm64/mm/mmu.c |8 
 arch/arm64/mm/proc.S|2 
 arch/metag/include/asm/cmpxchg_lnkget.h |2 
 arch/mips/kernel/cevt-r4k.c |7 
 arch/mips/kernel/csrc-r4k.c |4 
 arch/mips/kvm/emulate.c |   40 -
 arch/mips/kvm/tlb.c |   66 +
 arch/mips/loongson64/loongson-3/hpet.c  |   14 
 arch/mips/mm/uasm-mips.c|2 
 arch/powerpc/kernel/tm.S|3 
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |  462 ++--
 arch/s390/include/asm/pgtable.h |2 
 arch/s390/include/asm/tlbflush.h|3 
 arch/s390/mm/gmap.c |4 
 arch/s390/mm/pgtable.c  |2 
 arch/um/os-Linux/signal.c   |5 
 arch/unicore32/include/asm/mmu_context.h|2 
 arch/x86/events/intel/uncore_snbep.c|   10 
 arch/x86/kvm/mtrr.c |1 
 arch/x86/kvm/vmx.c  |   20 
 arch/x86/kvm/x86.c  |   45 -
 arch/x86/pci/intel_mid_pci.c|   12 
 block/bio.c |   15 
 block/genhd.c   |2 
 drivers/acpi/ec.c   |   41 -
 drivers/bcma/host_pci.c |1 
 drivers/block/floppy.c  |   21 
 drivers/bluetooth/ath3k.c   |2 
 drivers/bluetooth/btusb.c   |1 
 drivers/char/random.c   |   33 
 drivers/char/tpm/tpm_crb.c  |2 
 drivers/clk/rockchip/clk-rk3399.c   |2 
 drivers/cpufreq/intel_pstate.c  |2 
 drivers/edac/edac_mc_sysfs.c|   20 
 drivers/gpio/gpio-intel-mid.c   |   21 
 drivers/gpio/gpio-pca953x.c |2 
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c|   25 
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c|5 
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c  |7 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   16 
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c  |1 
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   |1 
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c|4 
 drivers/gpu/drm/drm_cache.c |1 
 drivers/gpu/drm/drm_dp_helper.c |2 
 drivers/gpu

Linux 4.4.19

[Greg KH]

I'm announcing the release of the 4.4.19 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/module-signing.txt |6 
 Makefile |2 
 arch/arc/include/asm/pgtable.h   |2 
 arch/arm/boot/dts/sun4i-a10-a1000.dts|1 
 arch/arm/boot/dts/sun4i-a10-hackberry.dts|1 
 arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts   |1 
 arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts |1 
 arch/arm64/boot/dts/rockchip/rk3368.dtsi |2 
 arch/arm64/include/asm/ptrace.h  |2 
 arch/arm64/kernel/asm-offsets.c  |1 
 arch/arm64/kernel/debug-monitors.c   |1 
 arch/arm64/kernel/entry.S|   15 
 arch/arm64/kernel/smp.c  |3 
 arch/arm64/mm/mmu.c  |8 
 arch/arm64/mm/proc.S |2 
 arch/metag/include/asm/cmpxchg_lnkget.h  |2 
 arch/mips/kernel/csrc-r4k.c  |4 
 arch/mips/kvm/emulate.c  |   40 +
 arch/mips/kvm/tlb.c  |   68 ++-
 arch/mips/loongson64/loongson-3/hpet.c   |   14 
 arch/mips/mm/uasm-mips.c |2 
 arch/powerpc/kvm/book3s_hv_rmhandlers.S  |  462 ---
 arch/x86/kvm/mtrr.c  |1 
 arch/x86/kvm/vmx.c   |   20 
 arch/x86/pci/intel_mid_pci.c |   12 
 block/bio.c  |   15 
 block/genhd.c|2 
 drivers/acpi/ec.c|   41 +-
 drivers/bluetooth/hci_intel.c|6 
 drivers/char/random.c|   29 -
 drivers/cpufreq/intel_pstate.c   |2 
 drivers/edac/edac_mc_sysfs.c |   20 
 drivers/gpio/gpio-intel-mid.c|   19 
 drivers/gpio/gpio-pca953x.c  |2 
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |   25 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c |5 
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c   |7 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   |   16 
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c   |1 
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c|1 
 drivers/gpu/drm/drm_cache.c  |1 
 drivers/gpu/drm/drm_edid.c   |8 
 drivers/gpu/drm/i915/intel_display.c |   20 
 drivers/gpu/drm/i915/intel_opregion.c|2 
 drivers/gpu/drm/i915/intel_pm.c  |3 
 drivers/gpu/drm/nouveau/nouveau_drm.c|   11 
 drivers/gpu/drm/nouveau/nv04_fbcon.c |4 
 drivers/gpu/drm/nouveau/nv50_fbcon.c |2 
 drivers/gpu/drm/nouveau/nvc0_fbcon.c |2 
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv30.c|4 
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv34.c|4 
 drivers/gpu/drm/radeon/atombios_encoders.c   |1 
 drivers/gpu/drm/radeon/radeon_atombios.c |4 
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |5 
 drivers/gpu/drm/radeon/radeon_connectors.c   |   15 
 drivers/hid/uhid.c   |   33 +
 drivers/hv/vmbus_drv.c   |3 
 drivers/i2c/busses/i2c-efm32.c   |2 
 drivers/infiniband/core/iwpm_util.c  |1 
 drivers/infiniband/core/sa_query.c   |2 
 drivers/infiniband/hw/mlx4/mad.c |   24 -
 drivers/infiniband/hw/mlx4/qp.c  |6 
 drivers/infiniband/hw/mlx5/cq.c  |   12 
 drivers/infiniband/hw/mlx5/main.c|5 
 drivers/infiniband/hw/mlx5/qp.c  |   21 -
 drivers/infiniband/ulp/ipoib/ipoib_main.c|4 
 drivers/input/mouse/elan_i2c_core.c  |   79 +++
 drivers/input/touchscreen/sur40.c|5 
 drivers/iommu/amd_iommu.c|   40 +
 drivers/iommu/exynos-iommu.c |1 
 drivers/iommu/intel-iommu.c  |2 
 drivers/md/dm-flakey.c   |   23 -
 drivers/md/dm.c  |   14 
 drivers/media/dvb-core/dvb_ringbuffer.c  |   74 +++
 drivers/media/platform/s5p-mfc/s5p_mfc.c |   11 
 drivers/media/rc/ir-rc5-decoder.c|2 
 drivers/media/usb/usbtv/usbtv-audio.c|5 
 drivers/media/v4l2-core/videobuf2-core.c |   10 
 drivers/media/v4l

Re: Linux 3.14.77

[Greg KH]

diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt
index 2b40e04d3c49..f18b6ef7f805 100644
--- a/Documentation/module-signing.txt
+++ b/Documentation/module-signing.txt
@@ -238,3 +238,9 @@ Since the private key is used to sign modules, viruses and 
malware could use
 the private key to sign modules and compromise the operating system.  The
 private key must be either destroyed or moved to a secure location and not kept
 in the root node of the kernel source tree.
+
+If you use the same private key to sign modules for multiple kernel
+configurations, you must ensure that the module version information is
+sufficient to prevent loading a module into a different kernel.  Either
+set CONFIG_MODVERSIONS=y or ensure that each configuration has a different
+kernel release string by changing EXTRAVERSION or CONFIG_LOCALVERSION.
diff --git a/Makefile b/Makefile
index 306fd306906b..fc4df99727c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 14
-SUBLEVEL = 76
+SUBLEVEL = 77
 EXTRAVERSION =
 NAME = Remembering Coco
 
diff --git a/arch/arm/include/asm/pgtable-3level.h 
b/arch/arm/include/asm/pgtable-3level.h
index ab7ee9205ca4..40d60a679fc8 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -243,8 +243,11 @@ PMD_BIT_FUNC(mkyoung,   |= PMD_SECT_AF);
 #define pfn_pmd(pfn,prot)  (__pmd(((phys_addr_t)(pfn) << PAGE_SHIFT) | 
pgprot_val(prot)))
 #define mk_pmd(page,prot)  pfn_pmd(page_to_pfn(page),prot)
 
-/* represent a notpresent pmd by zero, this is used by pmdp_invalidate */
-#define pmd_mknotpresent(pmd)  (__pmd(0))
+/* represent a notpresent pmd by faulting entry, this is used by 
pmdp_invalidate */
+static inline pmd_t pmd_mknotpresent(pmd_t pmd)
+{
+   return __pmd(pmd_val(pmd) & ~L_PMD_SECT_VALID);
+}
 
 static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
 {
diff --git a/arch/metag/include/asm/cmpxchg_lnkget.h 
b/arch/metag/include/asm/cmpxchg_lnkget.h
index 0154e2807ebb..2369ad394876 100644
--- a/arch/metag/include/asm/cmpxchg_lnkget.h
+++ b/arch/metag/include/asm/cmpxchg_lnkget.h
@@ -73,7 +73,7 @@ static inline unsigned long __cmpxchg_u32(volatile int *m, 
unsigned long old,
  " DCACHE  [%2], %0\n"
 #endif
  "2:\n"
- : "=&d" (temp), "=&da" (retval)
+ : "=&d" (temp), "=&d" (retval)
  : "da" (m), "bd" (old), "da" (new)
  : "cc"
  );
diff --git a/arch/mips/kvm/kvm_mips_emul.c b/arch/mips/kvm/kvm_mips_emul.c
index 33085819cd89..9f7643874fba 100644
--- a/arch/mips/kvm/kvm_mips_emul.c
+++ b/arch/mips/kvm/kvm_mips_emul.c
@@ -972,8 +972,13 @@ kvm_mips_emulate_cache(uint32_t inst, uint32_t *opc, 
uint32_t cause,
preempt_disable();
if (KVM_GUEST_KSEGX(va) == KVM_GUEST_KSEG0) {
 
-   if (kvm_mips_host_tlb_lookup(vcpu, va) < 0) {
-   kvm_mips_handle_kseg0_tlb_fault(va, vcpu);
+   if (kvm_mips_host_tlb_lookup(vcpu, va) < 0 &&
+   kvm_mips_handle_kseg0_tlb_fault(va, vcpu)) {
+   kvm_err("%s: handling mapped kseg0 tlb fault for %lx, 
vcpu: %p, ASID: %#lx\n",
+   __func__, va, vcpu, read_c0_entryhi());
+   er = EMULATE_FAIL;
+   preempt_enable();
+   goto done;
}
} else if ((KVM_GUEST_KSEGX(va) < KVM_GUEST_KSEG0) ||
   KVM_GUEST_KSEGX(va) == KVM_GUEST_KSEG23) {
@@ -1006,11 +1011,16 @@ kvm_mips_emulate_cache(uint32_t inst, uint32_t *opc, 
uint32_t cause,
run, vcpu);
preempt_enable();
goto dont_update_pc;
-   } else {
-   /* We fault an entry from the guest tlb to the 
shadow host TLB */
-   kvm_mips_handle_mapped_seg_tlb_fault(vcpu, tlb,
-NULL,
-NULL);
+   }
+   /* We fault an entry from the guest tlb to the shadow 
host TLB */
+   if (kvm_mips_handle_mapped_seg_tlb_fault(vcpu, tlb,
+NULL, NULL)) {
+   kvm_err("%s: handling mapped seg tlb fault for 
%lx, index: %u, vcpu: %p, ASID: %#lx\n",
+   __func__, va, index, vcpu,
+   read_c0_entryhi());
+   er = EMULATE_FAIL;
+   preempt_enable();
+   goto done;
}
}
} else {
@@ -1821,8 +1831,13 @@ kvm_mips_handle_tlbmiss(un

Linux 3.14.77

[Greg KH]

I'm announcing the release of the 3.14.77 kernel.

All users of the 3.14 kernel series must upgrade.

The updated 3.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/module-signing.txt |6 ++
 Makefile |2 
 arch/arm/include/asm/pgtable-3level.h|7 ++-
 arch/metag/include/asm/cmpxchg_lnkget.h  |2 
 arch/mips/kvm/kvm_mips_emul.c|   33 ++
 arch/mips/kvm/kvm_tlb.c  |   61 ++-
 drivers/char/random.c|   12 +++--
 drivers/gpio/gpio-intel-mid.c|   19 
 drivers/gpio/gpio-pca953x.c  |2 
 drivers/gpu/drm/i915/intel_display.c |   20 ++--
 drivers/gpu/drm/radeon/atombios_encoders.c   |1 
 drivers/gpu/drm/radeon/radeon_atombios.c |4 -
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |5 ++
 drivers/gpu/drm/radeon/radeon_connectors.c   |   15 +++---
 drivers/infiniband/hw/mlx4/qp.c  |2 
 drivers/infiniband/hw/mlx5/qp.c  |   21 +
 drivers/infiniband/ulp/ipoib/ipoib_main.c|4 +
 drivers/md/dm-flakey.c   |   23 ++
 drivers/media/platform/s5p-mfc/s5p_mfc.c |   11 
 drivers/mtd/ubi/build.c  |5 +-
 drivers/mtd/ubi/vmt.c|   25 +++
 drivers/pci/quirks.c |   10 ++--
 drivers/platform/x86/hp-wmi.c|7 ++-
 drivers/target/iscsi/iscsi_target.c  |   22 +++--
 drivers/target/target_core_device.c  |8 ++-
 drivers/target/target_core_file.c|3 -
 drivers/target/target_core_iblock.c  |3 -
 drivers/target/target_core_transport.c   |3 -
 drivers/usb/core/devio.c |9 ++-
 drivers/usb/renesas_usbhs/mod_gadget.c   |9 +++
 drivers/usb/serial/option.c  |3 +
 drivers/virtio/virtio_balloon.c  |2 
 fs/cifs/cifsencrypt.c|   16 ---
 fs/cifs/dir.c|   24 +-
 fs/cifs/smb2ops.c|   30 -
 fs/nfs/write.c   |5 +-
 include/linux/mlx5/qp.h  |5 +-
 include/target/target_core_backend.h |2 
 kernel/module.c  |   13 +++--
 net/bluetooth/l2cap_sock.c   |2 
 net/ipv4/tcp_input.c |6 +-
 net/ipv4/udp.c   |6 +-
 net/ipv6/udp.c   |6 +-
 net/netlabel/netlabel_kapi.c |   12 -
 scripts/recordmcount.c   |9 +++
 45 files changed, 337 insertions(+), 158 deletions(-)

Alex Deucher (3):
  drm/radeon: add a delay after ATPX dGPU power off
  drm/radeon: fix firmware info version checks
  drm/radeon: support backlight control for UNIPHY3

Alex Hung (1):
  hp-wmi: Fix wifi cannot be hard-unblocked

Amadeusz Sławiński (1):
  Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU

Andy Shevchenko (1):
  gpio: intel-mid: Remove potentially harmful code

Artemy Kovalyov (1):
  IB/mlx5: Fix MODIFY_QP command input structure

Ben Hutchings (2):
  module: Invalidate signatures on force-loaded modules
  Documentation/module-signing.txt: Note need for version info if reusing a 
key

Benjamin Coddington (1):
  nfs: don't create zero-length requests

Chris Blake (1):
  PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset

Daniele Palmas (1):
  USB: serial: option: add support for Telit LE910 PID 0x1206

Eli Cohen (1):
  IB/mlx5: Fix post send fence logic

Erez Shitrit (1):
  IB/IPoIB: Don't update neigh validity for unresolved entries

Eric Dumazet (1):
  udp: properly support MSG_PEEK with truncated buffers

Greg Kroah-Hartman (2):
  tcp: make challenge acks faster
  Linux 3.14.77

Iosif Harutyunov (1):
  ubi: Fix race condition between ubi device creation and udev

James Hogan (5):
  MIPS: KVM: Fix mapped fault broken commpage handling
  MIPS: KVM: Add missing gfn range check
  MIPS: KVM: Fix gfn range check in kseg0 tlb faults
  MIPS: KVM: Propagate kseg0/mapped tlb fault errors
  metag: Fix __cmpxchg_u32 asm constraint for CMP

Javier Martinez Canillas (2):
  s5p-mfc: Set device name for reserved memory region devs
  s5p-mfc: Add release callback for memory region devs

Kangjie Lu (1):
  USB: usbfs: fix potential infoleak in devio

Konstantin Neumoin (1):
  balloon: check the number of available pages in leak balloon

Laura Ab