Re: [PATCHv4 0/3] Salted build ids via linker sections

[Michael Ellerman]

Laura Abbott  writes:
> Hi,
>
> This is v4 of the series to allow unique build ids in the kernel. As a
> reminder of the context:
>
> ""
> In Fedora, the debug information is packaged separately (foo-debuginfo) and
> can be installed separately. There's been a long standing issue where only one
> version of a debuginfo info package can be installed at a time. Mark Wielaard
> made an effort for Fedora 27 to allow parallel installation of debuginfo (see
> https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo for
> more details)
>
> Part of the requirement to allow this to work is that build ids are
> unique between builds. The existing upstream rpm implementation ensures
> this by re-calculating the build-id using the version and release as a
> seed. This doesn't work 100% for the kernel because of the vDSO which is
> its own binary and doesn't get updated. After poking holes in a few of my
> ideas, there was a discussion with some people from the binutils team about
> adding --build-id-salt to let ld do the calculation debugedit is doing. There
> was a counter proposal made to add in the salt while building. The
> easiest proposal was to add an item in the linker script vs. linking in
> an object since we need the salt to go in every module as well as the
> kernel and vmlinux.
> ""
>
> v4 takes Linus' suggestion of using linker fill to insert the build id.
> This removes the need to use a generated header which makes things much
> easier. One change is that because this section isn't .comment it won't
> get stripped automatically. This is pretty small but I also know people
> can be picky so I'm open to opinions or suggestions here.
>
> Laura Abbott (3):
>   scripts: Preprocess module-common.lds
>   kbuild: Introduce build-salt linker section and config option
>   x86: Add build salt to the vDSO and kernel linker scripts

Hi Laura,

Here's a patch to get it working on powerpc. Seems to work as expected.

cheers


>From fc5e22e4873956f9328e401ee5dd2835f4884db9 Mon Sep 17 00:00:00 2001
From: Michael Ellerman 
Date: Tue, 12 Jun 2018 14:52:34 +1000
Subject: [PATCH] powerpc: Add support for BUILD_SALT in kernel, modules & VDSO

This patch adds support for BUILD_SALT in the kernel, modules and
VDSO. See the commit that adds BUILD_SALT for more info.

Kernel:
  0:mon> d c1340840
  c1340840 0055aaff12345678 1234567812345678  |.U...4Vx.4Vx.4Vx|
  c1340850 1234567812345678 1234567812345678  |.4Vx.4Vx.4Vx.4Vx|

Module:

  $ cat/sys/module/kvm/sections/.salt
  0xd64385e8
  ...
  0:mon> d d64385e8
  d64385e8 0055aaff12345678 1234567812345678  |.U...4Vx.4Vx.4Vx|
  d64385f8 1234567812345678 1234567812345678  |.4Vx.4Vx.4Vx.4Vx|

vdso:
  (gdb) x/4xw (0x77f8 + 0x4a0)
  0x77f804a0:   0xffaa5500  0x78563412  0x78563412  
0x78563412

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/vdso32/vdso32.lds.S | 2 ++
 arch/powerpc/kernel/vdso64/vdso64.lds.S | 2 ++
 arch/powerpc/kernel/vmlinux.lds.S   | 1 +
 3 files changed, 5 insertions(+)

diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S 
b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index 099a6db14e67..c06a1260 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -4,6 +4,7 @@
  * library
  */
 #include 
+#include 
 
 #ifdef __LITTLE_ENDIAN__
 OUTPUT_FORMAT("elf32-powerpcle", "elf32-powerpcle", "elf32-powerpcle")
@@ -25,6 +26,7 @@ SECTIONS
.gnu.version_d  : { *(.gnu.version_d) }
.gnu.version_r  : { *(.gnu.version_r) }
 
+   BUILD_SALT
.note   : { *(.note.*) }:text   :note
 
. = ALIGN(16);
diff --git a/arch/powerpc/kernel/vdso64/vdso64.lds.S 
b/arch/powerpc/kernel/vdso64/vdso64.lds.S
index 256fb9720298..ace69258446a 100644
--- a/arch/powerpc/kernel/vdso64/vdso64.lds.S
+++ b/arch/powerpc/kernel/vdso64/vdso64.lds.S
@@ -4,6 +4,7 @@
  * library
  */
 #include 
+#include 
 
 #ifdef __LITTLE_ENDIAN__
 OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
@@ -25,6 +26,7 @@ SECTIONS
.gnu.version_d  : { *(.gnu.version_d) }
.gnu.version_r  : { *(.gnu.version_r) }
 
+   BUILD_SALT
.note   : { *(.note.*) }:text   :note
 
. = ALIGN(16);
diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
index 5baac79df97e..59635369ceea 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -348,6 +348,7 @@ SECTIONS
}
 
BUG_TABLE
+   BUILD_SALT
 
. = ALIGN(PAGE_SIZE);
_edata  =  .;
-- 
2.14.1

Re: [PATCH v13 0/3] Fix issues with huge mapping in ioremap for ARM64

[Chintan Pandya]

Hi Andrew,

On 6/6/2018 9:15 PM, Will Deacon wrote:

[...]


On Wed, Jun 06, 2018 at 12:31:18PM +0530, Chintan Pandya wrote:

This series of patches re-bring huge vmap back for arm64.

Patch 1/3 has been taken by Toshi in his series of patches
by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86"
to avoid merge conflict with this series.



[...]




  arch/arm64/include/asm/tlbflush.h |  7 ++
  arch/arm64/mm/mmu.c   | 48 +++
  arch/x86/mm/pgtable.c |  8 ---
  include/asm-generic/pgtable.h |  8 +++
  lib/ioremap.c |  4 ++--


If you get an ack from the x86 folks, then I could take all of this via
arm64. Alternatively, now that I've reviewed the series this could happily
go via another tree (e.g. akpm).



Would you be able to take a look at this series ?
- 1/3 has been reviewed by Will and Toshi (as it touches arm64 and x86).
- 2/3 & 3/3 are arm64 specific changes.

If you think to take these patches, great ! Otherwise, I will try to
reach-out to x86 folks for their ack.


Thanks,

Will

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

Re: [PATCH v2 2/2] ALSA: hda: add dock and led support for HP ProBook 640 G4

[Takashi Iwai]

On Tue, 12 Jun 2018 07:11:11 +0200,
Dennis Wassenberg wrote:
> 
> This patch adds missing initialisation for HP 2013 UltraSlim Dock
> Line-In/Out PINs and activates keyboard mute/micmute leds
> for HP ProBook 640 G4
> 
> Signed-off-by: Dennis Wassenberg 

Applied, thanks.


Takashi

Re: [PATCH] ALSA: lx6464es: add error handling for pci_ioremap_bar

[Takashi Iwai]

On Tue, 12 Jun 2018 05:23:14 +0200,
Zhouyang Jia wrote:
> 
> When pci_ioremap_bar fails, the lack of error-handling code may
> cause unexpected results.
> 
> This patch adds error-handling code after calling pci_ioremap_bar.
> 
> Signed-off-by: Zhouyang Jia 

This patch makes no sense, sorry.  The whole lx6464es error handling
there is buggy.  We need to fix it more properly.

And, you must have noticed a bad smell in that change before
submitting this.  Basically, using the same goto label for the error
handling of the next step is already fishy.  In this case, you'd have
to unmap at the error path after this point.  If you can use the same
label, it means that the unmap is missing -- already something wrong.


thanks,

Takashi

> ---
>  sound/pci/lx6464es/lx6464es.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/sound/pci/lx6464es/lx6464es.c b/sound/pci/lx6464es/lx6464es.c
> index 9655b08..6157b6d 100644
> --- a/sound/pci/lx6464es/lx6464es.c
> +++ b/sound/pci/lx6464es/lx6464es.c
> @@ -1016,6 +1016,10 @@ static int snd_lx6464es_create(struct snd_card *card,
>  
>   /* dsp port */
>   chip->port_dsp_bar = pci_ioremap_bar(pci, 2);
> + if (!chip->port_dsp_bar) {
> + dev_err(card->dev, "cannot remap PCI memory region\n");
> + goto request_irq_failed;
> + }
>  
>   err = request_threaded_irq(pci->irq, lx_interrupt, lx_threaded_irq,
>  IRQF_SHARED, KBUILD_MODNAME, chip);
> -- 
> 2.7.4
> 
> 

Re: [PATCH v2 1/2] ALSA: hda: add dock and led support for HP EliteBook 830 G5

[Takashi Iwai]

On Tue, 12 Jun 2018 07:10:59 +0200,
Dennis Wassenberg wrote:
> 
> This patch adds missing initialisation for HP 2013 UltraSlim Dock
> Line-In/Out PINs and activates keyboard mute/micmute leds
> for HP EliteBook 830 G5
> 
> Signed-off-by: Dennis Wassenberg 

Applied, thanks.


Takashi

RE: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller

[Yogesh Narayan Gaur]

Hi Boris,

-Original Message-
From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of 
Yogesh Narayan Gaur
Sent: Monday, June 11, 2018 3:51 PM
To: Boris Brezillon 
Cc: rich...@nod.at; Prabhakar Kushwaha ; Han Xu 
; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; 
marek.va...@gmail.com; Frieder Schrempf ; 
broo...@kernel.org; linux-...@lists.infradead.org; miquel.ray...@bootlin.com; 
Fabio Estevam ; David Wolfe ; 
computersforpe...@gmail.com; dw...@infradead.org
Subject: RE: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI 
controller

Hi Boris,

-Original Message-
From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] 
Sent: Monday, June 11, 2018 3:46 PM
To: Yogesh Narayan Gaur 
Cc: marek.va...@gmail.com; Frieder Schrempf ; 
linux-...@lists.infradead.org; linux-...@vger.kernel.org; dw...@infradead.org; 
computersforpe...@gmail.com; rich...@nod.at; miquel.ray...@bootlin.com; 
broo...@kernel.org; David Wolfe ; Fabio Estevam 
; Prabhakar Kushwaha ; Han 
Xu ; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI 
controller

On Mon, 11 Jun 2018 09:38:14 +
Yogesh Narayan Gaur  wrote:

> > > Observation 3:
> > > As we can support JFFS2 filesystem on NOR flash, so we can expect JFFS2 
> > > commands should work fine on NOR flash.
> > > But with this driver change my mount command is not working.
> > > 
> > > In my target there are 2 flash slave devices connected, and I have given 
> > > argument to create MTD partition like 
> > > "mtdparts=20c.quadspi-1:5M(rcw),10M(test),46M(rootfs) " for 2nd flash.
> > > Below is output for /proc/mtd commands
> > > root@ls1012ardb:~# cat /proc/mtd
> > > dev:size   erasesize  name
> > > mtd0: 0400 0004 "20c.quadspi-0"   --> First 64MB flash
> > > mtd1: 0050 0004 "rcw"   --> 
> > > Second 64 MB flash device, 3 MTD partition are created for it.
> > > mtd2: 00a0 0004 "test"
> > > mtd3: 02e0 0004 "rootfs"

When I do mtd1 + mtd2 + mtd3, I end up with 0x3d0 instead of 0x400. Is 
that normal? Do you reserve a bit of space at the end or is it that rcw is not 
starting at 0?

I have given partition size n bootargs as 
mtdparts=20c.quadspi-1:5M(rcw),10M(test),46M(rootfs)
5 + 10 + 46 ==> 61M i.e. 0x3d0.
I have just reserve the bit at the end, we can modify these settings also.

> > > 
> > > root@ls1012ardb:~# mkdir /media/ram ; flash_eraseall /dev/mtd3
> > > flash_eraseall has been replaced by `flash_erase  0 0`; 
> > > please use it
> > > Erasing 256 Kibyte @ 0 --  0 % complete [   18.299929] random: crng 
> > > init done
> > > Erasing 256 Kibyte @ 2dc -- 100 % complete
> > > root@ls1012ardb:~# mount -t jffs2 /dev/mtdblock3 /media/ram/
> > > 
> > > This command didn't finish successfully and there are lot of messages 
> > > coming on console mentioning failure in jffs2_scan_eraseblock()
> > > [  187.118677] jffs2: jffs2_scan_eraseblock(): Magic bitmask 
> > > 0x1985 not found at 0x013c: 0x2886 instead

>> Did you try to create a smaller partition? Maybe we have a problem when 
>> accessing addresses higher than X with the new driver (X to be determined).

> Would try and update you.

I have tried JFFS2 mounting with smaller partition size but still getting 
failure.
For partition size equal or less than 1MB, getting errors as
[   25.044930] jffs2: Too few erase blocks (4)
Thus, need to have size more than 1MB.

For 2MB partition size getting error message from jffs2_scan_eraseblock().
root@ls1012ardb:~# cat /proc/mtd
dev:size   erasesize  name
mtd0: 0400 0004 "20c.quadspi-0"
mtd1: 0050 0004 "rcw"
mtd2: 00a0 0004 "test"
mtd3: 0020 0004 "rootfs"
root@ls1012ardb:~#  mkdir /media/ram ; flash_eraseall /dev/mtd3
flash_eraseall has been replaced by `flash_erase  0 0`; please use 
it
Erasing 256 Kibyte @ 1c -- 100 % complete
root@ls1012ardb:~# mount -t jffs2 /dev/mtdblock3 /media/ram/
[   26.380989] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not 
found at 0x: 0x0dd0 instead
[   26.390509] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not 
found at 0x004c: 0x7366 instead
[   26.39] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not 
found at 0x0050: 0x736c instead

--
Regards
Yogesh Gaur

> > > [  187.128159] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 
> > > not found at 0x013c0004: 0x7a3b instead
> > > [  187.137641] jffs2: jffs2_scan_eraseblock(): Magic bitmask
> > > 0x1985 not found at 0x013c0008: 0xb10f instead
> > > 



__
Linux MTD discussion mailing list
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infradead.org%2Fmailman%2Flistinfo%2Flinux-mtd%2F&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7C0b09ae5

Re: [PATCH v3 5/7] dt-bindings: power: Add qcom rpmh power domain driver bindings

[Rajendra Nayak]

On 06/12/2018 11:09 AM, Bjorn Andersson wrote:
> On Mon 11 Jun 21:40 PDT 2018, Rajendra Nayak wrote:
> 
>> Add DT bindings to describe the rpmh powerdomains found on Qualcomm
>> Technologies, Inc. SoCs. These power domains communicate a performance
>> state to RPMh, which then translates it into corresponding voltage on
>> a PMIC rail.
>>
>> Signed-off-by: Rajendra Nayak 
>> ---
>>  .../devicetree/bindings/power/qcom,rpmhpd.txt | 65 +++
>>  1 file changed, 65 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt 
>> b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>> new file mode 100644
>> index ..41ef7afa6b24
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>> @@ -0,0 +1,65 @@
>> +Qualcomm RPMh Power domains
>> +
>> +For RPMh Power domains, we communicate a performance state to RPMh
>> +which then translates it into a corresponding voltage on a rail
>> +
>> +Required Properties:
>> + - compatible: Should be one of the following
>> +* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
> 
> Afaict this binding is identical to the one introduced in patch 1, so I
> would suggest that you just add the compatible there.

Sure, makes sense. thanks.

> 
> Regards,
> Bjorn
> 
>> + - power-domain-cells: number of cells in power domain specifier
>> +must be 1
>> + - operating-points-v2: Phandle to the OPP table for the power-domain.
>> +Refer to Documentation/devicetree/bindings/power/power_domain.txt
>> +and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
>> +
>> +Example:
>> +
>> +rpmhpd: power-controller {
>> +compatible = "qcom,sdm845-rpmhpd";
>> +#power-domain-cells = <1>;
>> +operating-points-v2 = <&rpmhpd_opp_table>;
>> +};
>> +
>> +rpmhpd_opp_table: opp-table {
>> +compatible = "operating-points-v2-qcom-level";
>> +
>> +rpmhpd_opp_ret: opp1 {
>> +qcom-level = <16>;
>> +};
>> +
>> +rpmhpd_opp_min_svs: opp2 {
>> +qcom-level = <48>;
>> +};
>> +
>> +rpmhpd_opp_low_svs: opp3 {
>> +qcom-level = <64>;
>> +};
>> +
>> +rpmhpd_opp_svs: opp4 {
>> +qcom-level = <128>;
>> +};
>> +
>> +rpmhpd_opp_svs_l1: opp5 {
>> +qcom-level = <192>;
>> +};
>> +
>> +rpmhpd_opp_nom: opp6 {
>> +qcom-level = <256>;
>> +};
>> +
>> +rpmhpd_opp_nom_l1: opp7 {
>> +qcom-level = <320>;
>> +};
>> +
>> +rpmhpd_opp_nom_l2: opp8 {
>> +qcom-level = <336>;
>> +};
>> +
>> +rpmhpd_opp_turbo: opp9 {
>> +qcom-level = <384>;
>> +};
>> +
>> +rpmhpd_opp_turbo_l1: opp10 {
>> +qcom-level = <416>;
>> +};
>> +};
>> -- 
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
>> of Code Aurora Forum, hosted by The Linux Foundation
>>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Re: [PATCH] ipc: Limit sysctl value to IPCMNI

[Takashi Iwai]

On Tue, 12 Jun 2018 01:18:45 +0200,
Andrew Morton wrote:
> 
> On Sat, 09 Jun 2018 08:48:48 +0200 Takashi Iwai  wrote:
> 
> > On Fri, 08 Jun 2018 23:16:59 +0200,
> > Andrew Morton wrote:
> > > 
> > > On Fri,  8 Jun 2018 15:49:49 +0200 Takashi Iwai  wrote:
> > > 
> > > > Currently shmmni proc entry accepts all entered integer values, but
> > > > the practical limit is IPCMNI (32768).  This confuses user as if a
> > > > bigger value were accepted but not applied correctly.
> > > > 
> > > > This patch changes the proc entry to use *_minmax variant to limit the
> > > > accepted values accordingly.
> > > 
> > > Waiman Long was working on a (vastly more complicated) patchset to
> > > address this.
> > 
> > That's great.  Any patch available for testing?
> 
> I think
> http://lkml.kernel.org/r/1520885744-1546-1-git-send-email-long...@redhat.com
> is the most recent version.
> 
> > 
> > > > --- a/ipc/ipc_sysctl.c
> > > > +++ b/ipc/ipc_sysctl.c
> > > > @@ -99,6 +99,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table 
> > > > *table, int write,
> > > >  static int zero;
> > > >  static int one = 1;
> > > >  static int int_max = INT_MAX;
> > > > +static int ipcmni = IPCMNI;
> > > >  
> > > >  static struct ctl_table ipc_kern_table[] = {
> > > > {
> > > > @@ -120,7 +121,9 @@ static struct ctl_table ipc_kern_table[] = {
> > > > .data   = &init_ipc_ns.shm_ctlmni,
> > > > .maxlen = sizeof(init_ipc_ns.shm_ctlmni),
> > > > .mode   = 0644,
> > > > -   .proc_handler   = proc_ipc_dointvec,
> > > > +   .proc_handler   = proc_ipc_dointvec_minmax,
> > > > +   .extra1 = &zero,
> > > > +   .extra2 = &ipcmni,
> > > > },
> > > > {
> > > > .procname   = "shm_rmid_forced",
> > > 
> > > What is the back-compatibility situation here?
> > 
> > It's obviously an error to set such a high value and suppose that it
> > were accepted.  So relying on that behavior must be broken in
> > anyway...
> 
> Well the present behaviour is to convert higher values downwards, yes?
> 
> int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int limit)
> {
>   kuid_t euid;
>   kgid_t egid;
>   int id, err;
> 
>   if (limit > IPCMNI)
>   limit = IPCMNI;
> 
> So if someone out there is presently setting this to 99 then their
> kernel will work just fine.  After your proposed change, it will no
> longer do so - the tuning attempt will fail with -EINVAL.
> 
> It really does us no good to say "you shouldn't have been doing that". 
> The fact that they *are* doing it and that it works OK is the kernel
> developers' fault for not applying suitable checking on day one.  I
> think we're stuck with continuing to accept such input.

Hm, that's one concern, yes.

OTOH, we do secretly ignore the input value, and this isn't what's
expected by user, either.  Moreover, user-space has no slightest idea
which value can be accepted and which not.

Actually I posted it just because of requests from customers who
needed to raise the bar, but didn't notice the effect.

Maybe another possible solution would be to add another proc entry to
handle this correctly, and make the old one only for compatibility.


thanks,

Takashi

Re: [PATCH] ipc: Limit sysctl value to IPCMNI

[Takashi Iwai]

On Mon, 11 Jun 2018 23:27:08 +0200,
Waiman Long wrote:
> 
> On 06/08/2018 05:16 PM, Andrew Morton wrote:
> > On Fri,  8 Jun 2018 15:49:49 +0200 Takashi Iwai  wrote:
> >
> >> Currently shmmni proc entry accepts all entered integer values, but
> >> the practical limit is IPCMNI (32768).  This confuses user as if a
> >> bigger value were accepted but not applied correctly.
> >>
> >> This patch changes the proc entry to use *_minmax variant to limit the
> >> accepted values accordingly.
> > Waiman Long was working on a (vastly more complicated) patchset to
> > address this.
> >
> >> --- a/ipc/ipc_sysctl.c
> >> +++ b/ipc/ipc_sysctl.c
> >> @@ -99,6 +99,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, 
> >> int write,
> >>  static int zero;
> >>  static int one = 1;
> >>  static int int_max = INT_MAX;
> >> +static int ipcmni = IPCMNI;
> >>  
> >>  static struct ctl_table ipc_kern_table[] = {
> >>{
> >> @@ -120,7 +121,9 @@ static struct ctl_table ipc_kern_table[] = {
> >>.data   = &init_ipc_ns.shm_ctlmni,
> >>.maxlen = sizeof(init_ipc_ns.shm_ctlmni),
> >>.mode   = 0644,
> >> -  .proc_handler   = proc_ipc_dointvec,
> >> +  .proc_handler   = proc_ipc_dointvec_minmax,
> >> +  .extra1 = &zero,
> >> +  .extra2 = &ipcmni,
> >>},
> >>{
> >>.procname   = "shm_rmid_forced",
> > What is the back-compatibility situation here?
> >
> >
> Sorry for the late reply. I am planning to send out an updated patch
> once the merge window is closed. The latest patch can be found in
> 
> https://lkml.org/lkml/2018/5/7/666
> 
> Luis has some concern about the use of __read_mostly tag which I am
> going to remove in the next version.

Thanks, that's as trivial as my patch, unsurprisingly :)


Takashi

Re: [PATCH] staging: lustre: add error handling for try_module_get

[Greg Kroah-Hartman]

On Tue, Jun 12, 2018 at 12:49:26PM +0800, Zhouyang Jia wrote:
> When try_module_get fails, the lack of error-handling code may
> cause unexpected results.
> 
> This patch adds error-handling code after calling try_module_get.
> 
> Signed-off-by: Zhouyang Jia 
> ---
>  drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 5 -

This patch does not apply to Linus's tree.  Always be sure to work
against linux-next to catch things like this.

thanks,

greg k-h

Re: [PATCH] staging: speakup: refactor synths array to use a list

[Samuel Thibault]

Gregory Nowak, le lun. 11 juin 2018 16:51:22 -0700, a ecrit:
> On Tue, Jun 12, 2018 at 12:57:03AM +0200, Samuel Thibault wrote:
> > Anybody up for testing please?
> > 
> > If people want to see speakup get mainlined instead of staging, please
> > help.
> 
> If I understand right, this patch changes how synthesizers are loaded
> and unloaded through /sys/accessibility/speakup/synth, correct?

The load/unload is about the module itself, i.e. modprobe speakup_bns ;
modprobe speakup_soft, switch between them, then rmmod speakup_bns ;
speakup_soft or the converse (to exercise both orders).

Thanks!
Samuel

Re: [PATCH] mmc: Move the mmc driver init earlier

[Ulf Hansson]

On 8 June 2018 at 11:51, Feng Tang  wrote:
> When doing some boot time optimization for an eMMC rootfs NUCs,
> we found the rootfs may spend around 100 microseconds waiting
> for eMMC card to be initialized, then the rootfs could be
> mounted.
> [1.216561] Waiting for root device /dev/mmcblk1p1...
> [1.289262] mmc1: new HS400 MMC card at address 0001
> [1.289667] mmcblk1: mmc1:0001 R1J56L 14.7 GiB
> [1.289772] mmcblk1boot0: mmc1:0001 R1J56L partition 1 8.00 MiB
> [1.289869] mmcblk1boot1: mmc1:0001 R1J56L partition 2 8.00 MiB
> [1.289967] mmcblk1rpmb: mmc1:0001 R1J56L partition 3 4.00 MiB
> [1.292798]  mmcblk1: p1 p2 p3
> [1.300576] EXT4-fs (mmcblk1p1): couldn't mount as ext3 due to 
> feature incompatibilities
> [1.300912] EXT4-fs (mmcblk1p1): couldn't mount as ext2 due to 
> feature incompatibilities
>
> And this is a common problem for smartphones, tablets, embedded
> devices and automotive products. This patch will make the eMMC/SD
> card  start initializing earlier, by changing its order in drivers/Makefile.
>
> On our platform, the waiting for eMMC card is almost eliminated with the 
> patch,
> which is critical to boot time.

I am wondering what kernel version you are running here. There have
been some changes to the mmc initialization path, which perhaps can
help.

>
> Signed-off-by: Feng Tang 
> ---
>  drivers/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 24cd47014657..c473afd3c688 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -50,6 +50,9 @@ obj-$(CONFIG_REGULATOR)   += regulator/
>  # reset controllers early, since gpu drivers might rely on them to initialize
>  obj-$(CONFIG_RESET_CONTROLLER) += reset/
>
> +# put mmc early as many morden devices use emm/sd card as rootfs storage
> +obj-y  += mmc/
> +

Your suggested approach isn't really a solution, as it may work for
your particular case but not for everybody else.

>  # tty/ comes before char/ so that the VT console is the boot-time
>  # default.
>  obj-y  += tty/
> @@ -128,7 +131,6 @@ obj-$(CONFIG_EISA)  += eisa/
>  obj-$(CONFIG_PM_OPP)   += opp/
>  obj-$(CONFIG_CPU_FREQ) += cpufreq/
>  obj-$(CONFIG_CPU_IDLE) += cpuidle/
> -obj-y  += mmc/
>  obj-$(CONFIG_MEMSTICK) += memstick/
>  obj-$(CONFIG_NEW_LEDS) += leds/
>  obj-$(CONFIG_INFINIBAND)   += infiniband/
> --
> 2.14.1
>

Kind regards
Uffe

Re: [GIT PULL] FSI updates

[Greg Kroah-Hartman]

On Tue, Jun 12, 2018 at 02:14:25PM +1000, Benjamin Herrenschmidt wrote:
> Hi Greg !
> 
> There are a first round of updates of the FSI stack, aiming at 
> reducing/removing
> the gap with the OpenBMC tree and a first step in getting dependent drivers
> upstream.
> 
> These changes significantly improve the FSI bitbanging driver performance
> and reliability, and add the new "sbefifo" driver for communicating with
> the POWER9 Self Boot Engine (which will be needed for some upcoming
> additional drivers).
> 
> [ Apologies if I got part of the process wrong, I haven't
>   sent a pull request in years ;-) ]

So, these are all for 4.19-rc1, right?  Not bugfixes for 4.18-final?

> The following changes since commit 8efcf34a263965e471e304f94d1f6799d42a:
> 
>   Merge tag 'armsoc-late' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-06-11 
> 18:19:45 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git 

I need a signed tag to pull from, not just a git tree, otherwise I don't
know that you really sent me what you think you sent me :)

Can you fix that up, and tell me where you want this to go and then I
can take it after 4.18-rc1 is out.

thanks,

greg k-h

Re: [PATCH] proc: Fix parsing of mount parameters.

[Alistair Strachan]

On Mon, Jun 11, 2018 at 6:22 PM Eric W. Biederman  wrote:
>
> Alistair Strachan  writes:
>
> > In commit e94591d0d90c "proc: Convert proc_mount to use mount_ns"
> > the parsing of mount parameters for the proc filesystem was broken.
> >
> > The SB_KERNMOUNT for procfs happens via:
> >
> >   start_kernel()
> > rest_init()
> >   kernel_thread()
> > _do_fork()
> >copy_process()
> >  alloc_pid()
> >pid_ns_prepare_proc()
> >  kern_mount_data()
> >proc_mount()
> >  mount_ns()
> >
> > In mount_ns(), the kernel calls proc_fill_super() only if the superblock
> > has not previously been set up (i.e. the first mount reference),
> > regardless of SB_KERNMOUNT. Because the call to proc_parse_options() had
> > been moved inside here, and the SB_KERNMOUNT uses no mount options, the
> > option parser became a no-op.
> >
> > When userspace later mounted procfs with e.g. hidepid=2, the options
> > would be ignored.
> >
> > This change backs out a part of the original cleanup and parses the
> > procfs mount options at every mount call. Because the options currently
> > only update the pid_ns for the mount, they are applied for all mounts of
> > proc by that pid or childen of that pid, instantaneously. This is the
> > same behavior as the original code.
>
> Two years for a regression to be reported is a litte long.  I think that
> gets out of the kneejerk immediate fix or revert phase and into thinking
> a little bout about what makes sense in this code.

Android has been using hidepid=2 for a while, but most shipping
products were on 3.18 or 4.4 kernels. To us, it's a new problem.

> As we say with devpts there is a very real danger of someone mounting
> a second instance of proc in a chroot and causing problems by either
> strengthening or weakening the hid pid protections for the entire pid
> namespace.  If we go with your proposed change in behavior.

I guess my change does change the behavior, but it's just back to the
behavior which the kernel had for a good while (~v3.3 thru v4.7).

> Ordinary block device filesystems (like ext4) avoid this problem by
> allowing a second mount and by not parsing the mount options except
> on remount.  What proc currently does.

IMHO, they're not really comparable. You'll only get kernmounts of an
ext4 filesystem when finding rootfs, and in that case the user knows
about the mount and can see it in /proc/mounts, so they know to use -o
remount,.

Since the first mount (where the options might have been respected) is
*always* the kernmount done before init, with your change these mount
options for procfs will never be respected. As userspace didn't yet
mount /proc, it can't know /proc was already mounted, in order to know
to use a remount to re-parse the options. The behavior was changed in
a non-obvious way.

> So I think it can be reasonably argued that the change in behavior is
> was an unintentional fix.
>
> I can see an argument for failing the mount of proc if mount options
> are specified or if those mount options differ from the existing mount
> options.
>
> proc_remount's call of proc_parse_options is definitely buggy as it can
> partially succeed and change the pid namespace and return an error code.
> That is bad error handling.
>
> There may be an argument for making these options available in something
> other than a mount of proc.  As they are pid namespace wide.
>
> There may be an argument for multiple instances of proc so that it makes
> sense to process these options during an ordinary mount.
>
>
> Ultimately what I see is that this is a difficult area of semantics that
> there is at least a little room for improvement on, but it is not
> as simple as this proposed change.

An alternative fix might be to ignore the super setup if done from a
kernmount of procfs. IMO, this initial mount shouldn't be considered
the first reference, because it will not pass the mount options and
cannot be observed by userspace. Such a change looks complicated,
though, and it would only be relevant to procfs. It might be better to
roll back the cleanup and implement these semantics directly in the
procfs code.

> > Fixes: e94591d0d90c ("proc: Convert proc_mount to use mount_ns")
> > Signed-off-by: Alistair Strachan 
> > Cc: Seth Forshee 
> > Cc: Djalal Harouni 
> > Cc: "Eric W. Biederman" 
> > Cc: kernel-t...@android.com
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >  fs/proc/inode.c| 4 
> >  fs/proc/internal.h | 1 -
> >  fs/proc/root.c | 5 -
> >  3 files changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/proc/inode.c b/fs/proc/inode.c
> > index 2cf3b74391ca..f348be0a 100644
> > --- a/fs/proc/inode.c
> > +++ b/fs/proc/inode.c
> > @@ -492,13 +492,9 @@ struct inode *proc_get_inode(struct super_block *sb, 
> > struct proc_dir_entry *de)
> >
> >  int proc_fill_super(struct super_block *s, void *data, int silent)
> >  {
> > - struct pid_namespace 

Re: [PATCHv4 1/3] scripts: Preprocess module-common.lds

[Michael Ellerman]

kbuild test robot  writes:

> Hi Laura,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.17 next-20180608]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Laura-Abbott/scripts-Preprocess-module-common-lds/20180612-083632
> config: i386-randconfig-a1-201823 (attached as .config)
> compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
>
> All errors (new ones prefixed by >>):
>
>>> ld: cannot open linker script file scripts/module-common.lds: No such file 
>>> or directory

This seems to need the following.

cheers


diff --git a/Makefile b/Makefile
index 73f0bb2c7a98..55a5725b6606 100644
--- a/Makefile
+++ b/Makefile
@@ -425,7 +425,7 @@ KBUILD_AFLAGS_KERNEL :=
 KBUILD_CFLAGS_KERNEL :=
 KBUILD_AFLAGS_MODULE  := -DMODULE
 KBUILD_CFLAGS_MODULE  := -DMODULE
-KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
+KBUILD_LDFLAGS_MODULE := -T $(objtree)/scripts/module-common.lds
 LDFLAGS :=
 GCC_PLUGINS_CFLAGS :=
 

Re: [PATCH v2 1/2] gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe

[Alexander Stein]

On Tuesday, June 12, 2018, 7:27:52 AM CEST Keerthy wrote:
> This is needed in case of PROBE_DEFER if IRQ resource is not yet ready.
> 
> Signed-off-by: Keerthy 
> ---
> [...]
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> [...]
> @@ -168,7 +168,7 @@ static int davinci_gpio_probe(struct platform_device 
> *pdev)
>  {
>   static int ctrl_num, bank_base;
>   int gpio, bank, ret = 0;
> - unsigned ngpio, nbank;
> + unsigned ngpio, nbank, bank_irq;

bank_irq should be an int, not unsigned, no?

>   struct davinci_gpio_controller *chips;
>   struct davinci_gpio_platform_data *pdata;
>   struct device *dev = &pdev->dev;
> @@ -209,6 +209,12 @@ static int davinci_gpio_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(gpio_base))
>   return PTR_ERR(gpio_base);
>  
> + bank_irq = platform_get_irq(pdev, 0);
> + if (bank_irq < 0) {

This won't work using an unsigned.

Best regards,
Alexander

Re: [PATCH v2 1/2] gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe

[Keerthy]

On Tuesday 12 June 2018 11:15 AM, Alexander Stein wrote:
> On Tuesday, June 12, 2018, 7:27:52 AM CEST Keerthy wrote:
>> This is needed in case of PROBE_DEFER if IRQ resource is not yet ready.
>>
>> Signed-off-by: Keerthy 
>> ---
>> [...]
>> --- a/drivers/gpio/gpio-davinci.c
>> +++ b/drivers/gpio/gpio-davinci.c
>> [...]
>> @@ -168,7 +168,7 @@ static int davinci_gpio_probe(struct platform_device 
>> *pdev)
>>  {
>>  static int ctrl_num, bank_base;
>>  int gpio, bank, ret = 0;
>> -unsigned ngpio, nbank;
>> +unsigned ngpio, nbank, bank_irq;
> 
> bank_irq should be an int, not unsigned, no?

Yes

> 
>>  struct davinci_gpio_controller *chips;
>>  struct davinci_gpio_platform_data *pdata;
>>  struct device *dev = &pdev->dev;
>> @@ -209,6 +209,12 @@ static int davinci_gpio_probe(struct platform_device 
>> *pdev)
>>  if (IS_ERR(gpio_base))
>>  return PTR_ERR(gpio_base);
>>  
>> +bank_irq = platform_get_irq(pdev, 0);
>> +if (bank_irq < 0) {
> 
> This won't work using an unsigned.

Thanks for catching this. I will correct this in v3.

> 
> Best regards,
> Alexander
> 
> 
> 

uapi headers userspace build results

[Randy Dunlap]

Hi,

Here is what I have so far.  It begins with a makefile and some
template files that are added to.  There's a good bit of Perl also.

I put all of these files in tools/uapi/ and run them from there.

There is one .c file generated for each .h file in builddir/usr/include
(O=builddir).

Out of 889 header files, I see 45 errors.  That is better than I expected.

The makefiles and scripts are attached (tar), as well as the output (I used
'make -ik' so that make would keep going after errors and attempt to build
all target files).

have fun!
-- 
~Randy
gcc  "-I../../xx64/usr/include" -c -o drm.i810_drm.o drm.i810_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.drm_fourcc.o drm.drm_fourcc.c
gcc  "-I../../xx64/usr/include" -c -o drm.etnaviv_drm.o drm.etnaviv_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.i915_drm.o drm.i915_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.drm_mode.o drm.drm_mode.c
gcc  "-I../../xx64/usr/include" -c -o drm.vc4_drm.o drm.vc4_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.mga_drm.o drm.mga_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.v3d_drm.o drm.v3d_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.msm_drm.o drm.msm_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.amdgpu_drm.o drm.amdgpu_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.exynos_drm.o drm.exynos_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.sis_drm.o drm.sis_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.armada_drm.o drm.armada_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.savage_drm.o drm.savage_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.r128_drm.o drm.r128_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.qxl_drm.o drm.qxl_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.vmwgfx_drm.o drm.vmwgfx_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.drm_sarea.o drm.drm_sarea.c
gcc  "-I../../xx64/usr/include" -c -o drm.via_drm.o drm.via_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.tegra_drm.o drm.tegra_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.omap_drm.o drm.omap_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.radeon_drm.o drm.radeon_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.virtgpu_drm.o drm.virtgpu_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.vgem_drm.o drm.vgem_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.nouveau_drm.o drm.nouveau_drm.c
gcc  "-I../../xx64/usr/include" -c -o drm.drm.o drm.drm.c
gcc  "-I../../xx64/usr/include" -c -o mtd.mtd-user.o mtd.mtd-user.c
gcc  "-I../../xx64/usr/include" -c -o mtd.ubi-user.o mtd.ubi-user.c
gcc  "-I../../xx64/usr/include" -c -o mtd.nftl-user.o mtd.nftl-user.c
gcc  "-I../../xx64/usr/include" -c -o mtd.mtd-abi.o mtd.mtd-abi.c
gcc  "-I../../xx64/usr/include" -c -o mtd.inftl-user.o mtd.inftl-user.c
gcc  "-I../../xx64/usr/include" -c -o sound.emu10k1.o sound.emu10k1.c
gcc  "-I../../xx64/usr/include" -c -o sound.sb16_csp.o sound.sb16_csp.c
gcc  "-I../../xx64/usr/include" -c -o sound.firewire.o sound.firewire.c
gcc  "-I../../xx64/usr/include" -c -o sound.asound_fm.o sound.asound_fm.c
gcc  "-I../../xx64/usr/include" -c -o sound.usb_stream.o sound.usb_stream.c
gcc  "-I../../xx64/usr/include" -c -o sound.compress_params.o 
sound.compress_params.c
gcc  "-I../../xx64/usr/include" -c -o sound.asoc.o sound.asoc.c
gcc  "-I../../xx64/usr/include" -c -o sound.sfnt_info.o sound.sfnt_info.c
gcc  "-I../../xx64/usr/include" -c -o sound.snd_sst_tokens.o 
sound.snd_sst_tokens.c
gcc  "-I../../xx64/usr/include" -c -o sound.compress_offload.o 
sound.compress_offload.c
gcc  "-I../../xx64/usr/include" -c -o sound.asequencer.o sound.asequencer.c
gcc  "-I../../xx64/usr/include" -c -o sound.hdspm.o sound.hdspm.c
gcc  "-I../../xx64/usr/include" -c -o sound.tlv.o sound.tlv.c
gcc  "-I../../xx64/usr/include" -c -o sound.asound.o sound.asound.c
gcc  "-I../../xx64/usr/include" -c -o sound.hdsp.o sound.hdsp.c
gcc  "-I../../xx64/usr/include" -c -o rdma.mlx5_user_ioctl_verbs.o 
rdma.mlx5_user_ioctl_verbs.c
gcc  "-I../../xx64/usr/include" -c -o rdma.ib_user_mad.o rdma.ib_user_mad.c
gcc  "-I../../xx64/usr/include" -c -o rdma.rdma_user_rxe.o rdma.rdma_user_rxe.c
gcc  "-I../../xx64/usr/include" -c -o rdma.ocrdma-abi.o rdma.ocrdma-abi.c
gcc  "-I../../xx64/usr/include" -c -o rdma.ib_user_cm.o rdma.ib_user_cm.c
gcc  "-I../../xx64/usr/include" -c -o rdma.ib_user_ioctl_cmds.o 
rdma.ib_user_ioctl_cmds.c
gcc  "-I../../xx64/usr/include" -c -o rdma.i40iw-abi.o rdma.i40iw-abi.c
gcc  "-I../../xx64/usr/include" -c -o rdma.rdma_netlink.o rdma.rdma_netlink.c
gcc  "-I../../xx64/usr/include" -c -o rdma.cxgb4-abi.o rdma.cxgb4-abi.c
gcc  "-I../../xx64/usr/include" -c -o rdma.ib_user_sa.o rdma.ib_user_sa.c
gcc  "-I../../xx64/usr/include" -c -o rdma.hns-abi.o rdma.hns-abi.c
gcc  "-I../../xx64/usr/include" -c -o rdma.rdma_user_cm.o rdma.rdma_user_cm.c
gcc  "-I../../xx64/usr/include" -c -o rdma.bnxt_re-abi.o rdma.bnxt_re-abi.c
gcc  "-I../../xx64/usr/include" -c -o rdma.mthca-abi.o rdma.mthca-abi.c
gcc  "-I../../xx64/usr/include" -c -o rdma.qedr-abi.o rdma.qedr-abi.c
gcc  "-I../../xx64/usr/include" -c -o rdma.mlx5_use

[PATCH 5/7] tty: serial: lantiq: Convert global lock to per device lock

[Songjun Wu]

Previous implementation uses one global lock to protect the resource.
If the serial driver have multiple entries, this kind of lock will
slow down the performance.
Add the lock at device level. This will lock only when the function
calling only to the same device.
So that it can avoid useless lock protection.

Signed-off-by: Songjun Wu 
---

 drivers/tty/serial/lantiq.c | 51 ++---
 1 file changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 1127586dbc94..72aab1b05265 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -107,7 +107,6 @@
 static void lqasc_tx_chars(struct uart_port *port);
 static struct ltq_uart_port *lqasc_port[MAXPORTS];
 static struct uart_driver lqasc_reg;
-static DEFINE_SPINLOCK(ltq_asc_lock);
 
 struct ltq_uart_port {
struct uart_portport;
@@ -118,6 +117,7 @@ struct ltq_uart_port {
unsigned inttx_irq;
unsigned intrx_irq;
unsigned interr_irq;
+   spinlock_t  lock;  /* exclusive access for multi core */
 };
 
 static inline struct ltq_uart_port *to_ltq_uart_port(struct uart_port *port)
@@ -133,10 +133,11 @@ static void lqasc_stop_tx(struct uart_port *port)
 static void lqasc_start_tx(struct uart_port *port)
 {
unsigned long flags;
-   spin_lock_irqsave(lock, flags);
lqasc_tx_chars(port);
-   spin_unlock_irqrestore(lock, flags);
 }
 
 static void lqasc_stop_rx(struct uart_port *port)
@@ -238,10 +239,14 @@ static irqreturn_t lqasc_tx_int(int irq, void *_port)
 {
unsigned long flags;
struct uart_port *port = (struct uart_port *)_port;
-   spin_lock_irqsave(lock, flags);
writel(ASC_IRNCR_TIR, port->membase + LTQ_ASC_IRNCR);
-   spin_unlock_irqrestore(lock, flags);
+
lqasc_start_tx(port);
+
return IRQ_HANDLED;
 }
 
@@ -250,8 +255,9 @@ static irqreturn_t lqasc_err_int(int irq, void *_port)
unsigned long flags;
u32 stat;
struct uart_port *port = (struct uart_port *)_port;
+   struct ltq_uart_port *ltq_port = to_ltq_uart_port(port);
 
-   spin_lock_irqsave(lock, flags);
/* clear any pending interrupts */
writel(ASC_IRNCR_EIR, port->membase + LTQ_ASC_IRNCR);
stat = readl(port->membase + LTQ_ASC_STATE);
@@ -266,7 +272,7 @@ static irqreturn_t lqasc_err_int(int irq, void *_port)
port->icount.overrun++;
}
asc_w32_mask(0, ASCWHBSTATE_CLRALL, port->membase + LTQ_ASC_WHBSTATE);
-   spin_unlock_irqrestore(lock, flags);
 
return IRQ_HANDLED;
 }
@@ -275,10 +281,13 @@ static irqreturn_t lqasc_rx_int(int irq, void *_port)
 {
unsigned long flags;
struct uart_port *port = (struct uart_port *)_port;
-   spin_lock_irqsave(lock, flags);
writel(ASC_IRNCR_RIR, port->membase + LTQ_ASC_IRNCR);
lqasc_rx_chars(port);
-   spin_unlock_irqrestore(lock, flags);
+
return IRQ_HANDLED;
 }
 
@@ -309,11 +318,13 @@ lqasc_startup(struct uart_port *port)
 {
struct ltq_uart_port *ltq_port = to_ltq_uart_port(port);
int retval;
+   unsigned long flags;
 
if (!IS_ERR(ltq_port->clk))
clk_enable(ltq_port->clk);
port->uartclk = clk_get_rate(ltq_port->fpiclk);
 
+   spin_lock_irqsave(lock, flags);
asc_w32_mask(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
 
@@ -330,6 +341,7 @@ lqasc_startup(struct uart_port *port)
wmb();
asc_w32_mask(0, ASCCON_M_8ASYNC | ASCCON_FEN | ASCCON_TOEN |
 ASCCON_ROEN, port->membase + LTQ_ASC_CON);
+   spin_unlock_irqrestore(lock, flags);
 
retval = request_irq(ltq_port->tx_irq, lqasc_tx_int,
 0, "asc_tx", port);
@@ -410,6 +422,7 @@ static void lqasc_set_termios(struct uart_port *port,
unsigned long flags;
u32 fdv = 0;
u32 reload = 0;
+   struct ltq_uart_port *ltq_port = to_ltq_uart_port(port);
 
cflag = new->c_cflag;
iflag = new->c_iflag;
@@ -463,7 +476,7 @@ static void lqasc_set_termios(struct uart_port *port,
/* set error signals  - framing,

[PATCH 4/7] tty: serial: lantiq: Always use readl()/writel()

[Songjun Wu]

Previous implementation uses platform-dependent functions
ltq_w32()/ltq_r32() to access registers. Those functions are not
available for other SoC which uses the same IP.
Change to OS provided readl()/writel() and readb()/writeb(), so
that different SoCs can use the same driver.

Signed-off-by: Songjun Wu 
---

 arch/mips/Kconfig   |   1 -
 drivers/tty/serial/lantiq.c | 236 
 2 files changed, 128 insertions(+), 109 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index c82cebeb6192..7bae259edd0b 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -395,7 +395,6 @@ config LANTIQ
select SYS_SUPPORTS_VPE_LOADER
select SYS_HAS_EARLY_PRINTK
select GPIOLIB
-   select SWAP_IO_SPACE
select BOOT_RAW
select CLKDEV_LOOKUP
select USE_OF
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 044128277248..1127586dbc94 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -49,7 +49,8 @@
 #define LTQ_ASC_RXFCON 0x0040
 #define LTQ_ASC_CON0x0010
 #define LTQ_ASC_BG 0x0050
-#define LTQ_ASC_IRNREN 0x00F4
+#define LTQ_ASC_FDV0x0058
+#define LTQ_ASC_IRNEN  0x00F4
 
 #define ASC_IRNREN_TX  0x1
 #define ASC_IRNREN_RX  0x2
@@ -62,6 +63,7 @@
 #define ASCOPT_CSIZE   0x3
 #define TXFIFO_FL  1
 #define RXFIFO_FL  1
+#define ASCCLC_DISR0x1
 #define ASCCLC_DISS0x2
 #define ASCCLC_RMCMASK 0xFF00
 #define ASCCLC_RMCOFFSET   8
@@ -84,6 +86,7 @@
 #define ASCWHBSTATE_CLRPE  0x0004
 #define ASCWHBSTATE_CLRFE  0x0008
 #define ASCWHBSTATE_CLRROE 0x0020
+#define ASCWHBSTATE_CLRALL 0x00FC
 #define ASCTXFCON_TXFEN0x0001
 #define ASCTXFCON_TXFFLU   0x0002
 #define ASCTXFCON_TXFITLMASK   0x3F00
@@ -97,6 +100,10 @@
 #define ASCFSTAT_TXFREEMASK0x3F00
 #define ASCFSTAT_TXFREEOFF 24
 
+#define asc_w32_mask(clear, set, reg)  \
+   ({ typeof(reg) reg_ = (reg);\
+   writel((readl(reg_) & ~(clear)) | (set), reg_); })
+
 static void lqasc_tx_chars(struct uart_port *port);
 static struct ltq_uart_port *lqasc_port[MAXPORTS];
 static struct uart_driver lqasc_reg;
@@ -113,20 +120,17 @@ struct ltq_uart_port {
unsigned interr_irq;
 };
 
-static inline struct
-ltq_uart_port *to_ltq_uart_port(struct uart_port *port)
+static inline struct ltq_uart_port *to_ltq_uart_port(struct uart_port *port)
 {
return container_of(port, struct ltq_uart_port, port);
 }
 
-static void
-lqasc_stop_tx(struct uart_port *port)
+static void lqasc_stop_tx(struct uart_port *port)
 {
return;
 }
 
-static void
-lqasc_start_tx(struct uart_port *port)
+static void lqasc_start_tx(struct uart_port *port)
 {
unsigned long flags;
spin_lock_irqsave(membase + LTQ_ASC_WHBSTATE);
+   writel(ASCWHBSTATE_CLRREN, port->membase + LTQ_ASC_WHBSTATE);
 }
 
-static int
-lqasc_rx_chars(struct uart_port *port)
+static int lqasc_rx_chars(struct uart_port *port)
 {
struct tty_port *tport = &port->state->port;
unsigned int ch = 0, rsr = 0, fifocnt;
 
-   fifocnt = ltq_r32(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_RXFFLMASK;
+   fifocnt = readl(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_RXFFLMASK;
while (fifocnt--) {
u8 flag = TTY_NORMAL;
-   ch = ltq_r8(port->membase + LTQ_ASC_RBUF);
-   rsr = (ltq_r32(port->membase + LTQ_ASC_STATE)
+   ch = readb(port->membase + LTQ_ASC_RBUF);
+   rsr = (readl(port->membase + LTQ_ASC_STATE)
& ASCSTATE_ANY) | UART_DUMMY_UER_RX;
tty_flip_buffer_push(tport);
port->icount.rx++;
@@ -163,16 +165,16 @@ lqasc_rx_chars(struct uart_port *port)
if (rsr & ASCSTATE_ANY) {
if (rsr & ASCSTATE_PE) {
port->icount.parity++;
-   ltq_w32_mask(0, ASCWHBSTATE_CLRPE,
+   asc_w32_mask(0, ASCWHBSTATE_CLRPE,
port->membase + LTQ_ASC_WHBSTATE);
} else if (rsr & ASCSTATE_FE) {
port->icount.frame++;
-   ltq_w32_mask(0, ASCWHBSTATE_CLRFE,
+   asc_w32_mask(0, ASCWHBSTATE_CLRFE,
port->membase + LTQ_ASC_WHBSTATE);
}
if (rsr & ASCSTATE_ROE) {
port->icount.overrun++;
- 

[PATCH 3/7] MIPS: intel: Add initial support for Intel MIPS SoCs

[Songjun Wu]

From: Hua Ma 

Add initial support for Intel MIPS interAptiv SoCs made by Intel.
This series will add support for the GRX500 family.

The series allows booting a minimal system using a initramfs.

Signed-off-by: Hua ma 
Signed-off-by: Songjun Wu 
---

 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  36 
 arch/mips/boot/dts/Makefile|   1 +
 arch/mips/boot/dts/intel-mips/Makefile |   3 +
 arch/mips/boot/dts/intel-mips/easy350_anywan.dts   |  20 +++
 arch/mips/boot/dts/intel-mips/xrx500.dtsi  | 196 +
 arch/mips/configs/grx500_defconfig | 165 +
 .../asm/mach-intel-mips/cpu-feature-overrides.h|  61 +++
 arch/mips/include/asm/mach-intel-mips/ioremap.h|  39 
 arch/mips/include/asm/mach-intel-mips/irq.h|  17 ++
 .../asm/mach-intel-mips/kernel-entry-init.h|  76 
 arch/mips/include/asm/mach-intel-mips/spaces.h |  29 +++
 arch/mips/include/asm/mach-intel-mips/war.h|  18 ++
 arch/mips/intel-mips/Kconfig   |  22 +++
 arch/mips/intel-mips/Makefile  |   3 +
 arch/mips/intel-mips/Platform  |  11 ++
 arch/mips/intel-mips/irq.c |  36 
 arch/mips/intel-mips/prom.c| 184 +++
 arch/mips/intel-mips/time.c|  56 ++
 19 files changed, 974 insertions(+)
 create mode 100644 arch/mips/boot/dts/intel-mips/Makefile
 create mode 100644 arch/mips/boot/dts/intel-mips/easy350_anywan.dts
 create mode 100644 arch/mips/boot/dts/intel-mips/xrx500.dtsi
 create mode 100644 arch/mips/configs/grx500_defconfig
 create mode 100644 
arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h
 create mode 100644 arch/mips/include/asm/mach-intel-mips/ioremap.h
 create mode 100644 arch/mips/include/asm/mach-intel-mips/irq.h
 create mode 100644 arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h
 create mode 100644 arch/mips/include/asm/mach-intel-mips/spaces.h
 create mode 100644 arch/mips/include/asm/mach-intel-mips/war.h
 create mode 100644 arch/mips/intel-mips/Kconfig
 create mode 100644 arch/mips/intel-mips/Makefile
 create mode 100644 arch/mips/intel-mips/Platform
 create mode 100644 arch/mips/intel-mips/irq.c
 create mode 100644 arch/mips/intel-mips/prom.c
 create mode 100644 arch/mips/intel-mips/time.c

diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
index ac7ad54f984f..bcd647060f3e 100644
--- a/arch/mips/Kbuild.platforms
+++ b/arch/mips/Kbuild.platforms
@@ -12,6 +12,7 @@ platforms += cobalt
 platforms += dec
 platforms += emma
 platforms += generic
+platforms += intel-mips
 platforms += jazz
 platforms += jz4740
 platforms += lantiq
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 225c95da23ce..c82cebeb6192 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -404,6 +404,41 @@ config LANTIQ
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
 
+config INTEL_MIPS
+   bool "Intel MIPS interAptiv SoC based platforms"
+   select ARCH_HAS_RESET_CONTROLLER
+   select ARCH_SUPPORTS_MSI
+   select BOOT_RAW
+   select CEVT_R4K
+   select COMMON_CLK
+   select CPU_MIPS32_3_5_EVA
+   select CPU_MIPS32_3_5_FEATURES
+   select CPU_MIPSR2_IRQ_EI
+   select CPU_MIPSR2_IRQ_VI
+   select CSRC_R4K
+   select DMA_NONCOHERENT
+   select GENERIC_ISA_DMA
+   select GPIOLIB
+   select HW_HAS_PCI
+   select IRQ_MIPS_CPU
+   select MFD_CORE
+   select MFD_SYSCON
+   select MIPS_CPU_SCACHE
+   select MIPS_GIC
+   select PCI_DRIVERS_GENERIC
+   select RESET_CONTROLLER
+   select SYS_HAS_CPU_MIPS32_R1
+   select SYS_HAS_CPU_MIPS32_R2
+   select SYS_HAS_CPU_MIPS32_R3_5
+   select SYS_HAS_EARLY_PRINTK
+   select SYS_SUPPORTS_BIG_ENDIAN
+   select SYS_SUPPORTS_32BIT_KERNEL
+   select SYS_SUPPORTS_MIPS_CPS
+   select SYS_SUPPORTS_MULTITHREADING
+   select SYS_SUPPORTS_ZBOOT
+   select TIMER_OF
+   select USE_OF
+
 config LASAT
bool "LASAT Networks platforms"
select CEVT_R4K
@@ -1010,6 +1045,7 @@ source "arch/mips/bcm47xx/Kconfig"
 source "arch/mips/bcm63xx/Kconfig"
 source "arch/mips/bmips/Kconfig"
 source "arch/mips/generic/Kconfig"
+source "arch/mips/intel-mips/Kconfig"
 source "arch/mips/jazz/Kconfig"
 source "arch/mips/jz4740/Kconfig"
 source "arch/mips/lantiq/Kconfig"
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 1e79cab8e269..05f52f279047 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -3,6 +3,7 @@ subdir-y+= brcm
 subdir-y   += cavium-octeon
 subdir-y   += img
 subdir-y   += ingenic
+subdir-y   += intel-mips
 subdir-y   += lantiq
 subdir-y   += mscc
 subdir-y   += mti
diff --git a/arch/mips/boot/dts/in

[PATCH 6/7] tty: serial: lantiq: Remove unneeded header includes and macros

[Songjun Wu]

Update the author list with Intel Corporation.
Sort the header includes in alphabetical orders.
Remove unneeded header includes and macros.

Signed-off-by: Songjun Wu 
---

 drivers/tty/serial/lantiq.c | 29 +++--
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 72aab1b05265..cc33208c93ac 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -6,24 +6,23 @@
  * Copyright (C) 2007 Felix Fietkau 
  * Copyright (C) 2007 John Crispin 
  * Copyright (C) 2010 Thomas Langer, 
+ * Copyright (C) 2017 Intel Corporation.
  */
 
-#include 
-#include 
-#include 
+#include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -43,7 +42,6 @@
 #define LTQ_ASC_STATE  0x0014
 #define LTQ_ASC_IRNCR  0x00F8
 #define LTQ_ASC_CLC0x
-#define LTQ_ASC_ID 0x0008
 #define LTQ_ASC_PISEL  0x0004
 #define LTQ_ASC_TXFCON 0x0044
 #define LTQ_ASC_RXFCON 0x0040
@@ -51,16 +49,12 @@
 #define LTQ_ASC_BG 0x0050
 #define LTQ_ASC_FDV0x0058
 #define LTQ_ASC_IRNEN  0x00F4
-
 #define ASC_IRNREN_TX  0x1
 #define ASC_IRNREN_RX  0x2
 #define ASC_IRNREN_ERR 0x4
-#define ASC_IRNREN_TX_BUF  0x8
 #define ASC_IRNCR_TIR  0x1
 #define ASC_IRNCR_RIR  0x2
 #define ASC_IRNCR_EIR  0x4
-
-#define ASCOPT_CSIZE   0x3
 #define TXFIFO_FL  1
 #define RXFIFO_FL  1
 #define ASCCLC_DISR0x1
@@ -71,7 +65,6 @@
 #define ASCCON_M_7ASYNC0x2
 #define ASCCON_ODD 0x0020
 #define ASCCON_STP 0x0080
-#define ASCCON_BRS 0x0100
 #define ASCCON_FDE 0x0200
 #define ASCCON_R   0x8000
 #define ASCCON_FEN 0x0002
@@ -80,7 +73,7 @@
 #define ASCSTATE_PE0x0001
 #define ASCSTATE_FE0x0002
 #define ASCSTATE_ROE   0x0008
-#define ASCSTATE_ANY   (ASCSTATE_ROE|ASCSTATE_PE|ASCSTATE_FE)
+#define ASCSTATE_ANY   (ASCSTATE_ROE | ASCSTATE_PE | ASCSTATE_FE)
 #define ASCWHBSTATE_CLRREN 0x0001
 #define ASCWHBSTATE_SETREN 0x0002
 #define ASCWHBSTATE_CLRPE  0x0004
-- 
2.11.0

Re: [PATCH 2/2] nvmem: Add Spreadtrum SC27XX efuse support

[Baolin Wang]

Hi Randy,

On 12 June 2018 at 13:27, Randy Dunlap  wrote:
> On 06/11/2018 10:24 PM, Baolin Wang wrote:
>> From: Freeman Liu 
>>
>> This patch add the efuse driver which is embeded in Spreadtrum SC27XX
>> series PMICs. The sc27xx efuse contains 32 blocks and each block's
>> data width is 16 bits.
>>
>> Signed-off-by: Freeman Liu 
>> Signed-off-by: Baolin Wang 
>> ---
>>  drivers/nvmem/Kconfig|   11 ++
>>  drivers/nvmem/Makefile   |3 +-
>>  drivers/nvmem/sc27xx-efuse.c |  263 
>> ++
>>  3 files changed, 276 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/nvmem/sc27xx-efuse.c
>>
>> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
>> index 54a3c29..3dca608 100644
>> --- a/drivers/nvmem/Kconfig
>> +++ b/drivers/nvmem/Kconfig
>> @@ -181,4 +181,15 @@ config RAVE_SP_EEPROM
>>   help
>> Say y here to enable Rave SP EEPROM support.
>>
>> +config SC27XX_EFUSE
>> + tristate "Spreadtrum SC27XX eFuse Support"
>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>> + depends on HAS_IOMEM
>> + help
>> +   This is a simple drive to dump specified values of Spreadtrum
>
>driver

Sorry for the typo and will fix in next version. Thanks.

-- 
Baolin.wang
Best Regards

[PATCH 1/7] MIPS: dts: Add aliases node for lantiq danube serial

[Songjun Wu]

Previous implementation uses a hard-coded register value to check if
the current serial entity is the console entity.
Now the lantiq serial driver uses the aliases for the index of the
serial port.
The lantiq danube serial dts are updated with aliases to support this.

Signed-off-by: Songjun Wu 
---

 arch/mips/boot/dts/lantiq/danube.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/mips/boot/dts/lantiq/danube.dtsi 
b/arch/mips/boot/dts/lantiq/danube.dtsi
index 2dd950181f8a..7a9e15da6bd0 100644
--- a/arch/mips/boot/dts/lantiq/danube.dtsi
+++ b/arch/mips/boot/dts/lantiq/danube.dtsi
@@ -4,6 +4,10 @@
#size-cells = <1>;
compatible = "lantiq,xway", "lantiq,danube";
 
+   aliases {
+   serial0 = &asc1;
+   };
+
cpus {
cpu@0 {
compatible = "mips,mips24Kc";
@@ -74,7 +78,7 @@
reg = <0xE100A00 0x100>;
};
 
-   serial@E100C00 {
+   asc1: serial@E100C00 {
compatible = "lantiq,asc";
reg = <0xE100C00 0x400>;
interrupt-parent = <&icu0>;
-- 
2.11.0

[PATCH 7/7] tty: serial: lantiq: Add CCF support

[Songjun Wu]

Previous implementation uses platform-dependent API to get the clock.
Those functions are not available for other SoC which uses the same IP.
The CCF (Common Clock Framework) have an abstraction based APIs
for clock.
Change to use CCF APIs to get clock and rate.
So that different SoCs can use the same driver.
Clocks and clock-names are updated in device tree binding.

Signed-off-by: Songjun Wu 

---

 .../devicetree/bindings/serial/lantiq_asc.txt  |  15 +++
 drivers/tty/serial/Kconfig |   2 +-
 drivers/tty/serial/lantiq.c| 101 +
 3 files changed, 98 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.txt 
b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
index 3acbd309ab9d..608f0c87a4af 100644
--- a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
+++ b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
@@ -6,6 +6,10 @@ Required properties:
 - interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier
   depends on the interrupt-parent interrupt controller.
 
+Optional properties:
+- clocks: Should contain frequency clock and gate clock
+- clock-names: Should be "freq" and "asc"
+
 Example:
 
 asc1: serial@e100c00 {
@@ -14,3 +18,14 @@ asc1: serial@e100c00 {
interrupt-parent = <&icu0>;
interrupts = <112 113 114>;
 };
+
+asc0: serial@60 {
+   compatible = "lantiq,asc";
+   reg = <0x60 0x10>;
+   interrupt-parent = <&gic>;
+   interrupts = ,
+   ,
+   ;
+   clocks = <&pll0aclk SSX4_CLK>, <&clkgate1 GATE_URT_CLK>;
+   clock-names = "freq", "asc";
+};
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 0f058df0b070..0f8ac5872a54 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1062,7 +1062,7 @@ config SERIAL_OMAP_CONSOLE
 
 config SERIAL_LANTIQ
bool "Lantiq serial driver"
-   depends on LANTIQ
+   depends on LANTIQ || INTEL_MIPS || COMPILE_TEST
select SERIAL_CORE
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index cc33208c93ac..fd7ba89daaa2 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -24,7 +24,9 @@
 #include 
 #include 
 
+#ifndef CONFIG_COMMON_CLK
 #include 
+#endif
 
 #define PORT_LTQ_ASC   111
 #define MAXPORTS   2
@@ -104,7 +106,7 @@ static struct uart_driver lqasc_reg;
 struct ltq_uart_port {
struct uart_portport;
/* clock used to derive divider */
-   struct clk  *fpiclk;
+   struct clk  *freqclk;
/* clock gating of the ASC core */
struct clk  *clk;
unsigned inttx_irq;
@@ -120,7 +122,6 @@ static inline struct ltq_uart_port *to_ltq_uart_port(struct 
uart_port *port)
 
 static void lqasc_stop_tx(struct uart_port *port)
 {
-   return;
 }
 
 static void lqasc_start_tx(struct uart_port *port)
@@ -291,8 +292,7 @@ static unsigned int lqasc_tx_empty(struct uart_port *port)
return status ? 0 : TIOCSER_TEMT;
 }
 
-static unsigned int
-lqasc_get_mctrl(struct uart_port *port)
+static unsigned int lqasc_get_mctrl(struct uart_port *port)
 {
return TIOCM_CTS | TIOCM_CAR | TIOCM_DSR;
 }
@@ -301,21 +301,65 @@ static void lqasc_set_mctrl(struct uart_port *port, u_int 
mctrl)
 {
 }
 
-static void
-lqasc_break_ctl(struct uart_port *port, int break_state)
+static void lqasc_break_ctl(struct uart_port *port, int break_state)
 {
 }
 
-static int
-lqasc_startup(struct uart_port *port)
+static void lqasc_fdv_and_reload_get(struct ltq_uart_port *ltq_port,
+unsigned int baudrate, unsigned int *fdv,
+unsigned int *reload)
+{
+   unsigned int asc_clk = clk_get_rate(ltq_port->freqclk);
+   unsigned int baudrate1 = baudrate * 8192;
+   unsigned long long baudrate2 = (unsigned long long)baudrate * 1000;
+   unsigned long long fdv_over_bg_fpi;
+   unsigned long long fdv_over_bg;
+   unsigned long long difference;
+   unsigned long long min_difference;
+   unsigned int bg;
+
+   /* Sanity check first */
+   if (baudrate >= (asc_clk >> 4)) {
+   pr_err("%s current fpi clock %u can't provide baudrate %u!!!\n",
+  __func__, asc_clk, baudrate);
+   return;
+   }
+
+   min_difference = UINT_MAX;
+   fdv_over_bg_fpi = baudrate1;
+
+   for (bg = 1; bg <= 8192; bg++, fdv_over_bg_fpi += baudrate1) {
+   fdv_over_bg = fdv_over_bg_fpi + asc_clk / 2;
+   do_div(fdv_over_bg, asc_clk);
+   if (fdv_over_bg <= 512) {
+   difference = fdv_over_bg * asc_clk * 1000;
+   do_div(difference, 8192 * bg);
+   if (difference < baudrate2)
+ 

[PATCH 2/7] clk: intel: Add clock driver for GRX500 SoC

[Songjun Wu]

From: Yixin Zhu 

PLL of GRX500 provide clock to DDR, CPU, and peripherals as show below

 +-+
|--->| LCPLL3 0|--PCIe clk-->
   XO   |+-+
+---|
|+-+
||3|--PAE clk-->
|--->| PLL0B  2|--GSWIP clk-->
||1|--DDR clk-->DDR PHY clk-->
||0|--CPU1 clk--+   +-+
|+-+|--->0|
|   | MUX |--CPU clk-->
|+-+|--->1|
||0|--CPU0 clk--+   +-+
|--->| PLLOA  1|--SSX4 clk-->
 |2|--NGI clk-->
 |3|--CBM clk-->
 +-+

VCO of all PLLs of GRX500 is not supposed to be reprogrammed.
DDR PHY clock is created to show correct clock rate in software
point of view.
CPU clock of 1Ghz from PLL0B otherwise from PLL0A.
Signed-off-by: Yixin Zhu 

Signed-off-by: Songjun Wu 
---

 .../devicetree/bindings/clock/intel,grx500-clk.txt |  46 ++
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/intel/Kconfig  |  21 +
 drivers/clk/intel/Makefile |   7 +
 drivers/clk/intel/clk-cgu-api.c| 676 +
 drivers/clk/intel/clk-cgu-api.h| 120 
 drivers/clk/intel/clk-grx500.c | 236 +++
 include/dt-bindings/clock/intel,grx500-clk.h   |  61 ++
 9 files changed, 1169 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
 create mode 100644 drivers/clk/intel/Kconfig
 create mode 100644 drivers/clk/intel/Makefile
 create mode 100644 drivers/clk/intel/clk-cgu-api.c
 create mode 100644 drivers/clk/intel/clk-cgu-api.h
 create mode 100644 drivers/clk/intel/clk-grx500.c
 create mode 100644 include/dt-bindings/clock/intel,grx500-clk.h

diff --git a/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt 
b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
new file mode 100644
index ..dd761d900dc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
@@ -0,0 +1,46 @@
+Device Tree Clock bindings for GRX500 PLL controller.
+
+This binding uses the common clock binding:
+   Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+This GRX500 PLL controller provides the 5 main clock domain of the SoC: 
CPU/DDR, XBAR,
+Voice, WLAN, PCIe and gate clocks for HW modules.
+
+Required properties for osc clock node
+- compatible: Should be intel,grx500-xxx-clk
+- reg: offset address of the controller memory area.
+- clocks: phandle of the external reference clock
+- #clock-cells: can be one or zero.
+- clock-output-names: Names of the output clocks.
+
+Example:
+   pll0aclk: pll0aclk {
+   #clock-cells = <1>;
+   compatible = "intel,grx500-pll0a-clk";
+   clocks = <&pll0a>;
+   reg = <0x8>;
+   clock-output-names = "cbmclk", "ngiclk", "ssx4clk", "cpu0clk";
+   };
+
+   cpuclk: cpuclk {
+   #clock-cells = <0>;
+   compatible = "intel,grx500-cpu-clk";
+   clocks = <&pll0aclk CPU0_CLK>, <&pll0bclk CPU1_CLK>;
+   reg = <0x8>;
+   clock-output-names = "cpu";
+   };
+
+Required properties for gate node:
+- compatible: Should be intel,grx500-gatex-clk
+- reg: offset address of the controller memory area.
+- #clock-cells: Should be <1>
+- clock-output-names: Names of the output clocks.
+
+Example:
+   clkgate0: clkgate0 {
+   #clock-cells = <1>;
+   compatible = "intel,grx500-gate0-clk";
+   reg = <0x114>;
+   clock-output-names = "gate_xbar0", "gate_xbar1", "gate_xbar2",
+   "gate_xbar3", "gate_xbar6", "gate_xbar7";
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 34968a381d0f..9e2e19a1170a 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -280,6 +280,7 @@ config COMMON_CLK_STM32H7
 source "drivers/clk/bcm/Kconfig"
 source "drivers/clk/hisilicon/Kconfig"
 source "drivers/clk/imgtec/Kconfig"
+source "drivers/clk/intel/Kconfig"
 source "drivers/clk/keystone/Kconfig"
 source "drivers/clk/mediatek/Kconfig"
 source "drivers/clk/meson/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index de6d06ac790b..ef3e270005a1 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -105,3 +105,4 @@ obj-$(CONFIG_X86)   += x86/
 endif
 obj-$(CONFIG_ARCH_ZX)  += zte/
 obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
+obj-$(CONFIG_COMMON_CLK_INTEL) += intel/
diff --git a/drivers/clk/intel/Kconfig b/drivers/clk/intel/Kconfig
new file mode 100644
index ..d40a92ae7462
--- /dev/null
+++ b/drive

[PATCH 0/7] MIPS: intel: add initial support for Intel MIPS SoCs

[Songjun Wu]

This patch series is for adding the support for Intel MIPS interAptiv SoC 
GRX500 family.
It includes CCF support, serial driver optimization and DTS modification.

This patch series is applied on top of v4.17.1. Basic verification is performed 
on GRX500 board.
Any comments on this would be appreciated.

We propose merging this patch series into MIPS Linux tree.


Hua Ma (1):
  MIPS: intel: Add initial support for Intel MIPS SoCs

Songjun Wu (5):
  MIPS: dts: Add aliases node for lantiq danube serial
  tty: serial: lantiq: Always use readl()/writel()
  tty: serial: lantiq: Convert global lock to per device lock
  tty: serial: lantiq: Remove unneeded header includes and macros
  tty: serial: lantiq: Add CCF support

Yixin Zhu (1):
  clk: intel: Add clock driver for GRX500 SoC

 .../devicetree/bindings/clock/intel,grx500-clk.txt |  46 ++
 .../devicetree/bindings/serial/lantiq_asc.txt  |  15 +
 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  37 +-
 arch/mips/boot/dts/Makefile|   1 +
 arch/mips/boot/dts/intel-mips/Makefile |   3 +
 arch/mips/boot/dts/intel-mips/easy350_anywan.dts   |  20 +
 arch/mips/boot/dts/intel-mips/xrx500.dtsi  | 196 ++
 arch/mips/boot/dts/lantiq/danube.dtsi  |   6 +-
 arch/mips/configs/grx500_defconfig | 165 +
 .../asm/mach-intel-mips/cpu-feature-overrides.h|  61 ++
 arch/mips/include/asm/mach-intel-mips/ioremap.h|  39 ++
 arch/mips/include/asm/mach-intel-mips/irq.h|  17 +
 .../asm/mach-intel-mips/kernel-entry-init.h|  76 +++
 arch/mips/include/asm/mach-intel-mips/spaces.h |  29 +
 arch/mips/include/asm/mach-intel-mips/war.h|  18 +
 arch/mips/intel-mips/Kconfig   |  22 +
 arch/mips/intel-mips/Makefile  |   3 +
 arch/mips/intel-mips/Platform  |  11 +
 arch/mips/intel-mips/irq.c |  36 ++
 arch/mips/intel-mips/prom.c| 184 ++
 arch/mips/intel-mips/time.c|  56 ++
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/intel/Kconfig  |  21 +
 drivers/clk/intel/Makefile |   7 +
 drivers/clk/intel/clk-cgu-api.c| 676 +
 drivers/clk/intel/clk-cgu-api.h| 120 
 drivers/clk/intel/clk-grx500.c | 236 +++
 drivers/tty/serial/Kconfig |   2 +-
 drivers/tty/serial/lantiq.c| 415 -
 include/dt-bindings/clock/intel,grx500-clk.h   |  61 ++
 32 files changed, 2418 insertions(+), 164 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
 create mode 100644 arch/mips/boot/dts/intel-mips/Makefile
 create mode 100644 arch/mips/boot/dts/intel-mips/easy350_anywan.dts
 create mode 100644 arch/mips/boot/dts/intel-mips/xrx500.dtsi
 create mode 100644 arch/mips/configs/grx500_defconfig
 create mode 100644 
arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h
 create mode 100644 arch/mips/include/asm/mach-intel-mips/ioremap.h
 create mode 100644 arch/mips/include/asm/mach-intel-mips/irq.h
 create mode 100644 arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h
 create mode 100644 arch/mips/include/asm/mach-intel-mips/spaces.h
 create mode 100644 arch/mips/include/asm/mach-intel-mips/war.h
 create mode 100644 arch/mips/intel-mips/Kconfig
 create mode 100644 arch/mips/intel-mips/Makefile
 create mode 100644 arch/mips/intel-mips/Platform
 create mode 100644 arch/mips/intel-mips/irq.c
 create mode 100644 arch/mips/intel-mips/prom.c
 create mode 100644 arch/mips/intel-mips/time.c
 create mode 100644 drivers/clk/intel/Kconfig
 create mode 100644 drivers/clk/intel/Makefile
 create mode 100644 drivers/clk/intel/clk-cgu-api.c
 create mode 100644 drivers/clk/intel/clk-cgu-api.h
 create mode 100644 drivers/clk/intel/clk-grx500.c
 create mode 100644 include/dt-bindings/clock/intel,grx500-clk.h

-- 
2.11.0

Re: [PATCH v3 5/7] dt-bindings: power: Add qcom rpmh power domain driver bindings

[Bjorn Andersson]

On Mon 11 Jun 21:40 PDT 2018, Rajendra Nayak wrote:

> Add DT bindings to describe the rpmh powerdomains found on Qualcomm
> Technologies, Inc. SoCs. These power domains communicate a performance
> state to RPMh, which then translates it into corresponding voltage on
> a PMIC rail.
> 
> Signed-off-by: Rajendra Nayak 
> ---
>  .../devicetree/bindings/power/qcom,rpmhpd.txt | 65 +++
>  1 file changed, 65 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt 
> b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
> new file mode 100644
> index ..41ef7afa6b24
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
> @@ -0,0 +1,65 @@
> +Qualcomm RPMh Power domains
> +
> +For RPMh Power domains, we communicate a performance state to RPMh
> +which then translates it into a corresponding voltage on a rail
> +
> +Required Properties:
> + - compatible: Should be one of the following
> + * qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC

Afaict this binding is identical to the one introduced in patch 1, so I
would suggest that you just add the compatible there.

Regards,
Bjorn

> + - power-domain-cells: number of cells in power domain specifier
> + must be 1
> + - operating-points-v2: Phandle to the OPP table for the power-domain.
> + Refer to Documentation/devicetree/bindings/power/power_domain.txt
> + and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
> +
> +Example:
> +
> + rpmhpd: power-controller {
> + compatible = "qcom,sdm845-rpmhpd";
> + #power-domain-cells = <1>;
> + operating-points-v2 = <&rpmhpd_opp_table>;
> + };
> +
> + rpmhpd_opp_table: opp-table {
> + compatible = "operating-points-v2-qcom-level";
> +
> + rpmhpd_opp_ret: opp1 {
> + qcom-level = <16>;
> + };
> +
> + rpmhpd_opp_min_svs: opp2 {
> + qcom-level = <48>;
> + };
> +
> + rpmhpd_opp_low_svs: opp3 {
> + qcom-level = <64>;
> + };
> +
> + rpmhpd_opp_svs: opp4 {
> + qcom-level = <128>;
> + };
> +
> + rpmhpd_opp_svs_l1: opp5 {
> + qcom-level = <192>;
> + };
> +
> + rpmhpd_opp_nom: opp6 {
> + qcom-level = <256>;
> + };
> +
> + rpmhpd_opp_nom_l1: opp7 {
> + qcom-level = <320>;
> + };
> +
> + rpmhpd_opp_nom_l2: opp8 {
> + qcom-level = <336>;
> + };
> +
> + rpmhpd_opp_turbo: opp9 {
> + qcom-level = <384>;
> + };
> +
> + rpmhpd_opp_turbo_l1: opp10 {
> + qcom-level = <416>;
> + };
> + };
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 

Re: [PATCH] fanotify: add error handling for kmem_cache_create

[Amir Goldstein]

On Tue, Jun 12, 2018 at 7:19 AM, Zhouyang Jia  wrote:
> When kmem_cache_create fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling kmem_cache_create.
>
> Signed-off-by: Zhouyang Jia 
> ---
>  fs/notify/fanotify/fanotify_user.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/fs/notify/fanotify/fanotify_user.c 
> b/fs/notify/fanotify/fanotify_user.c
> index ec4d8c5..e3fa861 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -959,9 +959,14 @@ static int __init fanotify_user_setup(void)
>  {
> fanotify_mark_cache = KMEM_CACHE(fsnotify_mark, SLAB_PANIC);
> fanotify_event_cachep = KMEM_CACHE(fanotify_event_info, SLAB_PANIC);
> +   if (!fanotify_mark_cache || !fanotify_event_cachep)
> +   return -ENOMEM;

If only one failed need to free the other.

> +
> if (IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS)) {
> fanotify_perm_event_cachep =
> KMEM_CACHE(fanotify_perm_event_info, SLAB_PANIC);
> +   if (!fanotify_perm_event_cachep)
> +   return -ENOMEM;

here as well.
best implement as goto fail

> }
>
> return 0;

fail:
   if (fanotify_mark_cache)
kmem_cache_destroy(fanotify_mark_cache);
   ...
   return -ENOMEM;

Thanks,
Amir.

RE: [PATCH] Input: add error handling for da9052_reg_write

[Steve Twiss]

On 11 June 2018 18:30 wrote Dmitry Torokhov 

> Subject: Re: [PATCH] Input: add error handling for da9052_reg_write
> 
> Hi Zhouyang,
> 
> On Mon, Jun 11, 2018 at 01:23:39PM +0800, Zhouyang Jia wrote:
> > When da9052_reg_write fails, the lack of error-handling code may
> > cause unexpected results.
> >
> > This patch adds error-handling code after calling da9052_reg_write.
> >
> > Signed-off-by: Zhouyang Jia 
> > ---
> >  drivers/input/touchscreen/da9052_tsi.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/touchscreen/da9052_tsi.c
> b/drivers/input/touchscreen/da9052_tsi.c
> > index b5dfd594..60c82a0 100644
> > --- a/drivers/input/touchscreen/da9052_tsi.c
> > +++ b/drivers/input/touchscreen/da9052_tsi.c
> > @@ -319,8 +319,11 @@ static int da9052_ts_probe(struct platform_device 
> > *pdev)
> >  static int  da9052_ts_remove(struct platform_device *pdev)
> >  {
> > struct da9052_tsi *tsi = platform_get_drvdata(pdev);
> > +   int error;
> >
> > -   da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x19);
> > +   error = da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x19);
> > +   if (error < 0)
> > +   return error;
> 
> No, this does not help anything. The remove() action must not fail
> (really, having it return an int and not void was an API mistake made
> long time ago), and thus returning early in and event of error failing
> to communicate with the device is a mistake. You really want to release
> the interrupts and memory and unregister input device before returning.
> 
> >
> > da9052_free_irq(tsi->da9052, DA9052_IRQ_TSIREADY, tsi);
> > da9052_free_irq(tsi->da9052, DA9052_IRQ_PENDOWN, tsi);
> > --
> > 2.7.4
> >

script?
https://patchwork.kernel.org/project/LKML/list/?submitter=181001

Re: [PATCH] fsnotify: add error handling for kmem_cache_create

[Amir Goldstein]

On Tue, Jun 12, 2018 at 7:16 AM, Zhouyang Jia  wrote:
> When kmem_cache_create fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling kmem_cache_create.
>
> Signed-off-by: Zhouyang Jia 
> ---
>  fs/notify/dnotify/dnotify.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/fs/notify/dnotify/dnotify.c b/fs/notify/dnotify/dnotify.c
> index 63a1ca4..216b411 100644
> --- a/fs/notify/dnotify/dnotify.c
> +++ b/fs/notify/dnotify/dnotify.c
> @@ -387,6 +387,9 @@ static int __init dnotify_init(void)
> dnotify_struct_cache = KMEM_CACHE(dnotify_struct, SLAB_PANIC);
> dnotify_mark_cache = KMEM_CACHE(dnotify_mark, SLAB_PANIC);
>
> +   if (!dnotify_struct_cache || !dnotify_mark_cache)
> +   return -ENOMEM;
> +

If only one failed need to free the other.

> dnotify_group = fsnotify_alloc_group(&dnotify_fsnotify_ops);
> if (IS_ERR(dnotify_group))
> panic("unable to allocate fsnotify group for dnotify\n");
> --
> 2.7.4
>

[PATCH v2 2/2] gpio: davinci: Do not assume continuous IRQ numbering

[Keerthy]

Currently the driver assumes that the interrupts are continuous
and does platform_get_irq only once and assumes the rest are continuous,
instead call platform_get_irq for all the interrupts and store them
in an array for later use.

Signed-off-by: Keerthy 
---

Tested for GPIO Interrupts on da850-lcdk and keystone-k2g-evm boards.

Changes in v2:

  * Extended the logic of using saved IRQs to unbanked IRQs
as per Grygorii's suggestion.

 drivers/gpio/gpio-davinci.c| 53 +++---
 include/linux/platform_data/gpio-davinci.h |  3 +-
 2 files changed, 36 insertions(+), 20 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 861f35b..b2119c0 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -55,7 +55,7 @@ static inline struct davinci_gpio_regs __iomem 
*irq2regs(struct irq_data *d)
return g;
 }
 
-static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq);
+static int davinci_gpio_irq_setup(struct platform_device *pdev);
 
 /*--*/
 
@@ -168,7 +168,8 @@ static int davinci_gpio_probe(struct platform_device *pdev)
 {
static int ctrl_num, bank_base;
int gpio, bank, ret = 0;
-   unsigned ngpio, nbank, bank_irq;
+   unsigned int ngpio, nbank, nirq;
+   int i;
struct davinci_gpio_controller *chips;
struct davinci_gpio_platform_data *pdata;
struct device *dev = &pdev->dev;
@@ -197,6 +198,16 @@ static int davinci_gpio_probe(struct platform_device *pdev)
if (WARN_ON(ARCH_NR_GPIOS < ngpio))
ngpio = ARCH_NR_GPIOS;
 
+   /*
+* If there are unbanked interrupts then the number of
+* interrupts is equal to number of gpios else all are banked so
+* number of interrupts is equal to number of banks(each with 16 gpios)
+*/
+   if (pdata->gpio_unbanked)
+   nirq = pdata->gpio_unbanked;
+   else
+   nirq = DIV_ROUND_UP(ngpio, 16);
+
nbank = DIV_ROUND_UP(ngpio, 32);
chips = devm_kzalloc(dev,
 nbank * sizeof(struct davinci_gpio_controller),
@@ -209,10 +220,13 @@ static int davinci_gpio_probe(struct platform_device 
*pdev)
if (IS_ERR(gpio_base))
return PTR_ERR(gpio_base);
 
-   bank_irq = platform_get_irq(pdev, 0);
-   if (bank_irq < 0) {
-   dev_dbg(dev, "IRQ not populated\n");
-   return bank_irq;
+   for (i = 0; i < nirq; i++) {
+   chips->irqs[i] = platform_get_irq(pdev, i);
+   if (chips->irqs[i] < 0) {
+   dev_info(dev, "IRQ not populated, err = %d\n",
+chips->irqs[i]);
+   return chips->irqs[i];
+   }
}
 
snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
@@ -249,7 +263,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
goto err;
 
platform_set_drvdata(pdev, chips);
-   ret = davinci_gpio_irq_setup(pdev, bank_irq);
+   ret = davinci_gpio_irq_setup(pdev);
if (ret)
goto err;
 
@@ -383,7 +397,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, 
unsigned offset)
 * can provide direct-mapped IRQs to AINTC (up to 32 GPIOs).
 */
if (offset < d->gpio_unbanked)
-   return d->base_irq + offset;
+   return d->irqs[offset];
else
return -ENODEV;
 }
@@ -396,7 +410,7 @@ static int gpio_irq_type_unbanked(struct irq_data *data, 
unsigned trigger)
 
d = (struct davinci_gpio_controller 
*)irq_data_get_irq_handler_data(data);
g = (struct davinci_gpio_regs __iomem *)d->regs[0];
-   mask = __gpio_mask(data->irq - d->base_irq);
+   mask = __gpio_mask(data->irq - d->irqs[0]);
 
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
@@ -458,7 +472,7 @@ static struct irq_chip *keystone_gpio_get_irq_chip(unsigned 
int irq)
  * (dm6446) can be set appropriately for GPIOV33 pins.
  */
 
-static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq)
+static int davinci_gpio_irq_setup(struct platform_device *pdev)
 {
unsignedgpio, bank;
int irq;
@@ -492,6 +506,7 @@ static int davinci_gpio_irq_setup(struct platform_device 
*pdev, int bank_irq)
dev_err(dev, "Error %ld getting gpio clock\n", PTR_ERR(clk));
return PTR_ERR(clk);
}
+
ret = clk_prepare_enable(clk);
if (ret)
return ret;
@@ -531,12 +546,11 @@ static int davinci_gpio_irq_setup(struct platform_device 
*pdev, int bank_irq)
if (pdata->gpio_unbanked) {
/* pass "bank 0" GPIO IRQs to AINTC */
chips->chip.to_irq = gpio_to_irq_unbanked;
-  

[PATCH v2 1/2] gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe

[Keerthy]

This is needed in case of PROBE_DEFER if IRQ resource is not yet ready.

Signed-off-by: Keerthy 
---

Tested for GPIO Interrupts on da850-lcdk and keystone-k2g-evm boards.

No Changes in v2

 drivers/gpio/gpio-davinci.c | 29 +++--
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 987126c..861f35b 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -55,7 +55,7 @@ static inline struct davinci_gpio_regs __iomem 
*irq2regs(struct irq_data *d)
return g;
 }
 
-static int davinci_gpio_irq_setup(struct platform_device *pdev);
+static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq);
 
 /*--*/
 
@@ -168,7 +168,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
 {
static int ctrl_num, bank_base;
int gpio, bank, ret = 0;
-   unsigned ngpio, nbank;
+   unsigned ngpio, nbank, bank_irq;
struct davinci_gpio_controller *chips;
struct davinci_gpio_platform_data *pdata;
struct device *dev = &pdev->dev;
@@ -209,6 +209,12 @@ static int davinci_gpio_probe(struct platform_device *pdev)
if (IS_ERR(gpio_base))
return PTR_ERR(gpio_base);
 
+   bank_irq = platform_get_irq(pdev, 0);
+   if (bank_irq < 0) {
+   dev_dbg(dev, "IRQ not populated\n");
+   return bank_irq;
+   }
+
snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
chips->chip.label = devm_kstrdup(dev, label, GFP_KERNEL);
if (!chips->chip.label)
@@ -243,7 +249,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
goto err;
 
platform_set_drvdata(pdev, chips);
-   ret = davinci_gpio_irq_setup(pdev);
+   ret = davinci_gpio_irq_setup(pdev, bank_irq);
if (ret)
goto err;
 
@@ -452,16 +458,15 @@ static struct irq_chip 
*keystone_gpio_get_irq_chip(unsigned int irq)
  * (dm6446) can be set appropriately for GPIOV33 pins.
  */
 
-static int davinci_gpio_irq_setup(struct platform_device *pdev)
+static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq)
 {
unsignedgpio, bank;
int irq;
int ret;
struct clk  *clk;
u32 binten = 0;
-   unsignedngpio, bank_irq;
+   unsignedngpio;
struct device *dev = &pdev->dev;
-   struct resource *res;
struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
struct davinci_gpio_platform_data *pdata = dev->platform_data;
struct davinci_gpio_regs __iomem *g;
@@ -481,18 +486,6 @@ static int davinci_gpio_irq_setup(struct platform_device 
*pdev)
gpio_get_irq_chip = (gpio_get_irq_chip_cb_t)match->data;
 
ngpio = pdata->ngpio;
-   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-   if (!res) {
-   dev_err(dev, "Invalid IRQ resource\n");
-   return -EBUSY;
-   }
-
-   bank_irq = res->start;
-
-   if (!bank_irq) {
-   dev_err(dev, "Invalid IRQ resource\n");
-   return -ENODEV;
-   }
 
clk = devm_clk_get(dev, "gpio");
if (IS_ERR(clk)) {
-- 
1.9.1

Re: [PATCH 2/2] nvmem: Add Spreadtrum SC27XX efuse support

[Randy Dunlap]

On 06/11/2018 10:24 PM, Baolin Wang wrote:
> From: Freeman Liu 
> 
> This patch add the efuse driver which is embeded in Spreadtrum SC27XX
> series PMICs. The sc27xx efuse contains 32 blocks and each block's
> data width is 16 bits.
> 
> Signed-off-by: Freeman Liu 
> Signed-off-by: Baolin Wang 
> ---
>  drivers/nvmem/Kconfig|   11 ++
>  drivers/nvmem/Makefile   |3 +-
>  drivers/nvmem/sc27xx-efuse.c |  263 
> ++
>  3 files changed, 276 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/nvmem/sc27xx-efuse.c
> 
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index 54a3c29..3dca608 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -181,4 +181,15 @@ config RAVE_SP_EEPROM
>   help
> Say y here to enable Rave SP EEPROM support.
>  
> +config SC27XX_EFUSE
> + tristate "Spreadtrum SC27XX eFuse Support"
> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
> + depends on HAS_IOMEM
> + help
> +   This is a simple drive to dump specified values of Spreadtrum

   driver

> +   SC27XX PMICs from eFuse.
> +
> +   This driver can also be built as a module. If so, the module
> +   will be called nvmem-sc27xx-efuse.
> +
>  endif


-- 
~Randy

Re: [PATCH] staging: lustre: add error handling for try_module_get

[NeilBrown]

On Tue, Jun 12 2018, Zhouyang Jia wrote:

> When try_module_get fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling try_module_get.
>
> Signed-off-by: Zhouyang Jia 
> ---
>  drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c 
> b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
> index 7086678..72a42bd 100644
> --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
> +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
> @@ -2422,7 +2422,10 @@ ksocknal_base_startup(void)
>  
>   /* flag lists/ptrs/locks initialised */
>   ksocknal_data.ksnd_init = SOCKNAL_INIT_DATA;
> - try_module_get(THIS_MODULE);
> + if (!try_module_get(THIS_MODULE)) {
> + CERROR("%s: cannot get module\n", __func__);
> + goto failed;
> + }
>  
>   ksocknal_data.ksnd_sched_info = cfs_percpt_alloc(lnet_cpt_table(),
>sizeof(*info));

Thanks for the patch
I agree that this is probably a bug, but the code is still buggy after
you patch, just in a different way.
Try following through the code and see what happens when you 'goto
failed'.

NeilBrown




signature.asc
Description: PGP signature

[PATCH 2/2] nvmem: Add Spreadtrum SC27XX efuse support

[Baolin Wang]

From: Freeman Liu 

This patch add the efuse driver which is embeded in Spreadtrum SC27XX
series PMICs. The sc27xx efuse contains 32 blocks and each block's
data width is 16 bits.

Signed-off-by: Freeman Liu 
Signed-off-by: Baolin Wang 
---
 drivers/nvmem/Kconfig|   11 ++
 drivers/nvmem/Makefile   |3 +-
 drivers/nvmem/sc27xx-efuse.c |  263 ++
 3 files changed, 276 insertions(+), 1 deletion(-)
 create mode 100644 drivers/nvmem/sc27xx-efuse.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 54a3c29..3dca608 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -181,4 +181,15 @@ config RAVE_SP_EEPROM
help
  Say y here to enable Rave SP EEPROM support.
 
+config SC27XX_EFUSE
+   tristate "Spreadtrum SC27XX eFuse Support"
+   depends on MFD_SC27XX_PMIC || COMPILE_TEST
+   depends on HAS_IOMEM
+   help
+ This is a simple drive to dump specified values of Spreadtrum
+ SC27XX PMICs from eFuse.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-sc27xx-efuse.
+
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 27e96a8..4e8c616 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -39,4 +39,5 @@ obj-$(CONFIG_NVMEM_SNVS_LPGPR)+= nvmem_snvs_lpgpr.o
 nvmem_snvs_lpgpr-y := snvs_lpgpr.o
 obj-$(CONFIG_RAVE_SP_EEPROM)   += nvmem-rave-sp-eeprom.o
 nvmem-rave-sp-eeprom-y := rave-sp-eeprom.o
-
+obj-$(CONFIG_SC27XX_EFUSE) += nvmem-sc27xx-efuse.o
+nvmem-sc27xx-efuse-y   := sc27xx-efuse.o
diff --git a/drivers/nvmem/sc27xx-efuse.c b/drivers/nvmem/sc27xx-efuse.c
new file mode 100644
index 000..07c210c
--- /dev/null
+++ b/drivers/nvmem/sc27xx-efuse.c
@@ -0,0 +1,263 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Spreadtrum Communications Inc.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PMIC global registers definition */
+#define SC27XX_MODULE_EN   0xc08
+#define SC27XX_EFUSE_ENBIT(6)
+
+/* Efuse controller registers definition */
+#define SC27XX_EFUSE_GLB_CTRL  0x0
+#define SC27XX_EFUSE_DATA_RD   0x4
+#define SC27XX_EFUSE_DATA_WR   0x8
+#define SC27XX_EFUSE_BLOCK_INDEX   0xc
+#define SC27XX_EFUSE_MODE_CTRL 0x10
+#define SC27XX_EFUSE_STATUS0x14
+#define SC27XX_EFUSE_WR_TIMING_CTRL0x20
+#define SC27XX_EFUSE_RD_TIMING_CTRL0x24
+#define SC27XX_EFUSE_EFUSE_DEB_CTRL0x28
+
+/* Mask definition for SC27XX_EFUSE_BLOCK_INDEX register */
+#define SC27XX_EFUSE_BLOCK_MASKGENMASK(4, 0)
+
+/* Bits definitions for SC27XX_EFUSE_MODE_CTRL register */
+#define SC27XX_EFUSE_PG_START  BIT(0)
+#define SC27XX_EFUSE_RD_START  BIT(1)
+#define SC27XX_EFUSE_CLR_RDDONEBIT(2)
+
+/* Bits definitions for SC27XX_EFUSE_STATUS register */
+#define SC27XX_EFUSE_PGM_BUSY  BIT(0)
+#define SC27XX_EFUSE_READ_BUSY BIT(1)
+#define SC27XX_EFUSE_STANDBY   BIT(2)
+#define SC27XX_EFUSE_GLOBAL_PROT   BIT(3)
+#define SC27XX_EFUSE_RD_DONE   BIT(4)
+
+/* Block number and block width (bytes) definitions */
+#define SC27XX_EFUSE_BLOCK_MAX 32
+#define SC27XX_EFUSE_BLOCK_WIDTH   2
+
+/* Timeout (ms) for the trylock of hardware spinlocks */
+#define SC27XX_EFUSE_HWLOCK_TIMEOUT5000
+
+/* Timeout (us) of polling the status */
+#define SC27XX_EFUSE_POLL_TIMEOUT  300
+#define SC27XX_EFUSE_POLL_DELAY_US 1
+
+struct sc27xx_efuse {
+   struct device *dev;
+   struct regmap *regmap;
+   struct hwspinlock *hwlock;
+   struct mutex mutex;
+   u32 base;
+};
+
+/*
+ * On Spreadtrum platform, we have multi-subsystems will access the unique
+ * efuse controller, so we need one hardware spinlock to synchronize between
+ * the multiple subsystems.
+ */
+static int sc27xx_efuse_lock(struct sc27xx_efuse *efuse)
+{
+   int ret;
+
+   mutex_lock(&efuse->mutex);
+
+   ret = hwspin_lock_timeout_raw(efuse->hwlock,
+ SC27XX_EFUSE_HWLOCK_TIMEOUT);
+   if (ret) {
+   dev_err(efuse->dev, "timeout to get the hwspinlock\n");
+   mutex_unlock(&efuse->mutex);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void sc27xx_efuse_unlock(struct sc27xx_efuse *efuse)
+{
+   hwspin_unlock_raw(efuse->hwlock);
+   mutex_unlock(&efuse->mutex);
+}
+
+static int sc27xx_efuse_poll_status(struct sc27xx_efuse *efuse, u32 bits)
+{
+   int ret;
+   u32 val;
+
+   ret = regmap_read_poll_timeout(efuse->regmap,
+  efuse->base + SC27XX_EFUSE_STATUS,
+  val, (val & bits),
+  SC27XX_EFUSE_POLL_DELAY_US,
+  SC27XX_EFUSE_POLL_TIMEOUT);
+   if (ret

[PATCH 1/2] dt-bindings: nvmem: Add Spreadtrum SC27XX efuse controller documentation

[Baolin Wang]

This patch adds the binding documentation for Spreadtrum SC27XX series
PMICs efuse controller device.

Signed-off-by: Baolin Wang 
---
 .../devicetree/bindings/nvmem/sc27xx-efuse.txt |   52 
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt

diff --git a/Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt 
b/Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt
new file mode 100644
index 000..586c082
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt
@@ -0,0 +1,52 @@
+= Spreadtrum SC27XX PMIC eFuse device tree bindings =
+
+Required properties:
+- compatible: Should be one of the following.
+   "sprd,sc2720-efuse"
+   "sprd,sc2721-efuse"
+   "sprd,sc2723-efuse"
+   "sprd,sc2730-efuse"
+   "sprd,sc2731-efuse"
+- reg: Specify the address offset of efuse controller.
+- hwlocks: Reference to a phandle of a hwlock provider node.
+
+= Data cells =
+Are child nodes of eFuse, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+   sc2731_pmic: pmic@0 {
+   compatible = "sprd,sc2731";
+   reg = <0>;
+   spi-max-frequency = <2600>;
+   interrupts = ;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   efuse@380 {
+   compatible = "sprd,sc2731-efuse";
+   reg = <0x380>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   hwlocks = <&hwlock 12>;
+
+   /* Data cells */
+   thermal_calib: calib@10 {
+   reg = <0x10 0x2>;
+   };
+   };
+   };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+Example:
+
+   thermal {
+   ...
+   nvmem-cells = <&thermal_calib>;
+   nvmem-cell-names = "calibration";
+   };
-- 
1.7.9.5

Re: [PATCH 1/2] arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes

[Doug Anderson]

Hi,

On Mon, Jun 11, 2018 at 10:01 PM, Bjorn Andersson
 wrote:
> On Thu 07 Jun 13:46 PDT 2018, Douglas Anderson wrote:
>
>> This adds nodes to SDM845-dtsi for all the I2C ports, all the SPI
>> ports, and UART9.  Note that I2C / SPI / UART are a bit strange on
>> sdm845 because each "serial engine" has 4 pins associated with it and
>> depending on which firmware has been loaded into the serial engine
>> (loaded by the BIOS) the serial engine can behave like an I2C port, a
>> SPI port, or a UART.  As per the landed bindings that means that we
>> need to create one node for each possible mode that the port could be
>> in.  With 16 serial engines that means 16 x 3 = 48 nodes.
>>
>> We get away with only creating 33 nodes for now because it seems very
>> likely that SDM845-based boards will actually all use the same UART
>> (UART 9) for debug purposes.  While another UART could be used for
>> something like Bluetooth communication we can cross that path when we
>> come to it.  Some documentation that I saw implied that using a UART
>> for "high speed" communications actually needs yet another different
>> serial engine firmware anyway.
>>
>> Note that quick measurements adding all these nodes adds ~10k of extra
>> space per dtb that they're included with.  If this becomes a problem
>> we may need to think of a different way to structure this so that
>> boards only get the nodes they need (or figure out how to get dtc to
>> strip 'disabled' nodes).  For now it seems OK.
>>
>> These nodes were programmatically generated with a fairly dumb python
>> script.  See http://crosreview.com/1091631 for the source.
>>
>> Signed-off-by: Douglas Anderson 
>
> Reviewed-by: Bjorn Andersson 

Thanks for the review!

One note is that I have since come to find that it might not be so
wise to define the sleep pinctrl state here.  For the SPI driver at
least I dug in and I saw the the sleep state is selected when we're
runtime PMed.  ...and with the currently posted SPI driver that can
happen in some cases even when the chip select is supposed to be kept
low.  For now it's more prudent to keep the "sleep" state out of the
device tree and we can always add it in later.

I'll plan to re-spin the patch on Wednesday (I'm unavailable tomorrow).

For other's reference: I chatted offline with Bjorn offline and this
sounded fine to him.


-Doug

Re: [PATCH] proc: add error handling for kmem_cache_create

[kbuild test robot]

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/linux-kernel-owner-vger-kernel-org/proc-add-error-handling-for-kmem_cache_create/20180612-122737
config: i386-randconfig-x012-201823 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   fs/proc/inode.c: In function 'proc_init_kmemcache':
>> fs/proc/inode.c:108:10: warning: 'return' with a value, in function 
>> returning void
  return -ENOMEM;
 ^
   fs/proc/inode.c:96:13: note: declared here
void __init proc_init_kmemcache(void)
^~~

vim +/return +108 fs/proc/inode.c

95  
96  void __init proc_init_kmemcache(void)
97  {
98  proc_inode_cachep = kmem_cache_create("proc_inode_cache",
99   sizeof(struct proc_inode),
   100   0, (SLAB_RECLAIM_ACCOUNT|
   101  
SLAB_MEM_SPREAD|SLAB_ACCOUNT|
   102  SLAB_PANIC),
   103   init_once);
   104  pde_opener_cache =
   105  kmem_cache_create("pde_opener", sizeof(struct 
pde_opener), 0,
   106SLAB_ACCOUNT|SLAB_PANIC, NULL);
   107  if (!proc_inode_cachep || !pde_opener_cache)
 > 108  return -ENOMEM;
   109  
   110  proc_dir_entry_cache = kmem_cache_create_usercopy(
   111  "proc_dir_entry", sizeof(struct proc_dir_entry), 0, 
SLAB_PANIC,
   112  offsetof(struct proc_dir_entry, inline_name),
   113  sizeof_field(struct proc_dir_entry, inline_name), NULL);
   114  }
   115  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[RFC PATCH 2/5] fsi/scom: Whitespace fixes

[Benjamin Herrenschmidt]

No functional changes

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/fsi/fsi-scom.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index 3cba0eb645e1..8a608db0aa07 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -49,7 +49,7 @@ static struct list_head scom_devices;
 static DEFINE_IDA(scom_ida);
 
 static int put_scom(struct scom_device *scom_dev, uint64_t value,
-   uint32_t addr)
+   uint32_t addr)
 {
int rc;
uint32_t data;
@@ -77,7 +77,7 @@ static int put_scom(struct scom_device *scom_dev, uint64_t 
value,
 }
 
 static int get_scom(struct scom_device *scom_dev, uint64_t *value,
-   uint32_t addr)
+   uint32_t addr)
 {
uint32_t result, data;
int rc;
@@ -110,7 +110,7 @@ static int get_scom(struct scom_device *scom_dev, uint64_t 
*value,
 }
 
 static ssize_t scom_read(struct file *filep, char __user *buf, size_t len,
-   loff_t *offset)
+loff_t *offset)
 {
int rc;
struct miscdevice *mdev =
@@ -136,7 +136,7 @@ static ssize_t scom_read(struct file *filep, char __user 
*buf, size_t len,
 }
 
 static ssize_t scom_write(struct file *filep, const char __user *buf,
-   size_t len, loff_t *offset)
+ size_t len, loff_t *offset)
 {
int rc;
struct miscdevice *mdev = filep->private_data;
-- 
2.17.0

[RFC PATCH 3/5] fsi/scom: Fixup endian annotations

[Benjamin Herrenschmidt]

Use the proper annotated type __be32 and fixup the
accessor used for get_scom()

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/fsi/fsi-scom.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index 8a608db0aa07..6ddfb6021420 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -51,8 +51,8 @@ static DEFINE_IDA(scom_ida);
 static int put_scom(struct scom_device *scom_dev, uint64_t value,
uint32_t addr)
 {
+   __be32 data;
int rc;
-   uint32_t data;
 
mutex_lock(&scom_dev->lock);
 
@@ -79,7 +79,7 @@ static int put_scom(struct scom_device *scom_dev, uint64_t 
value,
 static int get_scom(struct scom_device *scom_dev, uint64_t *value,
uint32_t addr)
 {
-   uint32_t result, data;
+   __be32 result, data;
int rc;
 
 
@@ -96,14 +96,13 @@ static int get_scom(struct scom_device *scom_dev, uint64_t 
*value,
if (rc)
goto bail;
 
-   *value |= (uint64_t)cpu_to_be32(result) << 32;
+   *value |= (uint64_t)be32_to_cpu(result) << 32;
rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA1_REG, &result,
sizeof(uint32_t));
if (rc)
goto bail;
 
-   *value |= cpu_to_be32(result);
-
+   *value |= be32_to_cpu(result);
  bail:
mutex_unlock(&scom_dev->lock);
return rc;
-- 
2.17.0

[RFC PATCH 4/5] fsi/scom: Add register definitions

[Benjamin Herrenschmidt]

Add a few more register and bit definitions, also define and use
SCOM_READ_CMD (which is 0 but it makes the code clearer)

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/fsi/fsi-scom.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index 6ddfb6021420..e98573ecdae1 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -30,8 +30,25 @@
 #define SCOM_DATA0_REG 0x00
 #define SCOM_DATA1_REG 0x04
 #define SCOM_CMD_REG   0x08
+#define SCOM_FSI2PIB_RESET_REG 0x18
+#define SCOM_STATUS_REG0x1C /* Read */
+#define SCOM_PIB_RESET_REG 0x1C /* Write */
 
+/* Command register */
 #define SCOM_WRITE_CMD 0x8000
+#define SCOM_READ_CMD  0x
+
+/* Status register bits */
+#define SCOM_STATUS_ERR_SUMMARY0x8000
+#define SCOM_STATUS_PROTECTION 0x0100
+#define SCOM_STATUS_PIB_ABORT  0x0010
+#define SCOM_STATUS_PIB_RESP_MASK  0x7000
+#define SCOM_STATUS_PIB_RESP_SHIFT 12
+
+#define SCOM_STATUS_ANY_ERR(SCOM_STATUS_ERR_SUMMARY | \
+SCOM_STATUS_PROTECTION | \
+SCOM_STATUS_PIB_ABORT | \
+SCOM_STATUS_PIB_RESP_MASK)
 
 struct scom_device {
struct list_head link;
@@ -85,7 +102,7 @@ static int get_scom(struct scom_device *scom_dev, uint64_t 
*value,
 
mutex_lock(&scom_dev->lock);
*value = 0ULL;
-   data = cpu_to_be32(addr);
+   data = cpu_to_be32(SCOM_READ_CMD | addr);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
sizeof(uint32_t));
if (rc)
-- 
2.17.0

[RFC PATCH 5/5] fsi/scom: Major overhaul

[Benjamin Herrenschmidt]

This was too hard to split ... this adds a number of features
to the SCOM user interface:

 - Support for indirect SCOMs

 - read()/write() interface now handle errors and retries

 - New ioctl() "raw" interface for use by debuggers

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/fsi/fsi-scom.c   | 424 ---
 include/uapi/linux/fsi.h |  56 ++
 2 files changed, 450 insertions(+), 30 deletions(-)
 create mode 100644 include/uapi/linux/fsi.h

diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index e98573ecdae1..39c74351f1bf 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 
+#include 
+
 #define FSI_ENGID_SCOM 0x5
 
 /* SCOM engine register set */
@@ -41,14 +43,36 @@
 /* Status register bits */
 #define SCOM_STATUS_ERR_SUMMARY0x8000
 #define SCOM_STATUS_PROTECTION 0x0100
+#define SCOM_STATUS_PARITY 0x0400
 #define SCOM_STATUS_PIB_ABORT  0x0010
 #define SCOM_STATUS_PIB_RESP_MASK  0x7000
 #define SCOM_STATUS_PIB_RESP_SHIFT 12
 
 #define SCOM_STATUS_ANY_ERR(SCOM_STATUS_ERR_SUMMARY | \
 SCOM_STATUS_PROTECTION | \
+SCOM_STATUS_PARITY | \
 SCOM_STATUS_PIB_ABORT | \
 SCOM_STATUS_PIB_RESP_MASK)
+/* SCOM address encodings */
+#define XSCOM_ADDR_IND_FLAGBIT_ULL(63)
+#define XSCOM_ADDR_INF_FORM1   BIT_ULL(60)
+
+/* SCOM indirect stuff */
+#define XSCOM_ADDR_DIRECT_PART 0x7fffull
+#define XSCOM_ADDR_INDIRECT_PART   0x000full
+#define XSCOM_DATA_IND_READBIT_ULL(63)
+#define XSCOM_DATA_IND_COMPLETEBIT_ULL(31)
+#define XSCOM_DATA_IND_ERR_MASK0x7000ull
+#define XSCOM_DATA_IND_ERR_SHIFT   28
+#define XSCOM_DATA_IND_DATA0xull
+#define XSCOM_DATA_IND_FORM1_DATA  0x000full
+#define XSCOM_ADDR_FORM1_LOW   0x000ull
+#define XSCOM_ADDR_FORM1_HI0xfffull
+#define XSCOM_ADDR_FORM1_HI_SHIFT  20
+
+/* Retries */
+#define SCOM_MAX_RETRIES   100 /* Retries on busy */
+#define SCOM_MAX_IND_RETRIES   10  /* Retries indirect not ready */
 
 struct scom_device {
struct list_head link;
@@ -56,7 +80,7 @@ struct scom_device {
struct miscdevice mdev;
struct mutex lock;
charname[32];
-   int idx;
+   int idx;
 };
 
 #define to_scom_dev(x) container_of((x), struct scom_device, mdev)
@@ -65,80 +89,304 @@ static struct list_head scom_devices;
 
 static DEFINE_IDA(scom_ida);
 
-static int put_scom(struct scom_device *scom_dev, uint64_t value,
-   uint32_t addr)
+static int __put_scom(struct scom_device *scom_dev, uint64_t value,
+ uint32_t addr, uint32_t *status)
 {
-   __be32 data;
+   __be32 data, raw_status;
int rc;
 
-   mutex_lock(&scom_dev->lock);
-
data = cpu_to_be32((value >> 32) & 0x);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA0_REG, &data,
sizeof(uint32_t));
if (rc)
-   goto bail;
+   return rc;
 
data = cpu_to_be32(value & 0x);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA1_REG, &data,
sizeof(uint32_t));
if (rc)
-   goto bail;
+   return rc;
 
data = cpu_to_be32(SCOM_WRITE_CMD | addr);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
sizeof(uint32_t));
- bail:
-   mutex_unlock(&scom_dev->lock);
-   return rc;
+   if (rc)
+   return rc;
+   rc = fsi_device_read(scom_dev->fsi_dev, SCOM_STATUS_REG, &raw_status,
+sizeof(uint32_t));
+   if (rc)
+   return rc;
+   *status = be32_to_cpu(raw_status);
+
+   return 0;
 }
 
-static int get_scom(struct scom_device *scom_dev, uint64_t *value,
-   uint32_t addr)
+static int __get_scom(struct scom_device *scom_dev, uint64_t *value,
+ uint32_t addr, uint32_t *status)
 {
-   __be32 result, data;
+   __be32 data, raw_status;
int rc;
 
 
-   mutex_lock(&scom_dev->lock);
*value = 0ULL;
data = cpu_to_be32(SCOM_READ_CMD | addr);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
sizeof(uint32_t));
if (rc)
-   goto bail;
+   return rc;
+   rc = fsi_device_read(scom_dev->fsi_dev, SCOM_STATUS_REG, &raw_status,
+sizeof(uint32_t));
+   if (rc)
+   return rc;
 
-   rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA0_REG, &r

Re: linux-next: build failure after merge of the drivers-x86 tree

[dvhart]

On June 11, 2018 6:23:10 PM PDT, Stephen Rothwell  wrote:
>Hi all,
>
>After merging the drivers-x86 tree, today's linux-next build (x86_64
>allmodconfig) failed like this:
>
>drivers/platform/x86/silead_dmi.c:84:21: error: variable
>'chuwi_vi10_data' has initializer but incomplete type
> static const struct ts_dmi_data chuwi_vi10_data = {
> ^~~
...
>Caused by commit
>
>2da502a0aea7 ("platform/x86: silead_dmi: Add touchscreen info for the
>Chuwi Vi10 tablet")
>
>I have reverted that commit for today.  More care please.

Grmbl. Thanks Stephen. I'll work with Andy tonight to get for-next back into 
good shape.

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

[RFC PATCH 1/5] fsi/scom: Add mutex around FSI2PIB accesses

[Benjamin Herrenschmidt]

Otherwise, multiple clients can open the driver and attempt
to access the PIB at the same time, thus clobbering each other
in the process.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/fsi/fsi-scom.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index c8eb5e5b94a7..3cba0eb645e1 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -37,6 +37,7 @@ struct scom_device {
struct list_head link;
struct fsi_device *fsi_dev;
struct miscdevice mdev;
+   struct mutex lock;
charname[32];
int idx;
 };
@@ -53,21 +54,26 @@ static int put_scom(struct scom_device *scom_dev, uint64_t 
value,
int rc;
uint32_t data;
 
+   mutex_lock(&scom_dev->lock);
+
data = cpu_to_be32((value >> 32) & 0x);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA0_REG, &data,
sizeof(uint32_t));
if (rc)
-   return rc;
+   goto bail;
 
data = cpu_to_be32(value & 0x);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA1_REG, &data,
sizeof(uint32_t));
if (rc)
-   return rc;
+   goto bail;
 
data = cpu_to_be32(SCOM_WRITE_CMD | addr);
-   return fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
+   rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
sizeof(uint32_t));
+ bail:
+   mutex_unlock(&scom_dev->lock);
+   return rc;
 }
 
 static int get_scom(struct scom_device *scom_dev, uint64_t *value,
@@ -76,27 +82,31 @@ static int get_scom(struct scom_device *scom_dev, uint64_t 
*value,
uint32_t result, data;
int rc;
 
+
+   mutex_lock(&scom_dev->lock);
*value = 0ULL;
data = cpu_to_be32(addr);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
sizeof(uint32_t));
if (rc)
-   return rc;
+   goto bail;
 
rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA0_REG, &result,
sizeof(uint32_t));
if (rc)
-   return rc;
+   goto bail;
 
*value |= (uint64_t)cpu_to_be32(result) << 32;
rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA1_REG, &result,
sizeof(uint32_t));
if (rc)
-   return rc;
+   goto bail;
 
*value |= cpu_to_be32(result);
 
-   return 0;
+ bail:
+   mutex_unlock(&scom_dev->lock);
+   return rc;
 }
 
 static ssize_t scom_read(struct file *filep, char __user *buf, size_t len,
@@ -183,6 +193,7 @@ static int scom_probe(struct device *dev)
if (!scom)
return -ENOMEM;
 
+   mutex_init(&scom->lock);
scom->idx = ida_simple_get(&scom_ida, 1, INT_MAX, GFP_KERNEL);
snprintf(scom->name, sizeof(scom->name), "scom%d", scom->idx);
scom->fsi_dev = fsi_dev;
-- 
2.17.0

[RFC PATCH 0/5] FSI scom driver overhaul

[Benjamin Herrenschmidt]

The current FSI scom driver is a bit too simplistic (and buggy). This
fixes a locking bug, cleans a few things up, then overhaul the driver
more thoroughly by providing proper support for the different type
of SCOM accesses (direct and indirect), handling errors properly in
the read/write interface, and adding a lower level ioctl interface
needed by system debugger (such as cronus) that need to be able to
access the raw status register content resulting from the access
attempt and do their own error handling.

I will send patches separately for pdbg and cronus to use the new
debugger interface.

Note: It is unfortunate that the read/write interface does NOT use
the same addressing scheme as the host-side equivalent xscom debugfs
interface. However I didn't want to change the user ABI by "fixing"
this as I'm not entirely sure what other users we might have of
that existing interface.

The patches apply on top of the other FSI changes posted recently
and at this point are meant to discuss the new user API.

Re: linux-next: build failure after merge of the drivers-x86 tree

[Darren Hart]

On Tue, Jun 12, 2018 at 11:23:10AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drivers-x86 tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/platform/x86/silead_dmi.c:84:21: error: variable 'chuwi_vi10_data' 
> has initializer but incomplete type
>  static const struct ts_dmi_data chuwi_vi10_data = {
>  ^~~
> drivers/platform/x86/silead_dmi.c:85:3: error: 'const struct ts_dmi_data' has 
> no member named 'acpi_name'
>   .acpi_name  = "MSSL0002:00",
>^
> drivers/platform/x86/silead_dmi.c:85:20: warning: excess elements in struct 
> initializer
>   .acpi_name  = "MSSL0002:00",
> ^
> drivers/platform/x86/silead_dmi.c:85:20: note: (near initialization for 
> 'chuwi_vi10_data')
> drivers/platform/x86/silead_dmi.c:86:3: error: 'const struct ts_dmi_data' has 
> no member named 'properties'
>   .properties = chuwi_vi10_props,
>^~
> drivers/platform/x86/silead_dmi.c:86:20: warning: excess elements in struct 
> initializer
>   .properties = chuwi_vi10_props,
> ^~~~
> drivers/platform/x86/silead_dmi.c:86:20: note: (near initialization for 
> 'chuwi_vi10_data')
> drivers/platform/x86/silead_dmi.c:84:33: error: storage size of 
> 'chuwi_vi10_data' isn't known
>  static const struct ts_dmi_data chuwi_vi10_data = {
>  ^~~
> 
> Caused by commit
> 
>   2da502a0aea7 ("platform/x86: silead_dmi: Add touchscreen info for the Chuwi 
> Vi10 tablet")
> 
> I have reverted that commit for today.  More care please.

Thank you Stephen. We caught this earlier, but failed to remove it from for-next
while repairing the series. Our apologies. I have removed this series back to
the known good patch in for-next:

26ed9d1 platform/x86: silead_dmi: Add entry for Chuwi Hi8 tablet touchscreen

Andy has this reworked already and is working on completing
testing before pushing the update to for-next.

-- 
Darren Hart
VMware Open Source Technology Center

[PATCH v2 2/2] ALSA: hda: add dock and led support for HP ProBook 640 G4

[Dennis Wassenberg]

This patch adds missing initialisation for HP 2013 UltraSlim Dock
Line-In/Out PINs and activates keyboard mute/micmute leds
for HP ProBook 640 G4

Signed-off-by: Dennis Wassenberg 
---
 sound/pci/hda/patch_conexant.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index bca71f35b34f..ff0c52e98977 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -959,6 +959,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = {
SND_PCI_QUIRK(0x103c, 0x807C, "HP EliteBook 820 G3", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x80FD, "HP ProBook 640 G2", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x83b3, "HP EliteBook 830 G5", CXT_FIXUP_HP_DOCK),
+   SND_PCI_QUIRK(0x103c, 0x83d3, "HP ProBook 640 G4", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x8174, "HP Spectre x360", CXT_FIXUP_HP_SPECTRE),
SND_PCI_QUIRK(0x103c, 0x8115, "HP Z1 Gen3", CXT_FIXUP_HP_GATE_MIC),
SND_PCI_QUIRK(0x103c, 0x814f, "HP ZBook 15u G3", 
CXT_FIXUP_MUTE_LED_GPIO),
-- 
2.17.1

[PATCH v2 1/2] ALSA: hda: add dock and led support for HP EliteBook 830 G5

[Dennis Wassenberg]

This patch adds missing initialisation for HP 2013 UltraSlim Dock
Line-In/Out PINs and activates keyboard mute/micmute leds
for HP EliteBook 830 G5

Signed-off-by: Dennis Wassenberg 
---
 sound/pci/hda/patch_conexant.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index 5b4dbcec6de8..bca71f35b34f 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -958,6 +958,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = {
SND_PCI_QUIRK(0x103c, 0x8079, "HP EliteBook 840 G3", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x807C, "HP EliteBook 820 G3", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x80FD, "HP ProBook 640 G2", CXT_FIXUP_HP_DOCK),
+   SND_PCI_QUIRK(0x103c, 0x83b3, "HP EliteBook 830 G5", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x8174, "HP Spectre x360", CXT_FIXUP_HP_SPECTRE),
SND_PCI_QUIRK(0x103c, 0x8115, "HP Z1 Gen3", CXT_FIXUP_HP_GATE_MIC),
SND_PCI_QUIRK(0x103c, 0x814f, "HP ZBook 15u G3", 
CXT_FIXUP_MUTE_LED_GPIO),
-- 
2.17.1

Re: [PATCH] proc: add error handling for kmem_cache_create

[Alexey Dobriyan]

On Tue, Jun 12, 2018 at 12:23:52PM +0800, Zhouyang Jia wrote:
> When kmem_cache_create fails, the lack of error-handling code may
> cause unexpected results.
> 
> This patch adds error-handling code after calling kmem_cache_create.

>   pde_opener_cache =
>   kmem_cache_create("pde_opener", sizeof(struct pde_opener), 0,
> SLAB_ACCOUNT|SLAB_PANIC, NULL);
> + if (!proc_inode_cachep || !pde_opener_cache)
> + return -ENOMEM;

SLAB_PANIC was added to not worry about error handling.

Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs

[jackm]

On Mon, 11 Jun 2018 10:19:18 -0600
Jason Gunthorpe  wrote:

> On Mon, Jun 11, 2018 at 09:19:14AM +0300, jackm wrote:
> > On Sun, 10 Jun 2018 22:42:03 -0600
> > Jason Gunthorpe  wrote:
> >   
> > > Er, the spec has nothing to do with this. In Linux the TID is made
> > > unique because the core code provides 32 bits that are unique and
> > > the user provides another 32 bits that are unique. The driver
> > > cannot change any of those bits without risking non-uniquenes,
> > > which is exactly the bug mlx4 created when it stepped outside its
> > > bounds and improperly overrode bits in the TID for its own
> > > internal use.  
> > 
> > Actually, the opposite is true here.  When SRIOV is active, each VM
> > generates its *own* TIDs -- with 32 bits of agent number and 32 bits
> > of counter.  
> 
> And it does it while re-using the LRH of the host, so all VMs and the
> host are now forced to share a TID space, yes I know.
> 
> > There is a chance that two different VMs can generate the same TID!
> > Encoding the slave (VM) number in the packet actually guarantees
> > uniqueness here.  
> 
> Virtualizing the TID in the driver would be fine, but it must
> virtualize all the TIDs (even those generated by the HOST).

It DOES do so.  The host slave id is 0. Slave numbers start with 1.
If the MS byte contains a zero after paravirtualization, the MAD
was sent by the host.
In fact, ALL mads are paravirtualized -- including those to/from the host.

> 
> Just blindly assuming the host doesn't generate TID's that overlap
> with the virtualization process is a bug.
> 
Not the case, host mads are also paravirtualized.

> > There is nothing wrong with modifying the TID in a reversible way in
> > order to: a. guarantee uniqueness b. identify the VM which should
> > receive the response packet  
> 
> Sure, as long as *all* TID's sharing a LRH are vitalized like this.
> 
> > The problem was created when the agent-id numbers started to use the
> > most-significant byte (thus making the MSB slave-id addition
> > impossible).  
> 
> It hasn't always been this way? What commit?
> 
Commit: 37bfc7c1e83f1 ("IB/mlx4: SR-IOV multiplex and demultiplex MADs"):

Code snippet which replaces the MS byte is below (file 
drivers/infiniband/hw/mlx4/mad.c,
procedure mlx4_ib_multiplex_mad() ).
Just an aside:  Oracle noted the problem on the *host*: The host's message log
contained the warning issued on line 1529, with slave=0 (which is the 
hypervisor).

37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1519)  switch 
(tunnel->mad.mad_hdr.method) {
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1520)  case 
IB_MGMT_METHOD_SET:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1521)  case 
IB_MGMT_METHOD_GET:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1522)  case 
IB_MGMT_METHOD_REPORT:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1523)  case 
IB_SA_METHOD_GET_TABLE:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1524)  case 
IB_SA_METHOD_DELETE:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1525)  case 
IB_SA_METHOD_GET_MULTI:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1526)  case 
IB_SA_METHOD_GET_TRACE_TBL:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1527)  
slave_id = (u8 *) &tunnel->mad.mad_hdr.tid;
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1528)  
if (*slave_id) {
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1529)  
mlx4_ib_warn(ctx->ib_dev, "egress mad has non-null tid msb:%d "
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1530)  
 "class:%d slave:%d\n", *slave_id,
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1531)  
 tunnel->mad.mad_hdr.mgmt_class, slave);
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1532)  
return;
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1533)  
} else
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1534)  
*slave_id = slave;
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1535)  default:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1536)  
/* nothing */;
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1537)  }

> Jason 

Re: [PATCH 2/2] arm64: dts: qcom: sdm845: Enable debug UART and I2C10 on sdm845-mtp

[Bjorn Andersson]

On Thu 07 Jun 13:46 PDT 2018, Douglas Anderson wrote:

> The debug UART is very useful to have.  I2C10 is enabled as an example
> of a I2C port we can talk on for now.  Eventually we'll want to put
> peripherals under it.
> 
> Signed-off-by: Douglas Anderson 

Reviewed-by: Bjorn Andersson 
Tested-by: Bjorn Andersson 

Regards,
Bjorn

> ---
> 
>  arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 52 +
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> index 979ab49913f1..e1eda143a725 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -12,4 +12,56 @@
>  / {
>   model = "Qualcomm Technologies, Inc. SDM845 MTP";
>   compatible = "qcom,sdm845-mtp";
> +
> + aliases {
> + serial0 = &uart9;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&i2c10 {
> + status = "okay";
> + clock-frequency = <40>;
> +};
> +
> +&qupv3_id_1 {
> + status = "okay";
> +};
> +
> +&uart9 {
> + status = "okay";
> +};
> +
> +/* PINCTRL - additions to nodes defined in sdm845.dtsi */
> +
> +&qup_i2c10_default {
> + pinconf {
> + pins = "gpio55", "gpio56";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
> +&qup_uart9_default {
> + pinconf-tx {
> + pins = "gpio4";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + pinconf-rx {
> + pins = "gpio5";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +};
> +
> +&qup_uart9_sleep {
> + pinconf {
> + pins = "gpio4", "gpio5";
> + bias-pull-down;
> + };
>  };
> -- 
> 2.17.1.1185.g55be947832-goog
> 

Re: [PATCH 1/2] arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes

[Bjorn Andersson]

On Thu 07 Jun 13:46 PDT 2018, Douglas Anderson wrote:

> This adds nodes to SDM845-dtsi for all the I2C ports, all the SPI
> ports, and UART9.  Note that I2C / SPI / UART are a bit strange on
> sdm845 because each "serial engine" has 4 pins associated with it and
> depending on which firmware has been loaded into the serial engine
> (loaded by the BIOS) the serial engine can behave like an I2C port, a
> SPI port, or a UART.  As per the landed bindings that means that we
> need to create one node for each possible mode that the port could be
> in.  With 16 serial engines that means 16 x 3 = 48 nodes.
> 
> We get away with only creating 33 nodes for now because it seems very
> likely that SDM845-based boards will actually all use the same UART
> (UART 9) for debug purposes.  While another UART could be used for
> something like Bluetooth communication we can cross that path when we
> come to it.  Some documentation that I saw implied that using a UART
> for "high speed" communications actually needs yet another different
> serial engine firmware anyway.
> 
> Note that quick measurements adding all these nodes adds ~10k of extra
> space per dtb that they're included with.  If this becomes a problem
> we may need to think of a different way to structure this so that
> boards only get the nodes they need (or figure out how to get dtc to
> strip 'disabled' nodes).  For now it seems OK.
> 
> These nodes were programmatically generated with a fairly dumb python
> script.  See http://crosreview.com/1091631 for the source.
> 
> Signed-off-by: Douglas Anderson 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
> 
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 1013 ++
>  1 file changed, 1013 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index cdaabeb3c995..2dc5c7dcc9aa 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -5,6 +5,7 @@
>   * Copyright (c) 2018, The Linux Foundation. All rights reserved.
>   */
>  
> +#include 
>  #include 
>  
>  / {
> @@ -13,6 +14,41 @@
>   #address-cells = <2>;
>   #size-cells = <2>;
>  
> + aliases {
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + i2c2 = &i2c2;
> + i2c3 = &i2c3;
> + i2c4 = &i2c4;
> + i2c5 = &i2c5;
> + i2c6 = &i2c6;
> + i2c7 = &i2c7;
> + i2c8 = &i2c8;
> + i2c9 = &i2c9;
> + i2c10 = &i2c10;
> + i2c11 = &i2c11;
> + i2c12 = &i2c12;
> + i2c13 = &i2c13;
> + i2c14 = &i2c14;
> + i2c15 = &i2c15;
> + spi0 = &spi0;
> + spi1 = &spi1;
> + spi2 = &spi2;
> + spi3 = &spi3;
> + spi4 = &spi4;
> + spi5 = &spi5;
> + spi6 = &spi6;
> + spi7 = &spi7;
> + spi8 = &spi8;
> + spi9 = &spi9;
> + spi10 = &spi10;
> + spi11 = &spi11;
> + spi12 = &spi12;
> + spi13 = &spi13;
> + spi14 = &spi14;
> + spi15 = &spi15;
> + };
> +
>   chosen { };
>  
>   memory@8000 {
> @@ -206,6 +242,489 @@
>   #power-domain-cells = <1>;
>   };
>  
> + qupv3_id_0: geniqup@8c {
> + compatible = "qcom,geni-se-qup";
> + reg = <0x8c 0x6000>;
> + clock-names = "m-ahb", "s-ahb";
> + clocks = <&gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
> +  <&gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + i2c0: i2c@88 {
> + compatible = "qcom,geni-i2c";
> + reg = <0x88 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c0_default>;
> + pinctrl-1 = <&qup_i2c0_sleep>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi0: spi@88 {
> + compatible = "qcom,geni-spi";
> + reg = <0x88 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi0_default>;
> + pinct

Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave

[Andy Lutomirski]

On Mon, Jun 11, 2018 at 4:52 AM Neil Horman  wrote:
>
> On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski  wrote:
> > >
> > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> > >  wrote:
> > >>
> > >> The Launch Enclave (LE) generates cryptographic launch tokens for user
> > >> enclaves. A launch token is used by EINIT to check whether the enclave
> > >> is authorized to launch or not. By having its own launch enclave, Linux
> > >> has full control of the enclave launch process.
> > >>
> > >> LE is wrapped into a user space proxy program that reads enclave
> > >> signatures outputs launch tokens. The kernel-side glue code is
> > >> implemented by using the user space helper framework.  The IPC between
> > >> the LE proxy program and kernel is handled with an anonymous inode.
> > >>
> > >> The commit also adds enclave signing tool that is used by kbuild to
> > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points
> > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key
> > >> pair. The default location is:
> > >>
> > >>  drivers/platform/x86/intel_sgx/sgx_signing_key.pem
> > >>
> > >> If the default key does not exist kbuild will generate a random key and
> > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify
> > >> the passphrase for the LE public key.
> > >
> > > It seems to me that it might be more useful to just commit a key pair
> > > into the kernel.  As far as I know, there is no security whatsoever
> > > gained by keeping the private key private, so why not make
> > > reproducible builds easier by simply fixing the key?
> >
> > Having thought about this some more, I think that you should
> > completely remove support for specifying a key. Provide a fixed key
> > pair, hard code the cache, and call it a day. If you make the key
> > configurable, every vendor that has any vendor keys (Debian, Ubuntu,
> > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option
> > and set up their own key pair for no gain whatsoever.  Instead, it'll
> > give some illusion of security and it'll slow down operations in a VM
> > guest due to swapping out the values of the MSRs.  And, if the code to
> > support a locked MSR that just happens to have the right value stays
> > in the kernel, then we'll risk having vendors actually ship one
> > distro's public key hash, and that will seriously suck.
> >
> If you hard code the key pair however, doesn't that imply that anyone can 
> sign a
> user space binary as a launch enclave, and potentially gain control of the 
> token
> granting process?

Yes and no.

First of all, the kernel driver shouldn't be allowing user code to
launch a launch enclave regardless of signature.  I haven't gotten far
enough in reviewing the code to see whether that's the case, but if
it's not, it should be fixed before it's merged.

But keep in mind that control of the token granting process is not the
same thing as control over the right to launch an enclave.  On systems
without the LE hash MSRs, Intel controls the token granting process
and, barring some attack, an enclave that isn't blessed by Intel can't
be launched.  Support for that model will not be merged into upstream
Linux.  But on systems that have the LE hash MSRs and leave them
unlocked, there is effectively no hardware-enforced launch control.
Instead we have good old kernel policy.  If a user wants to launch an
enclave, they need to get the kernel to launch the enclave, and the
kernel needs to apply its policy.  The patch here (the in-kernel
launch enclave) has a wide-open policy.

So, as a practical matter, if every distro has their own LE key and
keeps it totally safe, then a system that locks the MSRs to one
distro's key makes it quite annoying to run another distro's intel_sgx
driver, but there is no effect on the actual security of the system.

>  It was my understanding that the value of the key pair was
> that the end user was guaranteed autonomy and security over which processes
> could start enclaves.  By publishing a fixed key pair, it seems to remove that
> ability.

If someone comes up with an actual machine that grants the actual end
user (where the end user is the person who bought the thing, not the
OEM) control over the MSRs, *and* the actual end user wants to limit
what enclaves can be launched even if the kernel is compromised, *and*
there is some actual argument for why this is useful (as opposed to
some compliance checkbox), then Linux could reasonably consider adding
support for this use case.  But that would be a separate patch.

>
> What would be nicer (I think) would be the abilty to specify both the public 
> and
> the private key at run time.  the use case here is not one in which a vendor 
> or
> os distribution ships a key pair, but one in which a downstream user doesn't
> want a vendor/os distribution to have any cryptographic information installed 
> on
> their sy

Re: [PATCH 2/2] fs/lock: show locks taken by processes from another pidns

[Andrey Vagin]

On Fri, Jun 08, 2018 at 05:27:12PM +0300, Konstantin Khorenko wrote:
> Currently if we face a lock taken by a process invisible in the current
> pidns we skip the lock completely, but this
> 
> 1) makes the output not that nice
> (root@vz7)/: cat /proc/${PID_A2}/fdinfo/3
> pos:4
> flags:  0212
> mnt_id: 257
> lock:   (root@vz7)/:
> 
> 2) makes it more difficult to debug issues with leaked flocks
>if you get error on lock, but don't see any locks in /proc/$id/fdinfo/$file

3) breaks the CRIU project. criu reads fdinfo to dump file locks.

> 
> Let's show information about such locks again as previously, but
> show zero in the owner pid field.
> 
> After the patch:
> ===
> (root@vz7)/:cat /proc/${PID_A2}/fdinfo/3
> pos:4
> flags:  0212
> mnt_id: 295
> lock:   1: FLOCK  ADVISORY  WRITE 0 b6:f8a61:529946 0 EOF
>

I think initially this was broken in this commit:

Fixes: d67fd44f697d ("locks: Filter /proc/locks output on proc pid ns")


Acked-by: Andrei Vagin 

Thanks,
Andrei

> Fixes: 9d5b86ac13c5 ("fs/locks: Remove fl_nspid and use fs-specific l_pid for 
> remote locks")
> Signed-off-by: Konstantin Khorenko 
> ---
>  fs/locks.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index bfee5b7f2862..e533623e2e99 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -2633,12 +2633,10 @@ static void lock_get_status(struct seq_file *f, 
> struct file_lock *fl,
>  
>   fl_pid = locks_translate_pid(fl, proc_pidns);
>   /*
> -  * If there isn't a fl_pid don't display who is waiting on
> -  * the lock if we are called from locks_show, or if we are
> -  * called from __show_fd_info - skip lock entirely
> +  * If lock owner is dead (and pid is freed) or not visible in current
> +  * pidns, zero is shown as a pid value. Check lock info from
> +  * init_pid_ns to get saved lock pid value.
>*/
> - if (fl_pid == 0)
> - return;
>  
>   if (fl->fl_file != NULL)
>   inode = locks_inode(fl->fl_file);
> -- 
> 2.15.1
> 

[PATCH] staging: lustre: add error handling for try_module_get

[Zhouyang Jia]

When try_module_get fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling try_module_get.

Signed-off-by: Zhouyang Jia 
---
 drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
index 7086678..72a42bd 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
@@ -2422,7 +2422,10 @@ ksocknal_base_startup(void)
 
/* flag lists/ptrs/locks initialised */
ksocknal_data.ksnd_init = SOCKNAL_INIT_DATA;
-   try_module_get(THIS_MODULE);
+   if (!try_module_get(THIS_MODULE)) {
+   CERROR("%s: cannot get module\n", __func__);
+   goto failed;
+   }
 
ksocknal_data.ksnd_sched_info = cfs_percpt_alloc(lnet_cpt_table(),
 sizeof(*info));
-- 
2.7.4

Re: [PATCH v2 2/2] tpm: add support for nonblocking operation

[Tadeusz Struk]

On 06/11/2018 07:53 PM, kbuild test robot wrote:
> Hi Tadeusz,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on char-misc/char-misc-testing]
> [also build test ERROR on next-20180608]
> [cannot apply to v4.17]

Hi,
Thanks for the report. This patch should go on top of
https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git/?h=next-tpm
I will check the config tomorrow.
Thanks,
-- 
Tadeusz

[PATCH v3 4/7] arm64: dts: msm8996: Add rpmpd device node

[Rajendra Nayak]

Add rpmpd device node and its OPP table

Signed-off-by: Rajendra Nayak 
Signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 8c7f9ca25b53..404a08630ccd 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -308,6 +308,40 @@
#clock-cells = <1>;
};
 
+   rpmpd: power-controller {
+   compatible = "qcom,msm8996-rpmpd";
+   #power-domain-cells = <1>;
+   operating-points-v2 = <&rpmpd_opp_table>;
+   };
+
+   rpmpd_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+   rpmpd_opp1: opp1 {
+   qcom,level = <1>;
+   };
+
+   rpmpd_opp2: opp2 {
+   qcom,level = <2>;
+   };
+
+   rpmpd_opp3: opp3 {
+   qcom,level = <3>;
+   };
+
+   rpmpd_opp4: opp4 {
+   qcom,level = <4>;
+   };
+
+   rpmpd_opp5: opp5 {
+   qcom,level = <5>;
+   };
+
+   rpmpd_opp6: opp6 {
+   qcom,level = <6>;
+   };
+   };
+
pm8994-regulators {
compatible = "qcom,rpm-pm8994-regulators";
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v3 2/7] soc: qcom: rpmpd: Add a Power domain driver to model corners

[Rajendra Nayak]

The Power domains for corners just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.

We add all Power domain data needed on msm8996 here. This driver can easily
be extended by adding data for other qualcomm SoCs as well.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Viresh Kumar 
---
 drivers/soc/qcom/Kconfig   |   9 +
 drivers/soc/qcom/Makefile  |   1 +
 drivers/soc/qcom/rpmpd.c   | 301 +
 include/dt-bindings/power/qcom-rpmpd.h |  16 ++
 4 files changed, 327 insertions(+)
 create mode 100644 drivers/soc/qcom/rpmpd.c
 create mode 100644 include/dt-bindings/power/qcom-rpmpd.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 9dc02f390ba3..5c54931a7b99 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
 
  Say y here if you intend to boot the modem remoteproc.
 
+config QCOM_RPMPD
+   tristate "Qualcomm RPM Power domain driver"
+   depends on MFD_QCOM_RPM && QCOM_SMD_RPM
+   help
+ QCOM RPM Power domain driver to support power-domains with
+ performance states. The driver communicates a performance state
+ value to RPM which then translates it into corresponding voltage
+ for the voltage rail.
+
 config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 19dcf957cb3a..9550c170de93 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_QCOM_SMP2P)  += smp2p.o
 obj-$(CONFIG_QCOM_SMSM)+= smsm.o
 obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
 obj-$(CONFIG_QCOM_APR) += apr.o
+obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
new file mode 100644
index ..c5e7a91f278c
--- /dev/null
+++ b/drivers/soc/qcom/rpmpd.c
@@ -0,0 +1,301 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
+
+/* Resource types */
+#define RPMPD_SMPA 0x61706d73
+#define RPMPD_LDOA 0x616f646c
+
+/* Operation Keys */
+#define KEY_CORNER 0x6e726f63 /* corn */
+#define KEY_ENABLE 0x6e657773 /* swen */
+#define KEY_FLOOR_CORNER   0x636676   /* vfc */
+
+#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
+   static struct rpmpd _platform##_##_active;  \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .peer = &_platform##_##_active, \
+   .res_type = RPMPD_SMPA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   };  \
+   static struct rpmpd _platform##_##_active = {   \
+   .pd = { .name = #_active, },\
+   .peer = &_platform##_##_name,   \
+   .active_only = true,\
+   .res_type = RPMPD_SMPA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   }
+
+#define DEFINE_RPMPD_CORN_LDOA(_platform, _name, r_id) \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .res_type = RPMPD_LDOA, \
+   .res_id = r_id, \
+   .key = KEY_CORNER,  \
+   }
+
+#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type)   \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .res_type = r_type, \
+   .res_id = r_id, \
+   .key = KEY_FLOOR_CORNER,\
+   }
+
+#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id)  \
+   DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
+

[PATCH v3 7/7] soc: qcom: rpmpd/rpmhpd: Add a max vote on all corners at init

[Rajendra Nayak]

As we move from no clients/consumers in kernel voting on corners,
to *some* voting and some not voting, we might end up in a situation
where the clients which remove votes can adversly impact others
who still don't have a way to vote.

To avoid this situation, have a max vote on all corners at init.
This should/can be removed once we have all clients moved to
be able to vote/unvote for themselves.

Signed-off-by: Rajendra Nayak 
Acked-by: Viresh Kumar 
---
 drivers/soc/qcom/rpmhpd.c | 12 +++-
 drivers/soc/qcom/rpmpd.c  |  9 +
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
index 7083ec1590ff..3c753d33aeee 100644
--- a/drivers/soc/qcom/rpmhpd.c
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -329,7 +329,7 @@ static int rpmhpd_update_level_mapping(struct rpmhpd 
*rpmhpd)
 
 static int rpmhpd_probe(struct platform_device *pdev)
 {
-   int i, ret;
+   int i, ret, max_level;
size_t num;
struct genpd_onecell_data *data;
struct rpmhpd **rpmhpds;
@@ -390,6 +390,16 @@ static int rpmhpd_probe(struct platform_device *pdev)
pm_genpd_init(&rpmhpds[i]->pd, NULL, true);
 
data->domains[i] = &rpmhpds[i]->pd;
+
+   /*
+* Until we have all consumers voting on corners
+* just vote the max corner on all PDs
+* This should ideally be *removed* once we have
+* all (most) consumers being able to vote
+*/
+   max_level = rpmhpds[i]->level_count - 1;
+   rpmhpd_set_performance(&rpmhpds[i]->pd, 
rpmhpds[i]->level[max_level]);
+   rpmhpd_power_on(&rpmhpds[i]->pd);
}
 
return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 53209454c1f3..6440163305e3 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -310,6 +310,15 @@ static int rpmpd_probe(struct platform_device *pdev)
pm_genpd_init(&rpmpds[i]->pd, NULL, true);
 
data->domains[i] = &rpmpds[i]->pd;
+
+   /*
+* Until we have all consumers voting on corners
+* just vote the max corner on all PDs
+* This should ideally be *removed* once we have
+* all (most) consumers being able to vote
+*/
+   rpmpd_set_performance(&rpmpds[i]->pd, MAX_RPMPD_STATE);
+   rpmpd_power_on(&rpmpds[i]->pd);
}
 
return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v3 5/7] dt-bindings: power: Add qcom rpmh power domain driver bindings

[Rajendra Nayak]

Add DT bindings to describe the rpmh powerdomains found on Qualcomm
Technologies, Inc. SoCs. These power domains communicate a performance
state to RPMh, which then translates it into corresponding voltage on
a PMIC rail.

Signed-off-by: Rajendra Nayak 
---
 .../devicetree/bindings/power/qcom,rpmhpd.txt | 65 +++
 1 file changed, 65 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmhpd.txt

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt 
b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
new file mode 100644
index ..41ef7afa6b24
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
@@ -0,0 +1,65 @@
+Qualcomm RPMh Power domains
+
+For RPMh Power domains, we communicate a performance state to RPMh
+which then translates it into a corresponding voltage on a rail
+
+Required Properties:
+ - compatible: Should be one of the following
+   * qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
+ - power-domain-cells: number of cells in power domain specifier
+   must be 1
+ - operating-points-v2: Phandle to the OPP table for the power-domain.
+   Refer to Documentation/devicetree/bindings/power/power_domain.txt
+   and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
+
+Example:
+
+   rpmhpd: power-controller {
+   compatible = "qcom,sdm845-rpmhpd";
+   #power-domain-cells = <1>;
+   operating-points-v2 = <&rpmhpd_opp_table>;
+   };
+
+   rpmhpd_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+   rpmhpd_opp_ret: opp1 {
+   qcom-level = <16>;
+   };
+
+   rpmhpd_opp_min_svs: opp2 {
+   qcom-level = <48>;
+   };
+
+   rpmhpd_opp_low_svs: opp3 {
+   qcom-level = <64>;
+   };
+
+   rpmhpd_opp_svs: opp4 {
+   qcom-level = <128>;
+   };
+
+   rpmhpd_opp_svs_l1: opp5 {
+   qcom-level = <192>;
+   };
+
+   rpmhpd_opp_nom: opp6 {
+   qcom-level = <256>;
+   };
+
+   rpmhpd_opp_nom_l1: opp7 {
+   qcom-level = <320>;
+   };
+
+   rpmhpd_opp_nom_l2: opp8 {
+   qcom-level = <336>;
+   };
+
+   rpmhpd_opp_turbo: opp9 {
+   qcom-level = <384>;
+   };
+
+   rpmhpd_opp_turbo_l1: opp10 {
+   qcom-level = <416>;
+   };
+   };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v3 3/7] soc: qcom: rpmpd: Add support for get/set performance state

[Rajendra Nayak]

Add support for the .set_performace_state() and .opp_to_performance_state()
callbacks in the rpmpd driver.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Viresh Kumar 
---
 drivers/soc/qcom/rpmpd.c | 46 
 1 file changed, 46 insertions(+)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index c5e7a91f278c..53209454c1f3 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -28,6 +29,8 @@
 #define KEY_ENABLE 0x6e657773 /* swen */
 #define KEY_FLOOR_CORNER   0x636676   /* vfc */
 
+#define MAX_RPMPD_STATE6
+
 #define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
static struct rpmpd _platform##_##_active;  \
static struct rpmpd _platform##_##_name = { \
@@ -221,6 +224,47 @@ static int rpmpd_power_off(struct generic_pm_domain 
*domain)
return ret;
 }
 
+static int rpmpd_set_performance(struct generic_pm_domain *domain,
+unsigned int state)
+{
+   int ret = 0;
+   struct rpmpd *pd = domain_to_rpmpd(domain);
+
+   mutex_lock(&rpmpd_lock);
+
+   if (state > MAX_RPMPD_STATE)
+   goto out;
+
+   pd->corner = state;
+
+   if (!pd->enabled && (pd->key != KEY_FLOOR_CORNER))
+   goto out;
+
+   ret = rpmpd_aggregate_corner(pd);
+
+out:
+   mutex_unlock(&rpmpd_lock);
+
+   return ret;
+}
+
+static unsigned int rpmpd_get_performance(struct generic_pm_domain *genpd,
+ struct dev_pm_opp *opp)
+{
+   struct device_node *np;
+   unsigned int corner = 0;
+
+   np = dev_pm_opp_get_of_node(opp);
+   if (of_property_read_u32(np, "qcom,level", &corner)) {
+   pr_err("%s: missing 'qcom,level' property\n", __func__);
+   return 0;
+   }
+
+   of_node_put(np);
+
+   return corner;
+}
+
 static int rpmpd_probe(struct platform_device *pdev)
 {
int i;
@@ -261,6 +305,8 @@ static int rpmpd_probe(struct platform_device *pdev)
rpmpds[i]->rpm = rpm;
rpmpds[i]->pd.power_off = rpmpd_power_off;
rpmpds[i]->pd.power_on = rpmpd_power_on;
+   rpmpds[i]->pd.set_performance_state = rpmpd_set_performance;
+   rpmpds[i]->pd.opp_to_performance_state = rpmpd_get_performance;
pm_genpd_init(&rpmpds[i]->pd, NULL, true);
 
data->domains[i] = &rpmpds[i]->pd;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v3 6/7] soc: qcom: Add RPMh Power domain driver

[Rajendra Nayak]

The RPMh Power domain driver aggregates the corner votes from various
consumers for the ARC resources and communicates it to RPMh.

We also add data for all power domains on sdm845 SoC as part of the patch.
The driver can be extended to support other SoCs which support RPMh

Signed-off-by: Rajendra Nayak 
---
 drivers/soc/qcom/Kconfig|   9 +
 drivers/soc/qcom/Makefile   |   1 +
 drivers/soc/qcom/rpmhpd.c   | 427 
 include/dt-bindings/power/qcom-rpmhpd.h |  31 ++
 4 files changed, 468 insertions(+)
 create mode 100644 drivers/soc/qcom/rpmhpd.c
 create mode 100644 include/dt-bindings/power/qcom-rpmhpd.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 5c54931a7b99..7cb7eba2b997 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
 
  Say y here if you intend to boot the modem remoteproc.
 
+config QCOM_RPMHPD
+   tristate "Qualcomm RPMh Power domain driver"
+   depends on QCOM_RPMH && QCOM_COMMAND_DB
+   help
+ QCOM RPMh Power domain driver to support power-domains with
+ performance states. The driver communicates a performance state
+ value to RPMh which then translates it into corresponding voltage
+ for the voltage rail.
+
 config QCOM_RPMPD
tristate "Qualcomm RPM Power domain driver"
depends on MFD_QCOM_RPM && QCOM_SMD_RPM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 9550c170de93..499513f63bef 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_QCOM_SMSM)   += smsm.o
 obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
 obj-$(CONFIG_QCOM_APR) += apr.o
 obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
+obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
new file mode 100644
index ..7083ec1590ff
--- /dev/null
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -0,0 +1,427 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved.*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define domain_to_rpmhpd(domain) container_of(domain, struct rpmhpd, pd)
+
+#define DEFINE_RPMHPD_AO(_platform, _name, _active)\
+   static struct rpmhpd _platform##_##_active; \
+   static struct rpmhpd _platform##_##_name = {\
+   .pd = { .name = #_name, },  \
+   .peer = &_platform##_##_active, \
+   .res_name = #_name".lvl",   \
+   .valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) |  \
+   BIT(RPMH_WAKE_ONLY_STATE) | \
+   BIT(RPMH_SLEEP_STATE)), \
+   };  \
+   static struct rpmhpd _platform##_##_active = {  \
+   .pd = { .name = #_active, },\
+   .peer = &_platform##_##_name,   \
+   .active_only = true,\
+   .res_name = #_name".lvl",   \
+   .valid_state_mask = (BIT(RPMH_ACTIVE_ONLY_STATE) |  \
+   BIT(RPMH_WAKE_ONLY_STATE) | \
+   BIT(RPMH_SLEEP_STATE)), \
+   }
+
+#define DEFINE_RPMHPD(_platform, _name)
\
+   static struct rpmhpd _platform##_##_name = {\
+   .pd = { .name = #_name, },  \
+   .res_name = #_name".lvl",   \
+   .valid_state_mask = BIT(RPMH_ACTIVE_ONLY_STATE),\
+   }
+
+/*
+ * This is the number of bytes used for each command DB aux data entry of an
+ * ARC resource.
+ */
+#define RPMH_ARC_LEVEL_SIZE2
+#define RPMH_ARC_MAX_LEVELS16
+
+struct rpmhpd {
+   struct device   *dev;
+   struct generic_pm_domain pd;
+   struct rpmhpd   *peer;
+   const bool  active_only;
+   unsigned intcorner;
+   unsigned intactive_corner;
+   u32 level[RPMH_ARC_MAX_LEVELS];
+   int level_count;
+   boolenabled;
+   const char  *res_name;
+   u32 addr;
+   u8  valid_state_mask;
+};
+
+struct rpmhpd_desc {
+   struct rpmhpd **rpmhpds;
+   size_t num_pds;
+};
+
+static DEFINE_MUTEX(rpmhpd_lock);
+
+/* sdm845 RPMh Power domains */
+DEFINE_RPMHPD(sdm845, ebi);
+DEFINE_RPMHPD_AO(sdm845, mx, mx_ao);
+DEFINE_RPMHPD_AO(sdm845, cx,

[PATCH v3 0/7] Add powerdomain driver for corners on msm8996/sdm845

[Rajendra Nayak]

Changes in v3:
* Bindings split into seperate patches
* Bindings updated to remove duplicate OPP table phandles
* DT headers defining macros for Power domain indexes and OPP levels
* Optimisations to use rpmh_write_async() whereever applicable
* Fixed up handling of ACTIVE_ONLY/WAKE_ONLY/SLEEP voting for RPMh
* Fixed the vlvl to hlvl conversions in set_performance
* Other minor fixes based on review of v2
* TODO: This series does not handle the case where all VDD_MX votes
should be higher than VDD_CX from APPs, as pointed out
by David Collins in v2. This needs support at genpd to propogate performance
state up the parents, if we model these as Parent/Child to handle the
interdependency.

Changes in v2:
* added a powerdomain driver for sdm845 which supports communicating to RPMh
* dropped the changes to sdhc driver to move over to using OPP
as there is active discussion on using OPP as the interface vs
handling all of it in clock drivers
* Other minor binding updates based on review of v1

With performance state support for genpd/OPP merged, this is an effort
to model a powerdomain driver to communicate corner/level
values for qualcomm platforms to RPM (Remote Power Manager) and RPMh.

Rajendra Nayak (7):
  dt-bindings: power: Add qcom rpm power domain driver bindings
  soc: qcom: rpmpd: Add a Power domain driver to model corners
  soc: qcom: rpmpd: Add support for get/set performance state
  arm64: dts: msm8996: Add rpmpd device node
  dt-bindings: power: Add qcom rpmh power domain driver bindings
  soc: qcom: Add RPMh Power domain driver
  soc: qcom: rpmpd/rpmhpd: Add a max vote on all corners at init

 .../devicetree/bindings/power/qcom,rpmhpd.txt |  65 +++
 .../devicetree/bindings/power/qcom,rpmpd.txt  |  49 ++
 arch/arm64/boot/dts/qcom/msm8996.dtsi |  34 ++
 drivers/soc/qcom/Kconfig  |  18 +
 drivers/soc/qcom/Makefile |   2 +
 drivers/soc/qcom/rpmhpd.c | 437 ++
 drivers/soc/qcom/rpmpd.c  | 356 ++
 include/dt-bindings/power/qcom-rpmhpd.h   |  31 ++
 include/dt-bindings/power/qcom-rpmpd.h|  16 +
 9 files changed, 1008 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
 create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
 create mode 100644 drivers/soc/qcom/rpmhpd.c
 create mode 100644 drivers/soc/qcom/rpmpd.c
 create mode 100644 include/dt-bindings/power/qcom-rpmhpd.h
 create mode 100644 include/dt-bindings/power/qcom-rpmpd.h

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v3 1/7] dt-bindings: power: Add qcom rpm power domain driver bindings

[Rajendra Nayak]

Add DT bindings to describe the rpm power domains found on Qualcomm
Technologies, Inc. SoCs. These power domains communicate a performance
state to RPM, which then translates it into corresponding voltage on a
PMIC rail.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Viresh Kumar 
---
 .../devicetree/bindings/power/qcom,rpmpd.txt  | 49 +++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt 
b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
new file mode 100644
index ..61a0e2687940
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -0,0 +1,49 @@
+Qualcomm RPM Power domains
+
+For RPM Power domains, we communicate a performance state to RPM
+which then translates it into a corresponding voltage on a rail
+
+Required Properties:
+ - compatible: Should be one of the following
+   * qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
+ - power-domain-cells: number of cells in Power domain specifier
+   must be 1.
+ - operating-points-v2: Phandle to the OPP table for the Power domain.
+   Refer to Documentation/devicetree/bindings/power/power_domain.txt
+   and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
+
+Example:
+
+   rpmpd: power-controller {
+   compatible = "qcom,msm8996-rpmpd";
+   #power-domain-cells = <1>;
+   operating-points-v2 = <&rpmpd_opp_table>;
+   };
+
+   rpmpd_opp_table: opp-table {
+   compatible = "operating-points-v2-qcom-level";
+
+   rpmpd_opp1: opp1 {
+   qcom,level = <1>;
+   };
+
+   rpmpd_opp2: opp2 {
+   qcom,level = <2>;
+   };
+
+   rpmpd_opp3: opp3 {
+   qcom,level = <3>;
+   };
+
+   rpmpd_opp4: opp4 {
+   qcom,level = <4>;
+   };
+
+   rpmpd_opp5: opp5 {
+   qcom,level = <5>;
+   };
+
+   rpmpd_opp6: opp6 {
+   qcom,level = <6>;
+   };
+   };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH] rtc: rtc-bq4802: add error handling for devm_ioremap

[Zhouyang Jia]

When devm_ioremap fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling devm_ioremap.

Signed-off-by: Zhouyang Jia 
---
 drivers/rtc/rtc-bq4802.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/rtc/rtc-bq4802.c b/drivers/rtc/rtc-bq4802.c
index bd170cb..5747a54 100644
--- a/drivers/rtc/rtc-bq4802.c
+++ b/drivers/rtc/rtc-bq4802.c
@@ -164,6 +164,10 @@ static int bq4802_probe(struct platform_device *pdev)
} else if (p->r->flags & IORESOURCE_MEM) {
p->regs = devm_ioremap(&pdev->dev, p->r->start,
resource_size(p->r));
+   if (!p->regs){
+   err = -ENOMEM;
+   goto out;
+   }
p->read = bq4802_read_mem;
p->write = bq4802_write_mem;
} else {
-- 
2.7.4

[PATCH] ACPI : dock: add error handling for acpi_bus_get_device

[Zhouyang Jia]

When acpi_bus_get_device fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling acpi_bus_get_device.

Signed-off-by: Zhouyang Jia 
---
 drivers/acpi/dock.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c
index e3fc1f0..02fc134 100644
--- a/drivers/acpi/dock.c
+++ b/drivers/acpi/dock.c
@@ -504,7 +504,9 @@ static ssize_t show_docked(struct device *dev,
struct dock_station *dock_station = dev->platform_data;
struct acpi_device *adev = NULL;
 
-   acpi_bus_get_device(dock_station->handle, &adev);
+   if (acpi_bus_get_device(dock_station->handle, &adev))
+   return -ENODEV;
+
return snprintf(buf, PAGE_SIZE, "%u\n", acpi_device_enumerated(adev));
 }
 static DEVICE_ATTR(docked, S_IRUGO, show_docked, NULL);
-- 
2.7.4

[PATCH] drivers/tty: add error handling for pcmcia_loop_config

[Zhouyang Jia]

When pcmcia_loop_config fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling pcmcia_loop_config.

Signed-off-by: Zhouyang Jia 
---
 drivers/tty/serial/8250/serial_cs.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/serial_cs.c 
b/drivers/tty/serial/8250/serial_cs.c
index 9963a76..c8186a0 100644
--- a/drivers/tty/serial/8250/serial_cs.c
+++ b/drivers/tty/serial/8250/serial_cs.c
@@ -638,8 +638,10 @@ static int serial_config(struct pcmcia_device *link)
(link->has_func_id) &&
(link->socket->pcmcia_pfc == 0) &&
((link->func_id == CISTPL_FUNCID_MULTI) ||
-(link->func_id == CISTPL_FUNCID_SERIAL)))
-   pcmcia_loop_config(link, serial_check_for_multi, info);
+(link->func_id == CISTPL_FUNCID_SERIAL))) {
+   if (pcmcia_loop_config(link, serial_check_for_multi, info))
+   goto failed;
+   }
 
/*
 * Apply any multi-port quirk.
-- 
2.7.4

Re: [PATCH 1/2] fs/lock: skip lock owner pid translation in case we are in init_pid_ns

[Andrey Vagin]

On Fri, Jun 08, 2018 at 05:27:11PM +0300, Konstantin Khorenko wrote:
> If the flock owner process is dead and its pid has been already freed,
> pid translation won't work, but we still want to show flock owner pid
> number when expecting /proc/$PID/fdinfo/$FD in init pidns.
> 
> Reproducer:
> process A process A1  process A2
> fork()->
> exit()open()
>   flock()
>   fork()->
>   exit()  sleep()
> 
> Before the patch:
> 
> (root@vz7)/: cat /proc/${PID_A2}/fdinfo/3
> pos:4
> flags:  0212
> mnt_id: 257
> lock:   (root@vz7)/:
> 
> After the patch:
> ===
> (root@vz7)/:cat /proc/${PID_A2}/fdinfo/3
> pos:4
> flags:  0212
> mnt_id: 295
> lock:   1: FLOCK  ADVISORY  WRITE ${PID_A1} b6:f8a61:529946 0 EOF
> 

Acked-by: Andrey Vagin 

> Fixes: 9d5b86ac13c5 ("fs/locks: Remove fl_nspid and use fs-specific l_pid for 
> remote locks")
> Signed-off-by: Konstantin Khorenko 
> ---
>  fs/locks.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index 05e211be8684..bfee5b7f2862 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -2072,6 +2072,13 @@ static pid_t locks_translate_pid(struct file_lock *fl, 
> struct pid_namespace *ns)
>   return -1;
>   if (IS_REMOTELCK(fl))
>   return fl->fl_pid;
> + /*
> +  * If the flock owner process is dead and its pid has been already
> +  * freed, the translation below won't work, but we still want to show
> +  * flock owner pid number in init pidns.
> +  */
> + if (ns == &init_pid_ns)
> + return (pid_t)fl->fl_pid;
>  
>   rcu_read_lock();
>   pid = find_pid_ns(fl->fl_pid, &init_pid_ns);
> -- 
> 2.15.1
> 

[PATCH] fs/coda: add error handling for fget

[Zhouyang Jia]

When fget fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling fget.

Signed-off-by: Zhouyang Jia 
---
 fs/coda/psdev.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/coda/psdev.c b/fs/coda/psdev.c
index c5234c2..55824cb 100644
--- a/fs/coda/psdev.c
+++ b/fs/coda/psdev.c
@@ -187,8 +187,11 @@ static ssize_t coda_psdev_write(struct file *file, const 
char __user *buf,
if (req->uc_opcode == CODA_OPEN_BY_FD) {
struct coda_open_by_fd_out *outp =
(struct coda_open_by_fd_out *)req->uc_data;
-   if (!outp->oh.result)
+   if (!outp->oh.result) {
outp->fh = fget(outp->fd);
+   if (!outp->fh)
+   return -EBADF;
+   }
}
 
 wake_up(&req->uc_sleep);
-- 
2.7.4

[PATCH] integrity: add error handling for kmem_cache_create

[Zhouyang Jia]

When kmem_cache_create fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling kmem_cache_create.

Signed-off-by: Zhouyang Jia 
---
 security/integrity/iint.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 149faa8..c074fd8 100644
--- a/security/integrity/iint.c
+++ b/security/integrity/iint.c
@@ -172,6 +172,9 @@ static int __init integrity_iintcache_init(void)
iint_cache =
kmem_cache_create("iint_cache", sizeof(struct integrity_iint_cache),
  0, SLAB_PANIC, init_once);
+   if (!iint_cache)
+   return -ENOMEM;
+
return 0;
 }
 security_initcall(integrity_iintcache_init);
-- 
2.7.4

[PATCH] proc: add error handling for kmem_cache_create

[Zhouyang Jia]

When kmem_cache_create fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling kmem_cache_create.

Signed-off-by: Zhouyang Jia 
---
 fs/proc/inode.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 2cf3b74..5d8b2d1 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -104,6 +104,9 @@ void __init proc_init_kmemcache(void)
pde_opener_cache =
kmem_cache_create("pde_opener", sizeof(struct pde_opener), 0,
  SLAB_ACCOUNT|SLAB_PANIC, NULL);
+   if (!proc_inode_cachep || !pde_opener_cache)
+   return -ENOMEM;
+
proc_dir_entry_cache = kmem_cache_create_usercopy(
"proc_dir_entry", sizeof(struct proc_dir_entry), 0, SLAB_PANIC,
offsetof(struct proc_dir_entry, inline_name),
-- 
2.7.4

[PATCH] inotify: add error handling for kmem_cache_create

[Zhouyang Jia]

When kmem_cache_create fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling kmem_cache_create.

Signed-off-by: Zhouyang Jia 
---
 fs/notify/inotify/inotify_user.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index ef32f36..0704bab 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -805,6 +805,8 @@ static int __init inotify_user_setup(void)
BUG_ON(hweight32(ALL_INOTIFY_BITS) != 21);
 
inotify_inode_mark_cachep = KMEM_CACHE(inotify_inode_mark, SLAB_PANIC);
+   if (!inotify_inode_mark_cachep)
+   return -ENOMEM;
 
inotify_max_queued_events = 16384;
init_user_ns.ucount_max[UCOUNT_INOTIFY_INSTANCES] = 128;
-- 
2.7.4

[PATCH] fanotify: add error handling for kmem_cache_create

[Zhouyang Jia]

When kmem_cache_create fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling kmem_cache_create.

Signed-off-by: Zhouyang Jia 
---
 fs/notify/fanotify/fanotify_user.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fs/notify/fanotify/fanotify_user.c 
b/fs/notify/fanotify/fanotify_user.c
index ec4d8c5..e3fa861 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -959,9 +959,14 @@ static int __init fanotify_user_setup(void)
 {
fanotify_mark_cache = KMEM_CACHE(fsnotify_mark, SLAB_PANIC);
fanotify_event_cachep = KMEM_CACHE(fanotify_event_info, SLAB_PANIC);
+   if (!fanotify_mark_cache || !fanotify_event_cachep)
+   return -ENOMEM;
+
if (IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS)) {
fanotify_perm_event_cachep =
KMEM_CACHE(fanotify_perm_event_info, SLAB_PANIC);
+   if (!fanotify_perm_event_cachep)
+   return -ENOMEM;
}
 
return 0;
-- 
2.7.4

[PATCH] fsnotify: add error handling for kmem_cache_create

[Zhouyang Jia]

When kmem_cache_create fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling kmem_cache_create.

Signed-off-by: Zhouyang Jia 
---
 fs/notify/dnotify/dnotify.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/notify/dnotify/dnotify.c b/fs/notify/dnotify/dnotify.c
index 63a1ca4..216b411 100644
--- a/fs/notify/dnotify/dnotify.c
+++ b/fs/notify/dnotify/dnotify.c
@@ -387,6 +387,9 @@ static int __init dnotify_init(void)
dnotify_struct_cache = KMEM_CACHE(dnotify_struct, SLAB_PANIC);
dnotify_mark_cache = KMEM_CACHE(dnotify_mark, SLAB_PANIC);
 
+   if (!dnotify_struct_cache || !dnotify_mark_cache)
+   return -ENOMEM;
+
dnotify_group = fsnotify_alloc_group(&dnotify_fsnotify_ops);
if (IS_ERR(dnotify_group))
panic("unable to allocate fsnotify group for dnotify\n");
-- 
2.7.4

[GIT PULL] FSI updates

[Benjamin Herrenschmidt]

Hi Greg !

There are a first round of updates of the FSI stack, aiming at reducing/removing
the gap with the OpenBMC tree and a first step in getting dependent drivers
upstream.

These changes significantly improve the FSI bitbanging driver performance
and reliability, and add the new "sbefifo" driver for communicating with
the POWER9 Self Boot Engine (which will be needed for some upcoming
additional drivers).

[ Apologies if I got part of the process wrong, I haven't
  sent a pull request in years ;-) ]

Cheers,
Ben.

The following changes since commit 8efcf34a263965e471e304f94d1f6799d42a:

  Merge tag 'armsoc-late' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-06-11 18:19:45 
-0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git 

for you to fetch changes up to 9f4a8a2d7f9d71093f41c4bb0ef8707e8145bad3:

  fsi/sbefifo: Add driver for the SBE FIFO (2018-06-12 14:05:39 +1000)


Andrew Jeffery (2):
  fsi: gpio: Trace busy count
  fsi: gpio: Remove unused 'id' variable

Benjamin Herrenschmidt (8):
  fsi/fsi-master-gpio: Sample input data on different clock phase
  fsi/fsi-master-gpio: Add "no-gpio-delays" option
  fsi/fsi-master-gpio: Reduce turnaround clocks
  fsi/fsi-master-gpio: Reduce dpoll clocks
  fsi/fsi-master-gpio: Delay sampling of FSI data input
  fsi/fsi-master-gpio: Implement CRC error recovery
  fsi/fsi-master-gpio: More error handling cleanup
  fsi/sbefifo: Add driver for the SBE FIFO

Eddie James (1):
  fsi: scom: Remove PIB reset during probe

Jeremy Kerr (4):
  fsi: gpio: Use a mutex to protect transfers
  fsi/gpio: Include command build in locked section
  fsi/gpio: Use relative-addressing commands
  fsi/master-gpio: Replace bit_bit lock with IRQ disable/enable

 arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts |1 +
 arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts |1 +
 arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts   |1 +
 drivers/fsi/Kconfig  |7 +
 drivers/fsi/Makefile |1 +
 drivers/fsi/fsi-master-gpio.c|  349 
+++
 drivers/fsi/fsi-sbefifo.c| 1005 

 drivers/fsi/fsi-scom.c   |8 -
 include/linux/fsi-sbefifo.h  |   33 
 include/trace/events/fsi_master_gpio.h   |   43 +
 10 files changed, 1362 insertions(+), 87 deletions(-)
 create mode 100644 drivers/fsi/fsi-sbefifo.c
 create mode 100644 include/linux/fsi-sbefifo.h

Re: [RESEND v2] dmaengine: pxa: add a default requestor policy

[Vinod Koul]

On 11-06-18, 21:54, Robert Jarzmik wrote:
> Vinod Koul  writes:
> 
> > On 09-06-18, 14:43, Robert Jarzmik wrote:
> >> Robert Jarzmik  writes:
> >> 
> >> > As what former drcmr -1 value meant, add a this as a default to each
> >> > channel, ie. that by default no requestor line is used.
> >> >
> >> > This is specifically used for network drivers smc91x and smc911x, and
> >> > needed for their port to slave maps.
> >> >
> >> > Cc: Arnd Bergmann 
> >> > Signed-off-by: Robert Jarzmik 
> >> > ---
> >> > Since v1: changed -1 to U32_MAX
> >> Hi Vinod,
> >> 
> >> Could I have your ack on this so that I add this one to the dma slave map 
> >> serie
> >> after the merge window is closed please ?
> >
> > Sorry I was thinking it would go thru dmaengine tree, please do
> > indicate if that is not the case. Nevertheless
> >
> > Acked-by: Vinod Koul 
> Thanks.
> 
> As this is a dependency to the serie, I'd rather take it, unless you insist, 
> in
> which case I'll rely on the fact that it will hit 4.19 cycle.

It fine if you take, just that it helps to indicate the route to take
for a patch :)

-- 
~Vinod

Re: [PATCH] perf report powerpc: Fix crash if callchain is empty

[Ravi Bangoria]

On 06/11/2018 04:10 PM, Sandipan Das wrote:
> For some cases, the callchain provided by the kernel may be
> empty. So, the callchain ip filtering code will cause a crash
> if we do not check whether the struct ip_callchain pointer is
> NULL before accessing any members.
> 
> This can be observed on a powerpc64le system running Fedora 27
> as shown below.
> 
>   # perf record -b -e cycles:u ls
> 
> Before applying this patch:
> 
>   # perf report --branch-history
> 
>   perf: Segmentation fault
>    backtrace 
>   perf[0x1027615c]
>   linux-vdso64.so.1(__kernel_sigtramp_rt64+0x0)[0x7fff856304d8]
>   perf(arch_skip_callchain_idx+0x44)[0x10257c58]
>   perf[0x1017f2e4]
>   perf(thread__resolve_callchain+0x124)[0x1017ff5c]
>   perf(sample__resolve_callchain+0xf0)[0x10172788]
>   ...
> 
> After applying this patch:
> 
>   # perf report --branch-history
> 
>   Samples: 25  of event 'cycles:u', Event count (approx.): 2306870
> Overhead  Source:LineSymbol   Shared Object
>   +   11.60%  _init+35736[.] _initls
>   +9.84%  strcoll_l.c:137[.] __strcoll_l  libc-2.26.so
>   +9.16%  memcpy.S:175   [.] __memcpy_power7  libc-2.26.so
>   +9.01%  gconv_charset.h:54 [.] _nl_find_locale  libc-2.26.so
>   +8.87%  dl-addr.c:52   [.] _dl_addr libc-2.26.so
>   +8.83%  _init+236  [.] _initls
>   ...
> 
> Reported-by: Ravi Bangoria 
> Signed-off-by: Sandipan Das 


Acked-by: Ravi Bangoria 

linux-next: Tree for Jun 12

[Stephen Rothwell]

Hi all,

Note: please do *not* add any v4.19 material to your linux-next included
branches until after v4.18-rc1 has been released.

Changes since 20180608:

The rcu tree gained a conflict against Linus' tree.

The drivers-x86 tree gained a build failure for which I reverted a commit.

Non-merge commits (relative to Linus' tree): 1986
 2008 files changed, 60173 insertions(+), 32163 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 278 trees (counting Linus' and 64 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (a2b7ab45b890 Merge tag 'linux-watchdog-4.18-rc1' of 
git://www.linux-watchdog.org/linux-watchdog)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (c90fca951e90 Merge tag 'powerpc-4.18-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage)
Merging arm64-fixes/for-next/fixes (82034c23fcbc arm64: Make sure permission 
updates happen for pmd/pud)
Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for 
platform devices)
Merging powerpc-fixes/fixes (faf37c44a105 powerpc/64s: Clear PCR on boot)
Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of 
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (349b71d6f427 net: dsa: add error handling for 
pskb_trim_rcsum)
Merging bpf/master (a343993c518c xsk: silence warning on memory allocation 
failure)
Merging ipsec/master (d6990976af7c vti6: fix PMTU caching and reporting on xmit)
Merging netfilter/master (d8e87fc6d11c netfilter: remove 
include/net/netfilter/nft_dup.h)
Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits)
Merging wireless-drivers/master (ab1068d6866e iwlwifi: pcie: compare with 
number of IRQs requested for, not number of CPUs)
Merging mac80211/master (885892fb378d mlx4_core: restore optimal ICM memory 
allocation)
Merging rdma-fixes/for-rc (a840c93ca758 IB/core: Fix error code for invalid GID 
entry)
Merging sound-current/for-linus (6d531e7b972c ALSA: emu10k1: add error handling 
for snd_ctl_add)
Merging sound-asoc-fixes/for-linus (2858e2cfc2ef Merge branch 'asoc-4.17' into 
asoc-linus)
Merging regmap-fixes/for-linus (97fe106a8027 Merge branch 'regmap-4.17' into 
regmap-linus)
Merging regulator-fixes/for-linus (59ce5f3e5530 Merge branch 'regulator-4.17' 
into regulator-linus)
Merging spi-fixes/for-linus (5d3257b8ea48 Merge branch 'spi-4.17' into 
spi-linus)
Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to 
pcie_print_link_status() messages)
Merging driver-core.current/driver-core-linus (3ca24ce9ff76 Merge branch 
'proc-cmdline')
Merging tty.current/tty-linus (3ca24ce9ff76 Merge branch 'proc-cmdline')
Merging usb.current/usb-linus (3ca24ce9ff76 Merge branch 'proc-cmdline')
Merging usb-gadget-fixes/fixes (6d08b06e67cd Linux 4.17-rc2)
Merging usb-serial-fixes/usb-linus (75bc37fefc44 Linux 4.17-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes (60cc43fc8884 Linux 4.17

[PATCH] gpio: max732x: add error handling for i2c_new_dummy

[Zhouyang Jia]

When i2c_new_dummy fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling i2c_new_dummy.

Signed-off-by: Zhouyang Jia 
---
 drivers/gpio/gpio-max732x.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpio/gpio-max732x.c b/drivers/gpio/gpio-max732x.c
index 9d8bcc6..f03cb0b 100644
--- a/drivers/gpio/gpio-max732x.c
+++ b/drivers/gpio/gpio-max732x.c
@@ -653,6 +653,12 @@ static int max732x_probe(struct i2c_client *client,
chip->client_group_a = client;
if (nr_port > 8) {
c = i2c_new_dummy(client->adapter, addr_b);
+   if (!c) {
+   dev_err(&client->dev,
+   "Failed to allocate I2C device\n");
+   ret = -ENODEV;
+   goto out_failed;
+   }
chip->client_group_b = chip->client_dummy = c;
}
break;
@@ -660,6 +666,12 @@ static int max732x_probe(struct i2c_client *client,
chip->client_group_b = client;
if (nr_port > 8) {
c = i2c_new_dummy(client->adapter, addr_a);
+   if (!c) {
+   dev_err(&client->dev,
+   "Failed to allocate I2C device\n");
+   ret = -ENODEV;
+   goto out_failed;
+   }
chip->client_group_a = chip->client_dummy = c;
}
break;
-- 
2.7.4

Re: [PATCH] RISC-V: Fix PTRACE_SETREGSET bug.

[Jim Wilson]

On Mon, Jun 11, 2018 at 5:46 PM, Palmer Dabbelt  wrote:
> Whoops, that's embarassing :).  I poked around and didn't see this anywhere
> else, so I'm not sure where we managed to obtain this particular pathology.

Comment say it was copied from tile which I think was just recently
removed.  But looking at older copy, tile has "struct pt_regs regs"
whereas riscv has "struct pt_regs *regs" and so tile needed the & and
riscv does not, but only one of the two ampersands was removed in the
riscv port.  My patch removes the other one.

Jim

[PATCH] staging: comedi: add error handling for vmap

[Zhouyang Jia]

When vmap fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling vmap.

Signed-off-by: Zhouyang Jia 
---
 drivers/staging/comedi/comedi_buf.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/comedi_buf.c 
b/drivers/staging/comedi/comedi_buf.c
index f693c2c..5e48693 100644
--- a/drivers/staging/comedi/comedi_buf.c
+++ b/drivers/staging/comedi/comedi_buf.c
@@ -132,9 +132,12 @@ static void __comedi_buf_alloc(struct comedi_device *dev,
spin_unlock_irqrestore(&s->spin_lock, flags);
 
/* vmap the prealloc_buf if all the pages were allocated */
-   if (i == n_pages)
+   if (i == n_pages) {
async->prealloc_buf = vmap(pages, n_pages, VM_MAP,
   COMEDI_PAGE_PROTECTION);
+   if (!async->prealloc_buf)
+   dev_err(dev->class_dev, "failed to vmap pages\n");
+   }
 
vfree(pages);
 }
-- 
2.7.4

[PATCH] ALSA: lx6464es: add error handling for pci_ioremap_bar

[Zhouyang Jia]

When pci_ioremap_bar fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling pci_ioremap_bar.

Signed-off-by: Zhouyang Jia 
---
 sound/pci/lx6464es/lx6464es.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/lx6464es/lx6464es.c b/sound/pci/lx6464es/lx6464es.c
index 9655b08..6157b6d 100644
--- a/sound/pci/lx6464es/lx6464es.c
+++ b/sound/pci/lx6464es/lx6464es.c
@@ -1016,6 +1016,10 @@ static int snd_lx6464es_create(struct snd_card *card,
 
/* dsp port */
chip->port_dsp_bar = pci_ioremap_bar(pci, 2);
+   if (!chip->port_dsp_bar) {
+   dev_err(card->dev, "cannot remap PCI memory region\n");
+   goto request_irq_failed;
+   }
 
err = request_threaded_irq(pci->irq, lx_interrupt, lx_threaded_irq,
   IRQF_SHARED, KBUILD_MODNAME, chip);
-- 
2.7.4

[PATCH] fmc: add error handling for kmemdup

[Zhouyang Jia]

When kmemdup fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling kmemdup.

Signed-off-by: Zhouyang Jia 
---
 drivers/fmc/fmc-fakedev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/fmc/fmc-fakedev.c b/drivers/fmc/fmc-fakedev.c
index 941d093..62d9046 100644
--- a/drivers/fmc/fmc-fakedev.c
+++ b/drivers/fmc/fmc-fakedev.c
@@ -282,6 +282,9 @@ static struct ff_dev *ff_dev_create(void)
for (i = 0; i < ff_nr_dev; i++) {
fmc = kmemdup(&ff_template_fmc, sizeof(ff_template_fmc),
  GFP_KERNEL);
+   if (!fmc)
+   return ERR_PTR(-ENOMEM);
+
fmc->hwdev = &ff->dev;
fmc->carrier_data = ff;
fmc->nr_slots = ff_nr_dev;
-- 
2.7.4

[PATCH] staging: rtl8712: add error handling for register_netdev

[Zhouyang Jia]

When register_netdev fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling register_netdev.

Signed-off-by: Zhouyang Jia 
---
 drivers/staging/rtl8712/hal_init.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/hal_init.c 
b/drivers/staging/rtl8712/hal_init.c
index 2a3f074..2b47e75 100644
--- a/drivers/staging/rtl8712/hal_init.c
+++ b/drivers/staging/rtl8712/hal_init.c
@@ -40,6 +40,7 @@
 static void rtl871x_load_fw_cb(const struct firmware *firmware, void *context)
 {
struct _adapter *padapter = context;
+   int rc;
 
complete(&padapter->rtl8712_fw_ready);
if (!firmware) {
@@ -53,7 +54,12 @@ static void rtl871x_load_fw_cb(const struct firmware 
*firmware, void *context)
}
padapter->fw = firmware;
/* firmware available - start netdev */
-   register_netdev(padapter->pnetdev);
+   rc = register_netdev(padapter->pnetdev);
+   if (rc) {
+   struct usb_device *udev = padapter->dvobjpriv.pusbdev;
+
+   dev_err(&udev->dev, "r8712u: Unable to register netdev\n");
+   }
 }
 
 static const char firmware_file[] = "rtlwifi/rtl8712u.bin";
-- 
2.7.4

Re: [PATCH -mm -V3 03/21] mm, THP, swap: Support PMD swap mapping in swap_duplicate()

[Huang, Ying]

"Huang, Ying"  writes:
>> On Wed, May 23, 2018 at 04:26:07PM +0800, Huang, Ying wrote:
>>> @@ -3516,11 +3512,39 @@ static int __swap_duplicate(swp_entry_t entry, 
>>> unsigned char usage)
>>
>> Two comments about this part of __swap_duplicate as long as you're moving it 
>> to
>> another function:
>>
>>} else if (count || has_cache) {
>>
>>  if ((count & ~COUNT_CONTINUED) < SWAP_MAP_MAX)  /* #1   */
>>  count += usage;
>>  else if ((count & ~COUNT_CONTINUED) > SWAP_MAP_MAX) /* #2   */
>>  err = -EINVAL;
>>
>> #1:  __swap_duplicate_locked might use
>>
>> VM_BUG_ON(usage != SWAP_HAS_CACHE && usage != 1);
>>
>> to document the unstated assumption that usage is 1 (otherwise count could
>> overflow).
>
> Sounds good.  Will do this.

Found usage parameter of __swap_duplicate() could be SWAP_MAP_SHMEM too.
We can improve the parameter checking.  But that appears not belong to
this series.

Best Regards,
Huang, Ying

[PATCH] mtd: gpio_flash: add error handling for ioremap_nocache

[Zhouyang Jia]

When ioremap_nocache fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling ioremap_nocache.

Signed-off-by: Zhouyang Jia 
---
 drivers/mtd/maps/gpio-addr-flash.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/maps/gpio-addr-flash.c 
b/drivers/mtd/maps/gpio-addr-flash.c
index 385305e..7fbba02 100644
--- a/drivers/mtd/maps/gpio-addr-flash.c
+++ b/drivers/mtd/maps/gpio-addr-flash.c
@@ -242,6 +242,9 @@ static int gpio_flash_probe(struct platform_device *pdev)
state->map.phys   = NO_XIP;
state->map.map_priv_1 = (unsigned long)state;
 
+   if (!state->map.virt)
+   return -ENOMEM;
+
platform_set_drvdata(pdev, state);
 
i = 0;
-- 
2.7.4

[GIT PULL] NTB changes for v4.18

[Jon Mason]

Hello Linus,
Here are a few NTB changes for v4.18.  They were tested earlier today by
Dave Jiang, and have been in linux-next for some time.  Please consider
pulling them.

Thanks,
Jon



The following changes since commit 29dcea88779c856c7dc92040a0c01233263101d4:

  Linux 4.17 (2018-06-03 14:15:21 -0700)

are available in the Git repository at:

  git://github.com/jonmason/ntb tags/ntb-4.18

for you to fetch changes up to c9160b69258ef46ab62c27a09decb8fef311e700:

  ntb: ntb_transport: Replace GFP_ATOMIC with GFP_KERNEL in 
ntb_transport_create_queue (2018-06-11 15:20:59 -0400)


Reorg and clean-up of the Intel NTB driver, a trivial comment change,
and changes of GFP_ATOMIC to GFP_KERNEL where appropriate.


Dave Jiang (3):
  ntb: intel: header definitions refactor
  ntb: intel: split out the gen3 code
  ntb: intel: change references of skx to gen3

Jia-Ju Bai (2):
  ntb: ntb_transport: Replace GFP_ATOMIC with GFP_KERNEL in 
ntb_transport_setup_qp_mw
  ntb: ntb_transport: Replace GFP_ATOMIC with GFP_KERNEL in 
ntb_transport_create_queue

Wolfram Sang (1):
  NTB: ntb_hw_idt: fix typo 'can by' to 'can be'

 drivers/ntb/hw/idt/ntb_hw_idt.c|   2 +-
 drivers/ntb/hw/intel/Makefile  |   1 +
 .../ntb/hw/intel/{ntb_hw_intel.c => ntb_hw_gen1.c} | 713 ++---
 drivers/ntb/hw/intel/ntb_hw_gen1.h | 182 ++
 drivers/ntb/hw/intel/ntb_hw_gen3.c | 597 +
 drivers/ntb/hw/intel/ntb_hw_gen3.h | 110 
 drivers/ntb/hw/intel/ntb_hw_intel.h| 203 ++
 drivers/ntb/ntb_transport.c|   6 +-
 8 files changed, 1001 insertions(+), 813 deletions(-)
 rename drivers/ntb/hw/intel/{ntb_hw_intel.c => ntb_hw_gen1.c} (74%)
 create mode 100644 drivers/ntb/hw/intel/ntb_hw_gen1.h
 create mode 100644 drivers/ntb/hw/intel/ntb_hw_gen3.c
 create mode 100644 drivers/ntb/hw/intel/ntb_hw_gen3.h

Re: [PATCH 3/3] riscv: fix __user annotation for __copy_user()

[Luc Van Oostenryck]

On Mon, Jun 11, 2018 at 12:01:37PM -0700, Palmer Dabbelt wrote:
> On Sat, 09 Jun 2018 14:42:12 PDT (-0700), luc.vanoostenr...@gmail.com wrote:
> > On Sat, Jun 09, 2018 at 01:00:08PM -0700, Palmer Dabbelt wrote:
> > > On Fri, 08 Jun 2018 17:13:12 PDT (-0700), luc.vanoostenr...@gmail.com 
> > > wrote:
> > > > I tried it and ... the preprocessed asm is as expected:
> > > > .globl __asm_copy_to_user ; .balign 4 ; __asm_copy_to_user:
> > > > .globl __asm_copy_from_user ; .balign 4 ; __asm_copy_from_user:
> > > >
> > > >
> > > >  li t6, 0x0004
> > > >  csrs sstatus, t6
> > > >  ...
> > > >
> > > > But the nm -S returns different sizes for them:
> > > > 0004 006c T __asm_copy_from_user
> > > > 0002 006e T __asm_copy_to_user
> > > >
> > > > and the object code is:
> > > >  <__asm_copy_to_user-0x2>:
> > > >0:   0001nop
> > > >
> > > > 0002 <__asm_copy_to_user>:
> > > >2:   0001nop
> > > >
> > > > 0004 <__asm_copy_from_user>:
> > > >4:   00040fb7lui t6,0x40
> > > >8:   100fa073csrssstatus,t6
> > > >...
> > > >
> > > > Why these unnneded nops?
> > > > Is this a known problem of my toolchain (I use a plain gcc 7.3 +
> > > > binutils 2.29, both configured as riscv64-none-elf)?
> > > >
> > > > If I remove the two ENTRY() and use instead:
> > > > .globl __asm_copy_to_user ; __asm_copy_to_user:
> > > > .globl __asm_copy_from_user ; __asm_copy_from_user:
> > > > (IOW, I drop the .balign) then I get the expected result.
> > > > But well, this seems unrelated to the double ENTRY.
> > > >
> > > > I can't test it more for now because I've some link errors (which,
> > > > I understand are probably solved in the riscv tree of binutils).
> > > >
> > > > I'll send you the patch anyway since, as far as I understand the changes
> > > > specific to this copy_to/from_user is OK.
> > > 
> > > I think it's probably a bug in binutils-2.29 that should be fixed by
> > > 2.30 -- IIRC we had some bugs that looked like this and they got
> > > fixed, though it might be just in master (so 2.31).
> > 
> > I've tried binutils-2.30 and riscv-binutils-gdb, both still have
> > the problem and master binutils-gdb doesn't compile for me.
> > OTOH, everything is fine if I disabled CONFIG_RISCV_ISA_C.
> 
> OK, I'll try and figure out what's going on.  We've had a handful of
> headaches trying to get things like '.align 2; .align 2' to actually produce
> no NOPs for the second alignment directive, which is surprisingly
> complicated due to the aggressive linker relaxation we do.

OK. I imagine indeed but note that no linker is involved here so,
if the problem is still present, it must already be in the assembler.
 
> > With this, the RISC-V arch should be sparse clean.
> > I'll recheck after -rc1.
> 
> This will be part of the PR that I tag today, so I anticipate it'll be in.

Cool! 

-- Luc

Re: [PATCHv4 1/3] scripts: Preprocess module-common.lds

[kbuild test robot]

Hi Laura,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Laura-Abbott/scripts-Preprocess-module-common-lds/20180612-083632
config: openrisc-or1ksim_defconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

>> or1k-linux-ld: cannot open linker script file scripts/module-common.lds: No 
>> such file or directory

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 2/2] tpm: add support for nonblocking operation

[kbuild test robot]

Hi Tadeusz,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on next-20180608]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Tadeusz-Struk/tpm-add-ptr-to-the-tpm_space-struct-to-file_priv/20180612-082203
config: i386-randconfig-x008-201823 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

>> drivers/char//tpm/tpm-dev-common.c:223:1: warning: data definition has no 
>> type or storage class
__exitcall(tpm_dev_common_exit);
^~
>> drivers/char//tpm/tpm-dev-common.c:223:1: error: type defaults to 'int' in 
>> declaration of '__exitcall' [-Werror=implicit-int]
>> drivers/char//tpm/tpm-dev-common.c:223:1: warning: parameter names (without 
>> types) in function declaration
   drivers/char//tpm/tpm-dev-common.c:215:20: warning: 'tpm_dev_common_exit' 
defined but not used [-Wunused-function]
static void __exit tpm_dev_common_exit(void)
   ^~~
   cc1: some warnings being treated as errors

vim +223 drivers/char//tpm/tpm-dev-common.c

   222  
 > 223  __exitcall(tpm_dev_common_exit);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 14/39] ovl: stack file ops

[Al Viro]

On Tue, Jun 12, 2018 at 03:29:26AM +0100, Al Viro wrote:

> It might (or might not) work for the filesystems you'd been testing
> on, but it's a lot of trouble waiting to happen.  Hell, try and use
> ecryptfs as lower layer, see how fast it'll blow up.  Sure, it's
> a dumb testcase, but I don't see how to check if something more
> realistic is trouble-free.
> 
> I'd been trying to come up with some way to salvage that kludge of yours,
> but I don't see any solutions.  We don't have good proxies for "this
> filesystem might be unsafe as lower layer" ;-/

Note that anything that uses file_dentry() anywhere near ->open(),
->read_iter() or ->write_iter() is an instant trouble with your scheme.
Such as
int nfs_open(struct inode *inode, struct file *filp)
{
struct nfs_open_context *ctx;

ctx = alloc_nfs_open_context(file_dentry(filp), filp->f_mode, filp);
if (IS_ERR(ctx)) 
return PTR_ERR(ctx);
nfs_file_set_open_context(filp, ctx);
put_nfs_open_context(ctx);
nfs_fscache_open_file(inode, filp);
return 0;
}

You do want to support NFS for lower layers, right?

Re: [PATCH] Revert "debugfs: inode: debugfs_create_dir uses mode permission from parent"

[Mike Galbraith]

On Mon, 2018-06-11 at 11:12 -0700, Laura Abbott wrote:
> On 06/11/2018 02:28 AM, Thomas Richter wrote:
> > This reverts commit 95cde3c59966f6371b6bcd9e4e2da2ba64ee9775.
> > It breaks the ioctl(KVM_CREATE_VM) interface.
> > 
> 
> Can you elaborate a little more on how this breaks? Fedora has
> gotten at least one report of a failure in this ioctl and
> I'd like know if it's the same issue.

What I reported is here https://lkml.org/lkml/2018/6/8/79

-Mike

Re: [PATCH 14/39] ovl: stack file ops

[Al Viro]

On Mon, Jun 11, 2018 at 09:09:04AM +0200, Miklos Szeredi wrote:

[context: opening files in layers with unholy mix of overlayfs
->f_path and layer's ->f_inode/->f_op]

> I'd really like to get there some time but...
> 
> List of basic requirements:
> 
>  - Private mmap of overlay file shares page cache with lower file (and
> hence with all other overlays using the same lower file).
> 
>  - /proc/PID/maps shows correct path.
> 
> Thought about setting f_mapping/i_mapping of overlay file to that of
> underlying file.  But that breaks when doing a copy-up.  We can't just
> go and change those mapping pointers, assumption is that those remain
> constant (we'd need READ_ONCE() for all cases where we use the mapping
> more than once).  It's probably doable, but it's a large and fragile
> change.

We are really asking for trouble here - anything with e.g. ->read_iter()
using dentry will get in trouble with that kind of games.  Consider something
like

foo_read_iter(struct kiocb *iocb, struct iov_iter *to)
{
struct file *file = iocb->ki_filp;
struct foo_data *p = file->f_path.dentry->d_fsdata;
...
}

which will work just fine for files on foofs, where we have ->d_fsdata set
on lookup.  Now, try to use foofs as a layer; suddenly, you get foofs
files with ->f_path.dentry being *overlayfs* dentry, with ->d_fsdata
being nothing like struct foo_data *.

Better yet, consider

foo_open(struct inode *inode, struct file *file)
{
struct dentry *dentry = file->f_path.dentry;
...
foo_add_splat(dentry, splat);
...
}
where foo_add_splat() inserts struct foo_splat into an hlist starting
in dentry->d_fsdata.  That's not a pure theory - we *do* have ->open()
instances doing things of that sort.  That'll bugger overlayfs quite
badly, not to mention that foofs methods won't be happy with overlayfs
dentries.

It might (or might not) work for the filesystems you'd been testing
on, but it's a lot of trouble waiting to happen.  Hell, try and use
ecryptfs as lower layer, see how fast it'll blow up.  Sure, it's
a dumb testcase, but I don't see how to check if something more
realistic is trouble-free.

I'd been trying to come up with some way to salvage that kludge of yours,
but I don't see any solutions.  We don't have good proxies for "this
filesystem might be unsafe as lower layer" ;-/

Frankly, it might be saner and safer to teach procfs (and similar
places) to do more than just use ->vm_file->f_path.  _That_ at least
is much more local in impact.

RE: [PATCH] KVM: x86: Expose CLDEMOTE CPU feature to guest VM

[Liu, Jingqi]

On 5/8/2018 12:30 AM, Paolo Bonzini wrote:

> 
> On 04/05/2018 05:55, Jingqi Liu wrote:
> > The CLDEMOTE instruction hints to hardware that the cache line that
> > contains the linear address should be moved("demoted") from the
> > cache(s) closest to the processor core to a level more distant from
> > the processor core. This may accelerate subsequent accesses to the
> > line by other cores in the same coherence domain, especially if the
> > line was written by the core that demotes the line.
> >
> > This patch exposes the cldemote feature to the guest.
> >
> > The release document ref below link:
> > https://software.intel.com/sites/default/files/managed/c5/15/\
> > architecture-instruction-set-extensions-programming-reference.pdf
> > This patch has a dependency on https://lkml.org/lkml/2018/4/23/928
> >
> > Signed-off-by: Jingqi Liu 
> > Signed-off-by: Wei Wang 
> 
> Thanks.  Note that the Signed-off-by chain for the patch looks strange, the
> submitter should be the last (because it is a chain).
> 
> In the meanwhile, Ingo, Thomas, would it be possible to get a topic branch for
> that patch ("[PATCH] x86/cpufeatures: Enumerate cldemote instruction")?
> 

I had re-sent the patch: https://lkml.org/lkml/2018/5/21/91

Hi Ingo, Thomas,
Would it be possible to get a topic branch for that patch ("[PATCH] 
x86/cpufeatures: Enumerate cldemote instruction")?

Hi Paolo,
Could you help to review this patch ?

Thanks
Jingqi

> Thanks,
> 
> Paolo
> 
> 
> > ---
> >  arch/x86/kvm/cpuid.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index
> > 82055b9..72d8c49 100644
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -403,7 +403,8 @@ static inline int __do_cpuid_ent(struct
> kvm_cpuid_entry2 *entry, u32 function,
> > const u32 kvm_cpuid_7_0_ecx_x86_features =
> > F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ |
> > F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI)
> |
> > -   F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) |
> F(AVX512_BITALG);
> > +   F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) |
> F(AVX512_BITALG) |
> > +   F(CLDEMOTE);
> >
> > /* cpuid 7.0.edx*/
> > const u32 kvm_cpuid_7_0_edx_x86_features =
> >

Re: [PATCHv4 1/3] scripts: Preprocess module-common.lds

[kbuild test robot]

Hi Laura,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Laura-Abbott/scripts-Preprocess-module-common-lds/20180612-083632
config: i386-randconfig-a1-201823 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ld: cannot open linker script file scripts/module-common.lds: No such file 
>> or directory

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 09/11] misc: throttler: Add core support for non-thermal throttling

[Brian Norris]

Hi!

A few comments, but I didn't get to finish a thorough review yet.


On Thu, Jun 07, 2018 at 11:12:12AM -0700, Matthias Kaehlcke wrote:
> The purpose of the throttler is to provide support for non-thermal
> throttling. Throttling is triggered by external event, e.g. the
> detection of a high battery discharge current, close to the OCP limit
> of the battery. The throttler is only in charge of the throttling, not
> the monitoring, which is done by another (possibly platform specific)
> driver.
> 
> Signed-off-by: Matthias Kaehlcke 
> ---
> Changes in v2:
> - completely reworked the driver to support configuration through OPPs, which
>   requires a more dynamic handling
> - added sysfs attribute to set the level for debugging and testing
> - Makefile: depend on Kconfig option to traverse throttler directory
> - Kconfig: removed 'default n'
> - added SPDX line instead of license boiler-plate
> - added entry to MAINTAINERS file
> 
> 
>  MAINTAINERS |   7 +
>  drivers/misc/Kconfig|   1 +
>  drivers/misc/Makefile   |   1 +
>  drivers/misc/throttler/Kconfig  |  14 +
>  drivers/misc/throttler/Makefile |   1 +
>  drivers/misc/throttler/core.c   | 642 
>  include/linux/throttler.h   |  11 +
>  7 files changed, 677 insertions(+)
>  create mode 100644 drivers/misc/throttler/Kconfig
>  create mode 100644 drivers/misc/throttler/Makefile
>  create mode 100644 drivers/misc/throttler/core.c
>  create mode 100644 include/linux/throttler.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 92e47b5b0480..f9550e5680ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13938,6 +13938,13 @@ T:   git 
> git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
>  S:   Maintained
>  F:   drivers/platform/x86/thinkpad_acpi.c
>  
> +THROTTLER DRIVERS
> +M:   Matthias Kaehlcke 
> +L:   linux...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/misc/throttler/
> +F:   include/linux/throttler.h
> +
>  THUNDERBOLT DRIVER
>  M:   Andreas Noever 
>  M:   Michael Jamet 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 5d713008749b..691d9625d83c 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -513,4 +513,5 @@ source "drivers/misc/echo/Kconfig"
>  source "drivers/misc/cxl/Kconfig"
>  source "drivers/misc/ocxl/Kconfig"
>  source "drivers/misc/cardreader/Kconfig"
> +source "drivers/misc/throttler/Kconfig"
>  endmenu
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 20be70c3f118..b549ccad5215 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -57,3 +57,4 @@ obj-$(CONFIG_ASPEED_LPC_SNOOP)  += aspeed-lpc-snoop.o
>  obj-$(CONFIG_PCI_ENDPOINT_TEST)  += pci_endpoint_test.o
>  obj-$(CONFIG_OCXL)   += ocxl/
>  obj-$(CONFIG_MISC_RTSX)  += cardreader/
> +obj-$(CONFIG_THROTTLER)  += throttler/
> diff --git a/drivers/misc/throttler/Kconfig b/drivers/misc/throttler/Kconfig
> new file mode 100644
> index ..e561f1df5085
> --- /dev/null
> +++ b/drivers/misc/throttler/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +menuconfig THROTTLER
> + bool "Throttler support"
> + depends on OF
> + select CPU_FREQ
> + select PM_DEVFREQ

I'm curious whether we're actually truly compile-time dependent on
{CPU,DEV}FREQ? It seems like those subsystems mostly stub out stuff so
they fall back to no-ops if not built in.

I know that's not very useful for your existing throttler, since it
wouldn't be very effective if one or both were disabled.

> + help
> +   This option enables core support for non-thermal throttling of CPUs
> +   and devfreq devices.
> +
> +   Note that you also need a event monitor module usually called
> +   *_throttler.
> +
> diff --git a/drivers/misc/throttler/Makefile b/drivers/misc/throttler/Makefile
> new file mode 100644
> index ..c8d920cee315
> --- /dev/null
> +++ b/drivers/misc/throttler/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_THROTTLER)  += core.o
> diff --git a/drivers/misc/throttler/core.c b/drivers/misc/throttler/core.c
> new file mode 100644
> index ..15b50c111032
> --- /dev/null
> +++ b/drivers/misc/throttler/core.c
> @@ -0,0 +1,642 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Core code for non-thermal throttling
> + *
> + * Copyright (C) 2018 Google, Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Non-thermal throttling: throttling of system components in response to
> + * external events (e.g. high battery discharge current).
> + *
> + * The throttler supports throttling through cpufreq and devfreq. Multiple
> + * levels of throttling can be configured. At level 0 no throttling is
> + * active on behalf of the throttler, for values > 0 throttling is typically
> + 

RE: [PATCH v9 09/12] KVM: x86: Introduce a function to initialize the PT configuration

[Kang, Luwei]

> >>> + /* Initialize and clear the no dependency bits */
> >>> + vmx->pt_desc.ctl_bitmask = ~0ULL;
> >> This looks redundant, doesn't it?
> > This is a bit mask for RTIT_CTL MSR and it will make & with the value of 
> > RTIT_CLT from guest.
> > The reserved bits will be 1 in this bit mask and the setable  bits are 0.
> >
> >>> + vmx->pt_desc.ctl_bitmask = ~(RTIT_CTL_TRACEEN | RTIT_CTL_OS |
> >>> + RTIT_CTL_USR | RTIT_CTL_TSC_EN |
> >> RTIT_CTL_DISRETC);
> 
> But it's set twice, so the first assignment is superfluous.

Oh, I see. Will remove it.

Thanks,
Luwei Kang

Re: [PATCHv4 0/3] Salted build ids via linker sections

[Linus Torvalds]

On Mon, Jun 11, 2018 at 5:32 PM Laura Abbott  wrote:
>
> v4 takes Linus' suggestion of using linker fill to insert the build id.

Heh. I was hoping somebody would come up with a way to avoid my crazy
"put a LONG into an aligned section to cause alignment filling" thing.

Because somebody will ask "what the heck is the meaning of that
LONG(0xffaa5500) thing"?

But since I couldn't come up with anything better myself, I guess I
can't complain.

> This is pretty small but I also know people can be picky so I'm open to 
> opinions or suggestions here.

I'm not sure anybody will care about 32 bytes. Although maybe it could
be made to be just 8 bytes (four bytes to force padding, four bytes of
padding) and put somewhere where you'll have more padding anyway due
to being followed by a PAGE_ALIGNED section or something?

I don't think we care.

Anyway, I'll pull this if somebody sends it to me, it seems to be
fairly minimally invasive and apparently fixes an issue for distros.

Linus

Re: [PATCH -mm -V3 03/21] mm, THP, swap: Support PMD swap mapping in swap_duplicate()

[Huang, Ying]

Hi, Daniel,

Thanks for your effort to review this series.

Daniel Jordan  writes:

> Hi,
>
> The series up to and including this patch doesn't build.  For this patch we
> need:
>
> diff --git a/mm/swap_state.c b/mm/swap_state.c
> index c6b3eab73fde..2f2d07627113 100644
> --- a/mm/swap_state.c
> +++ b/mm/swap_state.c
> @@ -433,7 +433,7 @@ struct page *__read_swap_cache_async(swp_entry_t entry, 
> gfp_t gfp_mask,
> /*
>  * Swap entry may have been freed since our caller observed 
> it.
>  */
> -   err = swapcache_prepare(entry);
> +   err = swapcache_prepare(entry, false);
> if (err == -EEXIST) {
> radix_tree_preload_end();
> /*

Thanks for pointing this out!  Will change in the next version.

>
> On Wed, May 23, 2018 at 04:26:07PM +0800, Huang, Ying wrote:
>> @@ -3516,11 +3512,39 @@ static int __swap_duplicate(swp_entry_t entry, 
>> unsigned char usage)
>
> Two comments about this part of __swap_duplicate as long as you're moving it 
> to
> another function:
>
>} else if (count || has_cache) {
>
>   if ((count & ~COUNT_CONTINUED) < SWAP_MAP_MAX)  /* #1   */
>   count += usage;
>   else if ((count & ~COUNT_CONTINUED) > SWAP_MAP_MAX) /* #2   */
>   err = -EINVAL;
>
> #1:  __swap_duplicate_locked might use
>
> VM_BUG_ON(usage != SWAP_HAS_CACHE && usage != 1);
>
> to document the unstated assumption that usage is 1 (otherwise count could
> overflow).

Sounds good.  Will do this.

> #2:  We've masked off SWAP_HAS_CACHE and COUNT_CONTINUED, and already checked
> for SWAP_MAP_BAD, so I think condition #2 always fails and can just be 
> removed.

I think this is used to check some software bug.  For example,
SWAP_MAP_SHMEM will yield true here.

>> +#ifdef CONFIG_THP_SWAP
>> +static int __swap_duplicate_cluster(swp_entry_t *entry, unsigned char usage)
> ...
>> +} else {
>> +for (i = 0; i < SWAPFILE_CLUSTER; i++) {
>> +retry:
>> +err = __swap_duplicate_locked(si, offset + i, 1);
>
> I guess usage is assumed to be 1 at this point (__swap_duplicate_locked makes
> the same assumption).  Maybe make this explicit with
>
>   err = __swap_duplicate_locked(si, offset + i, usage);
>
> , use 'usage' in cluster_set_count and __swap_entry_free too, and then
> earlier have a
>
>VM_BUG_ON(usage != SWAP_HAS_CACHE && usage != 1);
>
> ?

Yes.  I will fix this.  And we can just check it in
__swap_duplicate_locked() and all these will be covered.

>> +#else
>> +static inline int __swap_duplicate_cluster(swp_entry_t *entry,
>
> This doesn't need inline.

Why not?  This is just a one line stub.

> Not related to your changes, but while we're here, the comment with
> SWAP_HAS_CONT in swap_count() could be deleted: I don't think there ever was a
> SWAP_HAS_CONT.

Yes.  We should correct this.  Because this should go to a separate patch,
would you mind to submit a patch to fix it?

> The rest looks ok up to this point.

Thanks!

Best Regards,
Huang, Ying