Re: [PATCH 3/4] dt-bindings: mt8173-mtu3: add generic compatible and rename file

[Chunfeng Yun]

On Thu, 2017-08-10 at 21:54 -0500, Rob Herring wrote:
> On Tue, Aug 08, 2017 at 01:42:51PM +0800, Chunfeng Yun wrote:
> > The mt8173-mtu3.txt actually holds the bindings for all mediatek
> > SoCs with usb3 DRD IP, so add a generic compatible and change the
> > name to mtu3.txt.
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../bindings/usb/{mt8173-mtu3.txt => mtu3.txt} |6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >  rename Documentation/devicetree/bindings/usb/{mt8173-mtu3.txt => mtu3.txt} 
> > (95%)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
> > b/Documentation/devicetree/bindings/usb/mtu3.txt
> > similarity index 95%
> > rename from Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > rename to Documentation/devicetree/bindings/usb/mtu3.txt
> > index 1d7c3bc..832741d 100644
> > --- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > +++ b/Documentation/devicetree/bindings/usb/mtu3.txt
> 
> mediatek,mtu3.txt
Ok
> 
> > @@ -1,7 +1,9 @@
> >  The device node for Mediatek USB3.0 DRD controller
> >  
> >  Required properties:
> > - - compatible : should be "mediatek,mt8173-mtu3"
> > + - compatible : should be one of
> > +   "mediatek,mt8173-mtu3" (deprecated, use "mediatek,mtu3" instead),
> 
> NAK. You can add generic compatibles, but you need SoC specific ones in 
> addition.
It's for backward compatibility

> 
> > +   "mediatek,mtu3"
Is it appropriate if changed to "mediatek,generic-mtu3"?

> >   - reg : specifies physical base address and size of the registers
> >   - reg-names: should be "mac" for device IP and "ippc" for IP port control
> >   - interrupts : interrupt used by the device IP
> > @@ -44,7 +46,7 @@ Optional properties:
> >  Sub-nodes:
> >  The xhci should be added as subnode to mtu3 as shown in the following 
> > example
> >  if host mode is enabled. The DT binding details of xhci can be found in:
> > -Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > +Documentation/devicetree/bindings/usb/xhci-mtk.txt
> 
> This should be in the patch that renames this file.
Ok
> 
> >  
> >  Example:
> >  ssusb: usb@11271000 {
> > -- 
> > 1.7.9.5
> > 

Re: [PATCH 4/4] dt-bindings: mt8173-xhci: add generic compatible and rename file

[Chunfeng Yun]

On Thu, 2017-08-10 at 21:56 -0500, Rob Herring wrote:
> On Tue, Aug 08, 2017 at 01:42:52PM +0800, Chunfeng Yun wrote:
> > The mt8173-xhci.txt actually holds the bindings for all mediatek
> > SoCs with xHCI controller, so add a generic compatible and change
> > the name to xhci-mtk.txt to reflect that.
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../bindings/usb/{mt8173-xhci.txt => xhci-mtk.txt} |   10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >  rename Documentation/devicetree/bindings/usb/{mt8173-xhci.txt => 
> > xhci-mtk.txt} (92%)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
> > b/Documentation/devicetree/bindings/usb/xhci-mtk.txt
> > similarity index 92%
> > rename from Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > rename to Documentation/devicetree/bindings/usb/xhci-mtk.txt
> 
> mediatek,mtk-xhci.txt
Ok
> 
> > index 0acfc8a..1ce77c7 100644
> > --- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > +++ b/Documentation/devicetree/bindings/usb/xhci-mtk.txt
> > @@ -11,7 +11,9 @@ into two parts.
> >  
> >  
> >  Required properties:
> > - - compatible : should contain "mediatek,mt8173-xhci"
> > + - compatible : should be one of
> > +   "mediatek,mt8173-xhci" (deprecated, use "mediatek,xhci-mtk" instead),
> 
> NAK for same reason.
It's backward compatible
> 
> > +   "mediatek,xhci-mtk"
> 
> mediatek,mtk-xhci would be more in line with conventions.
Ok
> 
> >   - reg : specifies physical base address and size of the registers
> >   - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
> >   - interrupts : interrupt used by the controller
> > @@ -68,10 +70,12 @@ usb30: usb@1127 {
> >  
> >  In the case, xhci is added as subnode to mtu3. An example and the DT 
> > binding
> >  details of mtu3 can be found in:
> > -Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > +Documentation/devicetree/bindings/usb/mtu3.txt
> >  
> >  Required properties:
> > - - compatible : should contain "mediatek,mt8173-xhci"
> > + - compatible : should be one of
> > +   "mediatek,mt8173-xhci" (deprecated, use "mediatek,xhci-mtk" instead),
> > +   "mediatek,xhci-mtk"
> >   - reg : specifies physical base address and size of the registers
> >   - reg-names: should be "mac" for xHCI MAC
> >   - interrupts : interrupt used by the host controller
> > -- 
> > 1.7.9.5
> > 

Re: [PATCH v2 2/5] dt-bindings: input: Add document bindings for mtk-pmic-keys

[Chen Zhong]

Hi Rob,

On Thu, 2017-08-10 at 15:41 -0500, Rob Herring wrote:
> On Mon, Aug 07, 2017 at 09:57:42AM +0800, Chen Zhong wrote:
> > This patch adds the device tree binding documentation for the MediaTek
> > pmic keys found on PMIC MT6397/MT6323.
> > 
> > Signed-off-by: Chen Zhong 
> > ---
> >  .../devicetree/bindings/input/mtk-pmic-keys.txt|   36 
> > 
> >  1 file changed, 36 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt 
> > b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > new file mode 100644
> > index 000..c5b230f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> > @@ -0,0 +1,36 @@
> > +MediaTek MT6397/MT6323 PMIC Keys Device Driver
> > +
> > +There are two key functions provided by MT6397/MT6323 PMIC, pwrkey
> > +and homekey. The key functions are defined as the subnode of the function
> > +node provided by MT6397/MT6323 PMIC that is being defined as one kind
> > +of Muti-Function Device (MFD)
> > +
> > +For MT6397/MT6323 MFD bindings see:
> > +Documentation/devicetree/bindings/mfd/mt6397.txt
> > +
> > +Required properties:
> > +- compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys"
> > +- mediatek,pwrkey-code: Keycode of pwrkey
> > +
> > +Optional Properties:
> > +- mediatek,homekey-code: Keycode of homekey
> > +- mediatek,long-press-mode: Long press key shutdown setting, 1 for
> > +   pwrkey only, 2 for pwrkey/homekey together, others for disabled.
> > +- mediatek,long-press-duration: Long press key shutdown duration setting,
> > +   0/1/2/3 for 8/11/14/5 seconds.
> 
> Surely this could be a common property.

Sorry I'm not very clear about this. Could i move this to required
properties or remove the "mediatek" string here?

> 
> > +
> > +Example:
> > +
> > +   pmic: mt6397 {
> > +   compatible = "mediatek,mt6397";
> > +
> > +   ...
> > +
> > +   mt6397keys: mt6397keys {
> > +   compatible = "mediatek,mt6397-keys";
> > +   mediatek,pwrkey-code = <116>;
> > +   mediatek,homekey-code = <114>;
> 
> We have a standard properties for keycodes.

Could i write them like this way?

linux,keycodes = , 

> 
> > +   mediatek,long-press-mode = <1>;
> > +   mediatek,long-press-duration = <0>;
> > +   };
> > +   };
> > \ No newline at end of file
> > -- 
> > 1.7.9.5
> > 

Thanks.

[PATCH] Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB Add 2 ACPI IC ELAN0609, ELAN060B in the ACPI mapping table Signed-off-by: KT Liao

[KT Liao]

---
 drivers/input/mouse/elan_i2c_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/input/mouse/elan_i2c_core.c 
b/drivers/input/mouse/elan_i2c_core.c
index 3b616cb..0d111322 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1248,6 +1248,8 @@ static const struct acpi_device_id elan_acpi_id[] = {
{ "ELAN0100", 0 },
{ "ELAN0600", 0 },
{ "ELAN0605", 0 },
+   { "ELAN0609", 0 },
+   { "ELAN060B", 0 },
{ "ELAN1000", 0 },
{ }
 };
-- 
2.7.4

Re: [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer

[Michal Hocko]

On Fri 11-08-17 11:28:52, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > +/*
> > + * Checks whether a page fault on the given mm is still reliable.
> > + * This is no longer true if the oom reaper started to reap the
> > + * address space which is reflected by MMF_UNSTABLE flag set in
> > + * the mm. At that moment any !shared mapping would lose the content
> > + * and could cause a memory corruption (zero pages instead of the
> > + * original content).
> > + *
> > + * User should call this before establishing a page table entry for
> > + * a !shared mapping and under the proper page table lock.
> > + *
> > + * Return 0 when the PF is safe VM_FAULT_SIGBUS otherwise.
> > + */
> > +static inline int check_stable_address_space(struct mm_struct *mm)
> > +{
> > +   if (unlikely(test_bit(MMF_UNSTABLE, &mm->flags)))
> > +   return VM_FAULT_SIGBUS;
> > +   return 0;
> > +}
> > +
> 
> Will you explain the mechanism why random values are written instead of zeros
> so that this patch can actually fix the race problem?

I am not sure what you mean here. Were you able to see a write with an
unexpected content?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

[Vivek Gautam]

On Fri, Aug 11, 2017 at 5:33 AM, Martin K. Petersen
 wrote:
>
> Vivek,
>
>> Can you kindly review this patch series (for UFS controller changes)
>> and consider giving your Ack so that Kishon can pull in the series
>> through phy tree.
>
> SCSI piece looks OK.

Thank you Martin for your review.
>
> Would still like Subhash to review the rest.

Subhash is on vacation with limited access to emails. I will ask
his team to take a look.

regards
Vivek

>
> --
> Martin K. Petersen  Oracle Linux Engineering
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 4.12 004/106] scsi: sg: fix SG_DXFER_FROM_DEV transfers

[Johannes Thumshirn]

On Thu, Aug 10, 2017 at 08:11:34AM -0700, Greg KH wrote:
> else between it and the newer one?  Drop this and you provide a
> backport?  Something else?
> 
> Totally confusing...

Sorry for confusing you, here's the backport for your 4.12 stable branch,

Thanks,
Johannes

>From 469957522c4b356a313cb369e3e14fdac104370f Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn 
Date: Thu, 27 Jul 2017 09:11:26 +0200
Subject: [PATCH] scsi: sg: only check for dxfer_len greater than 256M

commit f930c7043663188429cd9b254e9d761edfc101ce upstream

Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the
sg_io_hdr_t::dxferp in order to determine if it is a valid request. The
only way we can check for bad requests is by checking if the length
exceeds 256M.

Signed-off-by: Johannes Thumshirn 
Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the
request)
Reported-by: Jason L Tibbitts III 
Tested-by: Jason L Tibbitts III 
Suggested-by: Doug Gilbert 
Cc: Doug Gilbert 
Cc: 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen 
---
 drivers/scsi/sg.c | 25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 82c33a6edbea..aa6f1debeaa7 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -751,29 +751,6 @@ sg_new_write(Sg_fd *sfp, struct file *file, const char 
__user *buf,
return count;
 }
 
-static bool sg_is_valid_dxfer(sg_io_hdr_t *hp)
-{
-   switch (hp->dxfer_direction) {
-   case SG_DXFER_NONE:
-   if (hp->dxferp || hp->dxfer_len > 0)
-   return false;
-   return true;
-   case SG_DXFER_TO_DEV:
-   case SG_DXFER_FROM_DEV:
-   case SG_DXFER_TO_FROM_DEV:
-   if (!hp->dxferp || hp->dxfer_len == 0)
-   return false;
-   return true;
-   case SG_DXFER_UNKNOWN:
-   if ((!hp->dxferp && hp->dxfer_len) ||
-   (hp->dxferp && hp->dxfer_len == 0))
-   return false;
-   return true;
-   default:
-   return false;
-   }
-}
-
 static int
 sg_common_write(Sg_fd * sfp, Sg_request * srp,
unsigned char *cmnd, int timeout, int blocking)
@@ -794,7 +771,7 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,
"sg_common_write:  scsi opcode=0x%02x, cmd_size=%d\n",
(int) cmnd[0], (int) hp->cmd_len));
 
-   if (!sg_is_valid_dxfer(hp))
+   if (hp->dxfer_len >= SZ_256M)
return -EINVAL;
 
k = sg_start_req(srp, cmnd);
-- 
2.12.3


-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCH v2 5/5] mfd: mt6397: Add PMIC keys support to MT6397 driver

[Chen Zhong]

On Tue, 2017-08-08 at 12:15 +0100, Lee Jones wrote:
> On Mon, 07 Aug 2017, Chen Zhong wrote:
> 
> > This patch adds compatible strings and interrupts for pmic keys
> > which serves as child device of MFD.
> > 
> > Signed-off-by: Chen Zhong 
> > ---
> >  drivers/mfd/mt6397-core.c |   36 +++-
> >  1 file changed, 35 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> > index 6546d7f..3c6a765 100644
> > --- a/drivers/mfd/mt6397-core.c
> > +++ b/drivers/mfd/mt6397-core.c
> > @@ -43,6 +43,30 @@
> > },
> >  };
> >  
> > +static const struct resource mt6323_keys_resources[] = {
> > +   {
> > +   .start = MT6323_IRQ_STATUS_PWRKEY,
> > +   .end   = MT6323_IRQ_STATUS_PWRKEY,
> > +   .flags = IORESOURCE_IRQ,
> > +   }, {
> > +   .start = MT6323_IRQ_STATUS_FCHRKEY,
> > +   .end   = MT6323_IRQ_STATUS_FCHRKEY,
> > +   .flags = IORESOURCE_IRQ,
> > +   },
> > +};
> > +
> > +static const struct resource mt6397_keys_resources[] = {
> > +   {
> > +   .start = MT6397_IRQ_PWRKEY,
> > +   .end   = MT6397_IRQ_PWRKEY,
> > +   .flags = IORESOURCE_IRQ,
> > +   }, {
> > +   .start = MT6397_IRQ_HOMEKEY,
> > +   .end   = MT6397_IRQ_HOMEKEY,
> > +   .flags = IORESOURCE_IRQ,
> > +   },
> > +};
> 
> We have better ways to define these now.
> 
> Please grep for "DEFINE_RES_"

I'll define these with "DEFINE_RES_IRQ" here, Thank you for your
suggestion.

> 
> >  static const struct mfd_cell mt6323_devs[] = {
> > {
> > .name = "mt6323-regulator",
> > @@ -50,6 +74,11 @@
> > }, {
> > .name = "mt6323-led",
> > .of_compatible = "mediatek,mt6323-led"
> > +   }, {
> > +   .name = "mtk-pmic-keys",
> > +   .num_resources = ARRAY_SIZE(mt6323_keys_resources),
> > +   .resources = mt6323_keys_resources,
> > +   .of_compatible = "mediatek,mt6323-keys"
> > },
> >  };
> >  
> > @@ -71,7 +100,12 @@
> > }, {
> > .name = "mt6397-pinctrl",
> > .of_compatible = "mediatek,mt6397-pinctrl",
> > -   },
> > +   }, {
> > +   .name = "mtk-pmic-keys",
> > +   .num_resources = ARRAY_SIZE(mt6397_keys_resources),
> > +   .resources = mt6397_keys_resources,
> > +   .of_compatible = "mediatek,mt6397-keys"
> > +   }
> >  };
> >  
> >  static void mt6397_irq_lock(struct irq_data *data)
> 

Re: [PATCH v2 0/4] KVM: optimize the kvm_vcpu_on_spin

[Cornelia Huck]

On Thu, 10 Aug 2017 09:18:09 -0400
Eric Farman  wrote:

> On 08/08/2017 04:14 AM, Longpeng (Mike) wrote:
> > 
> > 
> > On 2017/8/8 15:41, Cornelia Huck wrote:
> >   
> >> On Tue, 8 Aug 2017 12:05:31 +0800
> >> "Longpeng(Mike)"  wrote:
> >>  
> >>> This is a simple optimization for kvm_vcpu_on_spin, the
> >>> main idea is described in patch-1's commit msg.  
> >>
> >> I think this generally looks good now.
> >>  
> >>>
> >>> I did some tests base on the RFC version, the result shows
> >>> that it can improves the performance slightly.  
> >>
> >> Did you re-run tests on this version?  
> > 
> > 
> > Hi Cornelia,
> > 
> > I didn't re-run tests on V2. But the major difference between RFC and V2
> > is that V2 only cache result for X86 (s390/arm needn't) and V2 saves a
> > expensive operation ( 440-1400 cycles on my test machine ) for X86/VMX.
> > 
> > So I think V2's performance is at least the same as RFC or even slightly
> > better. :)
> >   
> >>
> >> I would also like to see some s390 numbers; unfortunately I only have a
> >> z/VM environment and any performance numbers would be nearly useless
> >> there. Maybe somebody within IBM with a better setup can run a quick
> >> test?  
> 
> Won't swear I didn't screw something up, but here's some quick numbers. 
> Host was 4.12.0 with and without this series, running QEMU 2.10.0-rc0. 
> Created 4 guests, each with 4 CPU (unpinned) and 4GB RAM.  VM1 did full 
> kernel compiles with kernbench, which took averages of 5 runs of 
> different job sizes (I threw away the "-j 1" numbers). VM2-VM4 ran cpu 
> burners on 2 of their 4 cpus.
> 
> Numbers from VM1 kernbench output, and the delta between runs:
> 
> load -j 3 before  after   delta
> Elapsed Time  183.178 182.58  -0.598
> User Time 534.19  531.52  -2.67
> System Time   32.538  33.37   0.832
> Percent CPU   308.8   309 0.2
> Context Switches  98484.6 99001   516.4
> Sleeps227347  228752  1405
> 
> load -j 16before  after   delta
> Elapsed Time  153.352 147.59  -5.762
> User Time 545.829 533.41  -12.419
> System Time   34.289  34.85   0.561
> Percent CPU   347.6   348 0.4
> Context Switches  160518  159120  -1398
> Sleeps240740  240536  -204

Thanks a lot, Eric!

The decreases in elapsed time look nice, and we probably should not
care about the increases reported.

Re: [PATCH 4.4 01/58] parisc: Increase thread and stack size to 32kb

[Helge Deller]

On 11.08.2017 03:33, Ben Hutchings wrote:
> On Wed, 2017-08-09 at 12:41 -0700, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch.  If anyone has any objections, please let me know.
>>
>> --
>>
>> From: Helge Deller 
>>
>> commit 8f8201dfed91a43ac38c899c82f81eef3d36afd9 upstream.
>>
>> Since kernel 4.11 the thread and irq stacks on parisc randomly overflow
>> the default size of 16k. The reason why stack usage suddenly grew is yet
>> unknown.
> 
> So we don't need this for 4.4.

Correct.

I had Cc: sta...@vger.kernel.org # 4.11+
in the commit itself:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8f8201dfed91a43ac38c899c82f81eef3d36afd9

Helge

> 
> Ben.
> 
>> Signed-off-by: Helge Deller 
>> Signed-off-by: Helge Deller 
>> Signed-off-by: Greg Kroah-Hartman 
>>
>> ---
>>  arch/parisc/include/asm/thread_info.h |2 +-
>>  arch/parisc/kernel/irq.c  |2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> --- a/arch/parisc/include/asm/thread_info.h
>> +++ b/arch/parisc/include/asm/thread_info.h
>> @@ -34,7 +34,7 @@ struct thread_info {
>>  
>>  /* thread information allocation */
>>  
>> -#define THREAD_SIZE_ORDER   2 /* PA-RISC requires at least 16k stack */
>> +#define THREAD_SIZE_ORDER   3 /* PA-RISC requires at least 32k stack */
>>  /* Be sure to hunt all references to this down when you change the size of
>>   * the kernel stack */
>>  #define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)
>> --- a/arch/parisc/kernel/irq.c
>> +++ b/arch/parisc/kernel/irq.c
>> @@ -380,7 +380,7 @@ static inline int eirr_to_irq(unsigned l
>>  /*
>>   * IRQ STACK - used for irq handler
>>   */
>> -#define IRQ_STACK_SIZE  (4096 << 2) /* 16k irq stack size */
>> +#define IRQ_STACK_SIZE  (4096 << 3) /* 32k irq stack size */
>>  
>>  union irq_stack_union {
>>  unsigned long stack[IRQ_STACK_SIZE/sizeof(unsigned long)];
>>
>>
> 

[PATCH 0/2] constify regmap_bus structures

[Julia Lawall]

These regmap_bus structures are only passed as the second argument to
__devm_regmap_init or __regmap_init, both of which are const, so the
regmap_bus structures can be const too.

Done with the help of Coccinelle.

---

 drivers/base/regmap/regmap-spi.c  |2 +-
 drivers/base/regmap/regmap-spmi.c |4 ++--
 drivers/bus/sunxi-rsb.c   |2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

[PATCH 1/2] regmap: constify regmap_bus structures

[Julia Lawall]

These regmap_bus structures are only passed as the second argument to
__devm_regmap_init or __regmap_init, both of which are const, so the
regmap_bus structures can be const too.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/base/regmap/regmap-spi.c  |2 +-
 drivers/base/regmap/regmap-spmi.c |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/regmap/regmap-spi.c b/drivers/base/regmap/regmap-spi.c
index edd9a83..c7150dd 100644
--- a/drivers/base/regmap/regmap-spi.c
+++ b/drivers/base/regmap/regmap-spi.c
@@ -102,7 +102,7 @@ static int regmap_spi_read(void *context,
return spi_write_then_read(spi, reg, reg_size, val, val_size);
 }
 
-static struct regmap_bus regmap_spi = {
+static const struct regmap_bus regmap_spi = {
.write = regmap_spi_write,
.gather_write = regmap_spi_gather_write,
.async_write = regmap_spi_async_write,
diff --git a/drivers/base/regmap/regmap-spmi.c 
b/drivers/base/regmap/regmap-spmi.c
index 4a36e41..0bfb8ed 100644
--- a/drivers/base/regmap/regmap-spmi.c
+++ b/drivers/base/regmap/regmap-spmi.c
@@ -83,7 +83,7 @@ static int regmap_spmi_base_write(void *context, const void 
*data,
 count - 1);
 }
 
-static struct regmap_bus regmap_spmi_base = {
+static const struct regmap_bus regmap_spmi_base = {
.read   = regmap_spmi_base_read,
.write  = regmap_spmi_base_write,
.gather_write   = regmap_spmi_base_gather_write,
@@ -203,7 +203,7 @@ static int regmap_spmi_ext_write(void *context, const void 
*data,
count - 2);
 }
 
-static struct regmap_bus regmap_spmi_ext = {
+static const struct regmap_bus regmap_spmi_ext = {
.read   = regmap_spmi_ext_read,
.write  = regmap_spmi_ext_write,
.gather_write   = regmap_spmi_ext_gather_write,

[PATCH 2/2] bus: sunxi-rsb: constify regmap_bus structures

[Julia Lawall]

This regmap_bus structure is only passed as the second argument to
__devm_regmap_init, which is const, so the regmap_bus structure can be
const too.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/bus/sunxi-rsb.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
index 795c9d9..dc3d781 100644
--- a/drivers/bus/sunxi-rsb.c
+++ b/drivers/bus/sunxi-rsb.c
@@ -423,7 +423,7 @@ static void regmap_sunxi_rsb_free_ctx(void *context)
kfree(ctx);
 }
 
-static struct regmap_bus regmap_sunxi_rsb = {
+static const struct regmap_bus regmap_sunxi_rsb = {
.reg_write = regmap_sunxi_rsb_reg_write,
.reg_read = regmap_sunxi_rsb_reg_read,
.free_context = regmap_sunxi_rsb_free_ctx,

Re: [PATCH] sym53c8xx: Avoid undefined behaviour in drivers/scsi/sym53c8xx_2/sym_hipd.c:762

[Johannes Thumshirn]

On Thu, Aug 10, 2017 at 09:08:49PM +0200, Helge Deller wrote:
> On parisc I see this UBSAN warning with a sym53c896:
> 
>  UBSAN: Undefined behaviour in ./drivers/scsi/sym53c8xx_2/sym_hipd.c:762:24
>  index -1903078336 is out of range for type 'u32 [7]'
> 
> Avoid this warning by switching to dev64_ul().
div64_ul() ^

Otherwise,
Reviewed-by: Johannes Thumshirn 


-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

[PATCH] pinctrl: aspeed: Fix hardware strap register write logic

[Yong Li]

The hardware strap register(SCU70) only accepts write ‘1’,
to clear it to ‘0’, must set bits(write  ‘1’) to SCU7C

Signed-off-by: Yong Li 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed.c | 9 +++--
 drivers/pinctrl/aspeed/pinctrl-aspeed.h | 1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
index a86a4d6..4305052 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
@@ -213,8 +213,13 @@ static int aspeed_sig_expr_set(const struct 
aspeed_sig_expr *expr,
if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP2)
continue;
 
-   ret = regmap_update_bits(maps[desc->ip], desc->reg,
-desc->mask, val);
+   if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP1 &&
+   val == 0)
+   ret = regmap_update_bits(maps[desc->ip], HW_REVISION_ID,
+   desc->mask, desc->mask);
+   else
+   ret = regmap_update_bits(maps[desc->ip], desc->reg,
+   desc->mask, val);
 
if (ret)
return ret;
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.h 
b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
index fa125db..d4d7f03 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.h
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
@@ -251,6 +251,7 @@
 #define SCU3C   0x3C /* System Reset Control/Status Register */
 #define SCU48   0x48 /* MAC Interface Clock Delay Setting */
 #define HW_STRAP1   0x70 /* AST2400 strapping is 33 bits, is split */
+#define HW_REVISION_ID  0x7C /* Silicon revision ID register */
 #define SCU80   0x80 /* Multi-function Pin Control #1 */
 #define SCU84   0x84 /* Multi-function Pin Control #2 */
 #define SCU88   0x88 /* Multi-function Pin Control #3 */
-- 
2.7.4

Re: [PATCH 1/3 v2] thermal: core: Add some new helper functions to free resources

[walter harms]

Am 08.08.2017 16:39, schrieb Christophe JAILLET:
> In order to easily free resources allocated by
> 'thermal_zone_create_device_groups()' we need 2 new helper functions.
> 
> The first one undoes 'thermal_zone_create_device_groups()'.
> The 2nd one undoes 'create_trip_attrs()', which is a function called by
> 'thermal_zone_create_device_groups()'.
> 
> Signed-off-by: Christophe JAILLET 
> ---
> These functions will be used in patch 2/3 in order to simplify
> 'thermal_release()'
> I've tried to implement it as close a possible as the way the resources have
> been allocated.
> However, in 'thermal_release()', the code is simplier without some
> additionnal 'if'.
> No sure if we should prefer consistancy with allocation or simplicity of code.
> ---
>  drivers/thermal/thermal_core.h  |  1 +
>  drivers/thermal/thermal_sysfs.c | 29 +
>  2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> index 2412b3759e16..27e3b1df7360 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -71,6 +71,7 @@ int thermal_build_list_of_policies(char *buf);
>  
>  /* sysfs I/F */
>  int thermal_zone_create_device_groups(struct thermal_zone_device *, int);
> +void thermal_zone_destroy_device_groups(struct thermal_zone_device *);
>  void thermal_cooling_device_setup_sysfs(struct thermal_cooling_device *);
>  /* used only at binding time */
>  ssize_t
> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
> index a694de907a26..eb95d64b9446 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -605,6 +605,24 @@ static int create_trip_attrs(struct thermal_zone_device 
> *tz, int mask)
>   return 0;
>  }
>  
> +/**
> + * destroy_trip_attrs() - create attributes for trip points
> + * @tz:  the thermal zone device
> + *
> + * helper function to free resources alocated by create_trip_attrs()
> + */
> +static void destroy_trip_attrs(struct thermal_zone_device *tz)
> +{
> + if (!tz)
> + return;
> +
> + kfree(tz->trip_type_attrs);
> + kfree(tz->trip_temp_attrs);
> + if (tz->ops->get_trip_hyst)
> + kfree(tz->trip_hyst_attrs);
> + kfree(tz->trips_attribute_group.attrs);
> +}
> +
>  int thermal_zone_create_device_groups(struct thermal_zone_device *tz,
> int mask)
>  {
> @@ -637,6 +655,17 @@ int thermal_zone_create_device_groups(struct 
> thermal_zone_device *tz,
>   return 0;
>  }
>  
> +void thermal_zone_destroy_device_groups(struct thermal_zone_device *tz)
> +{
> + if (!tz)
> + return;
> +
> + if (tz->trips)
> + destroy_trip_attrs(tz);

why the check for tz->trips ?
destroy_trip_attrs does not access tz->trips->

re,
 wh

> +
> + kfree(tz->device.groups);
> +}
> +
>  /* sys I/F for cooling device */
>  static ssize_t
>  thermal_cooling_device_type_show(struct device *dev,

[PATCH 2/2] dt-bindings: sound: add dmicen property in dmic driver

[Lin Huang]

there may use enable pin to control dmic start and stop,
so add this property in dt-bindings.

Signed-off-by: Lin Huang 
---
 Documentation/devicetree/bindings/sound/dmic.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/dmic.txt 
b/Documentation/devicetree/bindings/sound/dmic.txt
index a0c58f2..54c8ef6 100644
--- a/Documentation/devicetree/bindings/sound/dmic.txt
+++ b/Documentation/devicetree/bindings/sound/dmic.txt
@@ -5,8 +5,12 @@ This device support generic PDM digital microphone.
 Required properties:
- compatible: should be "dmic-codec".
 
+Optional properties:
+   - dmicen-gpios: GPIO specifier for dmic to control start and stop
+
 Example node:
 
dmic_codec: dmic@0 {
compatible = "dmic-codec";
+   dmicen-gpios = <&gpio4 3 GPIO_ACTIVE_HIGH>;
};
-- 
2.7.4

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

[Joerg Roedel]

Hey Sebastian,

On Thu, Aug 10, 2017 at 09:07:06PM +0200, Sebastian Ott wrote:
> With this patch pci hot-unplug fails with a use after free or refcounting
> issue - I'm currently trying to understand what's going on...

Let me know if I can help with debugging the issue, do you have a
backtrace for me to look at?


Regards,

Joerg

[PATCH 1/2] ASoC: codec: use enable pin to control dmic start and stop

[Lin Huang]

on some board use enable pin to control dmic start and stop,
so add this feature in dmic driver.

Signed-off-by: Lin Huang 
---
 sound/soc/codecs/Kconfig |  2 +-
 sound/soc/codecs/dmic.c  | 61 
 2 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index ccc5814..dff3586 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -61,7 +61,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_DA7219 if I2C
select SND_SOC_DA732X if I2C
select SND_SOC_DA9055 if I2C
-   select SND_SOC_DMIC
+   select SND_SOC_DMIC if GPIOLIB
select SND_SOC_BT_SCO
select SND_SOC_ES8328_SPI if SPI_MASTER
select SND_SOC_ES8328_I2C if I2C
diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
index 32b7a48..c4e5f47 100644
--- a/sound/soc/codecs/dmic.c
+++ b/sound/soc/codecs/dmic.c
@@ -19,6 +19,8 @@
  *
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +29,39 @@
 #include 
 #include 
 
+struct dmic_priv {
+   struct gpio_desc *dmic_en;
+};
+
+static int dmic_daiops_trigger(struct snd_pcm_substream *substream,
+   int cmd, struct snd_soc_dai *dai)
+{
+   struct snd_soc_codec *codec = dai->codec;
+   struct dmic_priv *dmic_data = snd_soc_codec_get_drvdata(codec);
+
+   if (!dmic_data->dmic_en)
+   return 0;
+
+   switch (cmd) {
+   case SNDRV_PCM_TRIGGER_START:
+   case SNDRV_PCM_TRIGGER_RESUME:
+   case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+   gpiod_set_value(dmic_data->dmic_en, 1);
+   break;
+   case SNDRV_PCM_TRIGGER_STOP:
+   case SNDRV_PCM_TRIGGER_SUSPEND:
+   case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+   gpiod_set_value(dmic_data->dmic_en, 0);
+   break;
+   }
+
+   return 0;
+}
+
+static const struct snd_soc_dai_ops dmic_dai_ops = {
+   .trigger= dmic_daiops_trigger,
+};
+
 static struct snd_soc_dai_driver dmic_dai = {
.name = "dmic-hifi",
.capture = {
@@ -38,8 +73,24 @@ static struct snd_soc_dai_driver dmic_dai = {
| SNDRV_PCM_FMTBIT_S24_LE
| SNDRV_PCM_FMTBIT_S16_LE,
},
+   .ops= &dmic_dai_ops,
 };
 
+static int dmic_codec_probe(struct snd_soc_codec *codec)
+{
+   struct dmic_priv *dmic_data = snd_soc_codec_get_drvdata(codec);
+
+   dmic_data->dmic_en = devm_gpiod_get_optional(codec->dev,
+   "dmicen", GPIOD_OUT_LOW);
+
+   if (IS_ERR(dmic_data->dmic_en))
+   return PTR_ERR(dmic_data->dmic_en);
+
+   snd_soc_codec_set_drvdata(codec, dmic_data);
+
+   return 0;
+}
+
 static const struct snd_soc_dapm_widget dmic_dapm_widgets[] = {
SND_SOC_DAPM_AIF_OUT("DMIC AIF", "Capture", 0,
 SND_SOC_NOPM, 0, 0),
@@ -51,6 +102,7 @@ static const struct snd_soc_dapm_route intercon[] = {
 };
 
 static struct snd_soc_codec_driver soc_dmic = {
+   .probe = dmic_codec_probe,
.dapm_widgets = dmic_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(dmic_dapm_widgets),
.dapm_routes = intercon,
@@ -59,6 +111,15 @@ static struct snd_soc_codec_driver soc_dmic = {
 
 static int dmic_dev_probe(struct platform_device *pdev)
 {
+   struct dmic_priv *dmic_data;
+
+   dmic_data = devm_kzalloc(&pdev->dev, sizeof(*dmic_data), GFP_KERNEL);
+
+   if (!dmic_data)
+   return -ENOMEM;
+
+   dev_set_drvdata(&pdev->dev, dmic_data);
+
return snd_soc_register_codec(&pdev->dev,
&soc_dmic, &dmic_dai, 1);
 }
-- 
2.7.4

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

[Helge Deller]

On 11.08.2017 02:15, Sergey Senozhatsky wrote:
> On (08/10/17 19:35), Helge Deller wrote:
>> Sometimes people seems unclear when to use the %pS or %pF printk format.
>> Adding some examples may help to avoid such mistakes.
>>
>> See for example commit 51d96dc2e2dc ("random: fix warning message on ia64 and
>> parisc") which fixed such a wrong format string.
>>
>> Signed-off-by: Helge Deller 
>>
>> diff --git a/Documentation/printk-formats.txt 
>> b/Documentation/printk-formats.txt
>> index 65ea591..be8c05b 100644
>> --- a/Documentation/printk-formats.txt
>> +++ b/Documentation/printk-formats.txt
>> @@ -73,6 +73,12 @@ actually function descriptors which must first be 
>> resolved. The ``F`` and
>>  ``f`` specifiers perform this resolution and then provide the same
>>  functionality as the ``S`` and ``s`` specifiers.
>>  
>> +Examples::
>> +
>> +printk("Called from %pS.\n", __builtin_return_address(0));
>> +printk("Called from %pS.\n", (void *)regs->ip);
>> +printk("Called from %pF.\n", &gettimeofday);
> 
> sorry, but how does it help?
> 
> 
> there is this paragraph
> 
> : On ia64, ppc64 and parisc64 architectures function pointers are
> : actually function descriptors which must first be resolved. The ``F`` and
> : ``f`` specifiers perform this resolution and then provide the same
> : functionality as the ``S`` and ``s`` specifiers.
> 
> which supposed to explain everything in details. the examples
> don't make it any `clearer', IMHO.

Experts surely do know what function descriptors are.
Nevertheless even those often get it wrong as can be seen in
various commits.

The hope with this patch is to show widely-used examples
and avoid additional commits afterwards to fix it up.

This patch was meant to be RFC.
If you decide not to take it, I'm fine as well.

> *may be* on "ia64, ppc64 and parisc64" we can somehow check
> that the pointer, which we pass as %pS, belongs to .text and
> print some build-time warnings. well, if it's actually a
> problem. dunno.

I think it's not needed. Those bugs will be seen and fixed.

Helge

[PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

[JamChen]

From: Jam Chen 

The vendor used the same PID(0x0001) for multiple touch IC controllers.
The newer ICs can support HID class and report the multitouch collection
in the descriptor. So they were handled by the hid-multitouch driver.
But some customized firmwares don't support multitouch protocol even if
driver have got the Win8 blob data.

Actually, those ICs only support the single touch function, and report
the mouse protocol by default. We can assign usbhid to handle them all.

Signed-off-by: Jam Chen 
---
 drivers/hid/hid-core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 9017dcc14502..df4696022488 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -828,6 +828,10 @@ static int hid_scan_report(struct hid_device *hid)
 */
hid->group = HID_GROUP_RMI;
break;
+   case USB_VENDOR_ID_DWAV:
+   if (hid->product == USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER)
+   hid->group = HID_GROUP_GENERIC;
+   break;
}
 
/* fall back to generic driver in case specific driver doesn't exist */
-- 
2.11.0

[PATCH v2] sched/topology: Introduce NUMA identity node sched domain

[Suravee Suthikulpanit]

On AMD Family17h-based (EPYC) system, a NUMA node can contain
upto 8 cores (16 threads) with the following topology.

 
 C0  | T0 T1 |||| T0 T1 | C4
 ||||
 C1  | T0 T1 | L3 || L3 | T0 T1 | C5
 ||||
 C2  | T0 T1 | #0 || #1 | T0 T1 | C6
 ||||
 C3  | T0 T1 |||| T0 T1 | C7
 

Here, there are 2 last-level (L3) caches per NUMA node. A socket can
contain upto 4 NUMA nodes, and a system can support upto 2 sockets.
With full system configuration, current scheduler creates 4 sched
domains:

  domain0 SMT   (span a core)
  domain1 MC(span a last-level-cache)
  domain2 NUMA  (span a socket: 4 nodes)
  domain3 NUMA  (span a system: 8 nodes)

Note that there is no domain to represent cpus spaning a NUMA node.
With this hierarchy of sched domains, the scheduler does not balance
properly in the following cases:

Case1:
When running 8 tasks, a properly balanced system should
schedule a task per NUMA node. This is not the case for
the current scheduler.

Case2:
Sometimes, threads are scheduled on the same cpu, while other
cpus are idle. This results in run-to-run inconsistency. For example:

  taskset -c 0-7 sysbench --num-threads=8 --test=cpu \
  --cpu-max-prime=10 run

Total execution time ranges from 25.1s to 33.5s depending on threads
placement, where 25.1s is when all 8 threads are balanced properly
across 8 cpus.

Introducing NUMA identity node sched domain, which is based on how
SRAT/SLIT table define a NUMA node. This results in the following
hierarchy of sched domains on the same system described above.

  domain0 SMT   (span a core)
  domain1 MC(span a last-level-cache)
  domain2 NODE  (span a NUMA node)
  domain3 NUMA  (span a socket: 4 nodes)
  domain4 NUMA  (span a system: 8 nodes)

This fixes the improper load balancing cases mentioned above.

Cc: sta...@vger.kernel.org
Signed-off-by: Suravee Suthikulpanit 
---
Changes from V1 (https://lkml.org/lkml/2017/8/10/540)
  * Update commit message to include performance number.
  * Change from NUMA_IDEN to NODE.
  * Fix code styling and update comments.

 kernel/sched/topology.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 79895ae..2dd5b11 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1335,6 +1335,10 @@ void sched_init_numa(void)
if (!sched_domains_numa_distance)
return;
 
+   /* Includes NUMA identity node at level 0. */
+   sched_domains_numa_distance[level++] = curr_distance;
+   sched_domains_numa_levels = level;
+
/*
 * O(nr_nodes^2) deduplicating selection sort -- in order to find the
 * unique distances in the node_distance() table.
@@ -1382,8 +1386,7 @@ void sched_init_numa(void)
return;
 
/*
-* 'level' contains the number of unique distances, excluding the
-* identity distance node_distance(i,i).
+* 'level' contains the number of unique distances
 *
 * The sched_domains_numa_distance[] array includes the actual distance
 * numbers.
@@ -1445,9 +1448,26 @@ void sched_init_numa(void)
tl[i] = sched_domain_topology[i];
 
/*
+* Do not setup NUMA node level if it has the same cpumask
+* as sched domain at previous level:
+* This is the case for system with:
+*  - LLC == NODE : LLC (MC) sched domain span a NUMA node.
+*  - DIE == NODE : DIE sched domain span a NUMA node.
+*
+* Assume all NUMA nodes are identical, so only check node 0.
+*/
+   if (!cpumask_equal(sched_domains_numa_masks[0][0], tl[i-1].mask(0))) {
+   tl[i++] = (struct sched_domain_topology_level){
+   .mask = sd_numa_mask,
+   .numa_level = 0,
+   SD_INIT_NAME(NODE)
+   };
+   }
+
+   /*
 * .. and append 'j' levels of NUMA goodness.
 */
-   for (j = 0; j < level; i++, j++) {
+   for (j = 1; j < level; i++, j++) {
tl[i] = (struct sched_domain_topology_level){
.mask = sd_numa_mask,
.sd_flags = cpu_numa_flags,
-- 
2.7.4

Re: [PATCH 1/2] reset: uniphier: remove sLD3 SoC support

[Philipp Zabel]

On Thu, 2017-08-10 at 15:30 -0500, Rob Herring wrote:
> On Sun, Aug 06, 2017 at 11:44:01AM +0900, Masahiro Yamada wrote:
> > This SoC is too old.  It is difficult to maintain any longer.
> > 
> > Signed-off-by: Masahiro Yamada 
> > ---
> > 
> >  .../devicetree/bindings/reset/uniphier-reset.txt   |  2 -
> >  drivers/reset/reset-uniphier.c | 48 
> > --
> >  2 files changed, 16 insertions(+), 34 deletions(-)
> 
> Acked-by: Rob Herring 

Added to the patch, thank you.

regards
Philipp

Re: [PATCH 07/11] arm64: add basic pointer authentication support

[Yao Qi]

Hi Mark,

On 19/07/17 17:01, Mark Rutland wrote:

+#define HWCAP_APIA   (1 << 16)


Can you rename it to HWCAP_ARM64_APIA or HWCAP_ARM_APIA?  When we
use it in user space, at least in GDB, we usually do this,

#ifndef HWCAP_APIA
#define HWCAP_APIA (1 << 16)
#endif

However, the code use this macro can be compiled on !arm64 host.
If HWCAP_APIA is defined on other !arm64 host and its value is not
(1 << 16), the program "aarch64_hwcap & HWCAP_APIA ? XXX : XXX;" is
wrong, and compiler doesn't complain.

I notice that mips, mn10300, sparc, and s390 define their HWCAP this
way, like HWCAP_SPARC_FLUSH, HWCAP_MIPS_R6, HWCAP_S390_DFP, etc.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

[PATCH] ASoC: kirkwood: Delete an error message for a failed memory allocation in kirkwood_i2s_dev_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 11 Aug 2017 09:35:33 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring 
---
 sound/soc/kirkwood/kirkwood-i2s.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/sound/soc/kirkwood/kirkwood-i2s.c 
b/sound/soc/kirkwood/kirkwood-i2s.c
index 3b09f71b9535..105a73cc5158 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -538,10 +538,9 @@ static int kirkwood_i2s_dev_probe(struct platform_device 
*pdev)
int err;
 
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
-   if (!priv) {
-   dev_err(&pdev->dev, "allocation failed\n");
+   if (!priv)
return -ENOMEM;
-   }
+
dev_set_drvdata(&pdev->dev, priv);
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-- 
2.14.0

Re: [PATCH v4 resend 1/2] rtmutex: update rt-mutex-design

[Alex Shi]

On 08/08/2017 04:30 AM, Jonathan Corbet wrote:
> On Mon, 31 Jul 2017 09:53:01 +0800
> Alex Shi  wrote:
> 
>> On 07/31/2017 09:50 AM, Alex Shi wrote:
>>> -Reviewers:  Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and Randy Dunlap
>>> +Original Reviewers:  Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and
>>> +Randy Dunlap
>>> +Update (7/6/2017) Reviewers: Steven Rostedt and Sebastian Siewior
>>>
>>
>> Hi Peter&Ingo,
>>
>> This patch had been reviewed and acked by Sebastian and Steven. Do you
>> still need a official 'reviewed-by' from them?
> 
> Given this, I've been assuming that these changes aren't meant to go
> through the docs tree; let me know if I should pick them up instead.
> 

Hi Jon,

Sorry for skip you here. Yes, if you like to pick them, please go ahead!

Best regards!
Alex

Re: [PATCH] KVM/x86: Increase max vcpu number to 352

[Lan Tianyu]

Hi Konrad:
Thanks for your review.

On 2017年08月11日 01:50, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 10, 2017 at 06:00:59PM +0800, Lan Tianyu wrote:
>> Intel Xeon phi chip will support 352 logical threads. For HPC usage
>> case, it will create a huge VM with vcpu number as same as host cpus. This
>> patch is to increase max vcpu number to 352.
> 
> Why not 1024 or 4096?

This is on demand. We can set a higher number since KVM already has
x2apic and vIOMMU interrupt remapping support.

> 
> Are there any issues with increasing the value from 288 to 352 right now?

No found.

> 
> Also perhaps this should be made in an Kconfig entry?

That will be anther option but I find different platforms will define
different MAX_VCPU. If we introduce a generic Kconfig entry, different
platforms should have different range.

Radim & Paolo, Could you give some input? In qemu thread, we will set
max vcpu to 8192 for x86 VM. In KVM, The length of vcpu pointer array in
struct kvm and dest_vcpu_bitmap in kvm_irq_delivery_to_apic() are
specified by KVM_MAX_VCPUS. Should we keep align with Qemu?

-- 
Best regards
Tianyu Lan

linux-next: manual merge of the akpm-current tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got conflicts in:

  include/linux/mm_types.h
  mm/huge_memory.c

between commit:

  8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")

from the tip tree and commits:

  16af97dc5a89 ("mm: migrate: prevent racy access to tlb_flush_pending")
  a9b802500ebb ("Revert "mm: numa: defer TLB flush for THP migration as long as 
possible"")

from the akpm-current tree.

The latter 2 are now in Linus' tree as well (but were not when I started
the day).

The only way forward I could see was to revert

  8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")

and the three following commits

  ff7a5fb0f1d5 ("overlayfs, locking: Remove smp_mb__before_spinlock() usage")
  d89e588ca408 ("locking: Introduce smp_mb__after_spinlock()")
  a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")

before merging the akpm-current tree again.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 2/2] mm, oom: fix potential data corruption when oom_reaper races with writer

[Tetsuo Handa]

Michal Hocko wrote:
> On Fri 11-08-17 11:28:52, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > +/*
> > > + * Checks whether a page fault on the given mm is still reliable.
> > > + * This is no longer true if the oom reaper started to reap the
> > > + * address space which is reflected by MMF_UNSTABLE flag set in
> > > + * the mm. At that moment any !shared mapping would lose the content
> > > + * and could cause a memory corruption (zero pages instead of the
> > > + * original content).
> > > + *
> > > + * User should call this before establishing a page table entry for
> > > + * a !shared mapping and under the proper page table lock.
> > > + *
> > > + * Return 0 when the PF is safe VM_FAULT_SIGBUS otherwise.
> > > + */
> > > +static inline int check_stable_address_space(struct mm_struct *mm)
> > > +{
> > > + if (unlikely(test_bit(MMF_UNSTABLE, &mm->flags)))
> > > + return VM_FAULT_SIGBUS;
> > > + return 0;
> > > +}
> > > +
> > 
> > Will you explain the mechanism why random values are written instead of 
> > zeros
> > so that this patch can actually fix the race problem?
> 
> I am not sure what you mean here. Were you able to see a write with an
> unexpected content?

Yes. See 
http://lkml.kernel.org/r/201708072228.faj09347.toovoffqjsh...@i-love.sakura.ne.jp
 .

[patch-rt] hotplug, hrtimer: Migrate expired/deferred timers during cpu offline

[Mike Galbraith]

The below fixes the list debug explosion up.

If we do not migrate expired/deferred timers during cpu offline, ->cb_entry
will be corrupted by online initialization of base->expired, leading to a
loud list debug complaint should someone call __remove_hrtimer() thereafter.

Signed-off-by: Mike Galvraith 
---
 kernel/time/hrtimer.c |   13 +
 1 file changed, 13 insertions(+)

--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1802,6 +1802,19 @@ static void migrate_hrtimer_list(struct
 */
enqueue_hrtimer(timer, new_base);
}
+
+   /*
+* Finally, migrate any expired timers deferred by RT.
+*/
+   while (!list_empty(&old_base->expired)) {
+   struct list_head *entry = old_base->expired.next;
+
+   timer = container_of(entry, struct hrtimer, cb_entry);
+   /* XXX: hm, perhaps defer again instead of enqueueing. */
+   __remove_hrtimer(timer, old_base, HRTIMER_STATE_ENQUEUED, 0);
+   timer->base = new_base;
+   enqueue_hrtimer(timer, new_base);
+   }
 }
 
 int hrtimers_dead_cpu(unsigned int scpu)

Re: [PATCH] arm: boot: dts: artpec6: Remove unnecessary interrupt-parent property from sub-nodes

[Surender Polsani]

On Tuesday 27 June 2017 05:57 PM, Niklas Cassel wrote:

Acked-by: Niklas Cassel 


Hi Nik, This patch has been Acknowledged but is not getting added / 
applied to the

respective git source tree. Please let me know if there is any problem.

Thanks
Surender


On 06/27/2017 02:15 PM, surend...@techveda.org wrote:

From: Surender Polsani 

"interrupt-parent" property is declared in root node, so it is global
to all nodes. This property is re-declared in few sub-nodes. To avoid
duplication this property is removed from following sub-nodes:
pmu, amba@0, amba@0/ethernet.

Signed-off-by: Surender Polsani 
---
  arch/arm/boot/dts/artpec6.dtsi | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
index 767cbe8..2ed1177 100644
--- a/arch/arm/boot/dts/artpec6.dtsi
+++ b/arch/arm/boot/dts/artpec6.dtsi
@@ -151,7 +151,6 @@
interrupts = ,
;
interrupt-affinity = <&cpu0>, <&cpu1>;
-   interrupt-parent = <&intc>;
};
  
  	pcie: pcie@f805 {

@@ -185,7 +184,6 @@
compatible = "simple-bus";
#address-cells = <0x1>;
#size-cells = <0x1>;
-   interrupt-parent = <&intc>;
ranges;
dma-ranges = <0x8000 0x 0x4000>;
dma-coherent;
@@ -195,7 +193,6 @@
clocks = <ð_phy_ref_clk>,
<&clkctrl ARTPEC6_CLK_ETH_ACLK>;
compatible = "snps,dwc-qos-ethernet-4.10";
-   interrupt-parent = <&intc>;
interrupts = ;
reg = <0xf801 0x4000>;
  

Re: [v6 00/15] complete deferred page initialization

[Michal Hocko]

[I am sorry I didn't get to your previous versions]

On Mon 07-08-17 16:38:34, Pavel Tatashin wrote:
[...]
> SMP machines can benefit from the DEFERRED_STRUCT_PAGE_INIT config option,
> which defers initializing struct pages until all cpus have been started so
> it can be done in parallel.
> 
> However, this feature is sub-optimal, because the deferred page
> initialization code expects that the struct pages have already been zeroed,
> and the zeroing is done early in boot with a single thread only.  Also, we
> access that memory and set flags before struct pages are initialized. All
> of this is fixed in this patchset.
> 
> In this work we do the following:
> - Never read access struct page until it was initialized

How is this enforced? What about pfn walkers? E.g. page_ext
initialization code (page owner in particular)

> - Never set any fields in struct pages before they are initialized
> - Zero struct page at the beginning of struct page initialization

Please give us a more highlevel description of how your reimplementation
works and how is the patchset organized. I will go through those patches
but it is always good to give an overview in the cover letter to make
the review easier.

> Performance improvements on x86 machine with 8 nodes:
> Intel(R) Xeon(R) CPU E7-8895 v3 @ 2.60GHz
> 
> Single threaded struct page init: 7.6s/T improvement
> Deferred struct page init: 10.2s/T improvement

What are before and after numbers and how have you measured them.
> 
> Pavel Tatashin (15):
>   x86/mm: reserve only exiting low pages
>   x86/mm: setting fields in deferred pages
>   sparc64/mm: setting fields in deferred pages
>   mm: discard memblock data later
>   mm: don't accessed uninitialized struct pages
>   sparc64: simplify vmemmap_populate
>   mm: defining memblock_virt_alloc_try_nid_raw
>   mm: zero struct pages during initialization
>   sparc64: optimized struct page zeroing
>   x86/kasan: explicitly zero kasan shadow memory
>   arm64/kasan: explicitly zero kasan shadow memory
>   mm: explicitly zero pagetable memory
>   mm: stop zeroing memory during allocation in vmemmap
>   mm: optimize early system hash allocations
>   mm: debug for raw alloctor
> 
>  arch/arm64/mm/kasan_init.c  |  42 ++
>  arch/sparc/include/asm/pgtable_64.h |  30 +++
>  arch/sparc/mm/init_64.c |  31 +++-
>  arch/x86/kernel/setup.c |   5 +-
>  arch/x86/mm/init_64.c   |   9 ++-
>  arch/x86/mm/kasan_init_64.c |  67 
>  include/linux/bootmem.h |  27 +++
>  include/linux/memblock.h|   9 ++-
>  include/linux/mm.h  |   9 +++
>  mm/memblock.c   | 152 
> 
>  mm/nobootmem.c  |  16 
>  mm/page_alloc.c |  31 +---
>  mm/sparse-vmemmap.c |  10 ++-
>  mm/sparse.c |   6 +-
>  14 files changed, 356 insertions(+), 88 deletions(-)
> 
> -- 
> 2.14.0

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v8 06/14] lockdep: Detect and handle hist_lock ring buffer overwrite

[Boqun Feng]

On Fri, Aug 11, 2017 at 12:43:28PM +0900, Byungchul Park wrote:
> On Thu, Aug 10, 2017 at 09:17:37PM +0800, Boqun Feng wrote:
> > > > > > @@ -4826,6 +4851,7 @@ static inline int depend_after(struct 
> > > > > > held_lock
> > > > > *hlock)
> > > > > >   * Check if the xhlock is valid, which would be false if,
> > > > > >   *
> > > > > >   *1. Has not used after initializaion yet.
> > > > > > + *2. Got invalidated.
> > > > > >   *
> > > > > >   * Remind hist_lock is implemented as a ring buffer.
> > > > > >   */
> > > > > > @@ -4857,6 +4883,7 @@ static void add_xhlock(struct held_lock 
> > > > > > *hlock)
> > > > > >
> > > > > > /* Initialize hist_lock's members */
> > > > > > xhlock->hlock = *hlock;
> > > > > > +   xhlock->hist_id = current->hist_id++;
> > > 
> > > Besides, is this code correct? Does this just make xhlock->hist_id
> > > one-less-than the curr->hist_id, which cause the invalidation every time
> > > you do ring buffer unwinding?
> > > 
> > > Regards,
> > > Boqun
> > > 
> > 
> > So basically, I'm suggesting do this on top of your patch, there is also
> > a fix in commit_xhlocks(), which I think you should swap the parameters
> > in before(...), no matter using task_struct::hist_id or using
> > task_struct::xhlock_idx as the timestamp.
> > 
> > Hope this could make my point more clear, and if I do miss something,
> > please point it out, thanks ;-)
> 
> Sorry for mis-understanding. I like your patch. I think it works.
> 

Thanks for taking a look at it ;-)

> Additionally.. See below..
> 
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 074872f016f8..886ba79bfc38 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -854,9 +854,6 @@ struct task_struct {
> > unsigned int xhlock_idx;
> > /* For restoring at history boundaries */
> > unsigned int xhlock_idx_hist[XHLOCK_NR];
> > -   unsigned int hist_id;
> > -   /* For overwrite check at each context exit */
> > -   unsigned int hist_id_save[XHLOCK_NR];
> >  #endif
> >  
> >  #ifdef CONFIG_UBSAN
> > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> > index 699fbeab1920..04c6c8d68e18 100644
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
> > @@ -4752,10 +4752,8 @@ void crossrelease_hist_start(enum xhlock_context_t c)
> >  {
> > struct task_struct *cur = current;
> >  
> > -   if (cur->xhlocks) {
> > +   if (cur->xhlocks)
> > cur->xhlock_idx_hist[c] = cur->xhlock_idx;
> > -   cur->hist_id_save[c] = cur->hist_id;
> > -   }
> >  }
> >  
> >  void crossrelease_hist_end(enum xhlock_context_t c)
> > @@ -4769,7 +4767,7 @@ void crossrelease_hist_end(enum xhlock_context_t c)
> > cur->xhlock_idx = idx;
> >  
> > /* Check if the ring was overwritten. */
> > -   if (h->hist_id != cur->hist_id_save[c])
> > +   if (h->hist_id != idx)
> > invalidate_xhlock(h);
> > }
> >  }
> > @@ -4849,7 +4847,7 @@ static void add_xhlock(struct held_lock *hlock)
> >  
> > /* Initialize hist_lock's members */
> > xhlock->hlock = *hlock;
> > -   xhlock->hist_id = current->hist_id++;
> > +   xhlock->hist_id = idx;
> >  
> > xhlock->trace.nr_entries = 0;
> > xhlock->trace.max_entries = MAX_XHLOCK_TRACE_ENTRIES;
> > @@ -5005,7 +5003,7 @@ static int commit_xhlock(struct cross_lock *xlock, 
> > struct hist_lock *xhlock)
> >  static void commit_xhlocks(struct cross_lock *xlock)
> >  {
> > unsigned int cur = current->xhlock_idx;
> > -   unsigned int prev_hist_id = xhlock(cur).hist_id;
> > +   unsigned int prev_hist_id = cur + 1;
> 
> I should have named it another. Could you suggest a better one?
> 

I think "prev" is fine, because I thought the "previous" means the
xhlock item we visit _previously_.

> > unsigned int i;
> >  
> > if (!graph_lock())
> > @@ -5030,7 +5028,7 @@ static void commit_xhlocks(struct cross_lock *xlock)
> >  * hist_id than the following one, which is impossible
> >  * otherwise.
> 
> Or we need to modify the comment so that the word 'prev' does not make
> readers confused. It was my mistake.
> 

I think the comment needs some help, but before you do it, could you
have another look at what Peter proposed previously? Note you have a
same_context_xhlock() check in the commit_xhlocks(), so the your
previous overwrite case actually could be detected, I think.

However, one thing may not be detected is this case:

pp
wrapped >   www

where p: process and w: worker.

, because p and w are in the same task_irq_context(). I discussed this
with Peter yesterday, and he has a good idea: unconditionally do a reset
on the ring buffer whenever we do a crossrelease_hist_end(XHLOCK_PROC).
Basically it means we empty the lock history whenever we finished a
worker function in a worker thread or we are about to return to
userspace after we finish th

Re: [PATCH v2 0/5] thermal: rockchip: add tsadc support in thermal driver and IPA thermal control for rk3328 in dts

[Zhang Rui]

On Fri, 2017-08-11 at 08:27 +0200, Heiko Stuebner wrote:
> Hi,
> 
> Am Freitag, 11. August 2017, 12:51:35 CEST schrieb Zhang Rui:
> > 
> > On Fri, 2017-08-04 at 16:06 +0800, Rocky Hao wrote:
> > > 
> > > This series patches add the tsadc support in thermal driver and
> > > in
> > > devicetree for rk3328.
> > > Also add thermal control with Intelligent Power Allocation (IPA)
> > > policy by default.  Please
> > > refer to https://developer.arm.com/open-source/intelligent-power-
> > > allo
> > > cation for more information
> > > about IPA.
> > > 
> > > Rocky Hao (5):
> > >   dt-bindings: rockchip-thermal: Support the RK3328 SoC
> > > compatible
> > >   thermal: rockchip: Support the RK3328 SOC in thermal driver
> > >   arm64: dts: rockchip: add tsadc node for rk3328 SoC
> > >   arm64: dts: rockchip: add thermal nodes for rk3328 SoC
> > >   arm64: dts: rockchip: Enable tsadc module on RK3328 eavluation
> > > board
> > > 
> > I can take this patch set if we have ACK for patch 3, 4 and 5.
> I would prefer if you would just apply patches 1+2 alone and I'd take
> the devicetree patches through my tree.
> 
> Having devicetree stuff mingle in a lot of trees produces unnecessary
> conflicts, so the general best practice is having code + binding.txt
> going through the driver tree and devicetree stuff through the
> platform
> tree.
> 
OKay, I will take patch 1 and 2 and queue them for next merge window.

thanks,
rui
> 
> Thanks
> Heiko
> 

Re: [PATCH 2/3] ARM: sun8i: sunxi-h3-h5: add phy-is-integrated property to internal PHY

[Corentin Labbe]

On Fri, Aug 11, 2017 at 10:42:51AM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Thu, Aug 10, 2017 at 4:51 PM, Corentin Labbe
>  wrote:
> > This patch add the new phy-is-integrated property to the internal PHY
> > node.
> >
> > Signed-off-by: Corentin Labbe 
> > ---
> >  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
> > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > index 4b599b5d26f6..54fc24e4c569 100644
> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > @@ -425,6 +425,7 @@
> > reg = <1>;
> > clocks = <&ccu CLK_BUS_EPHY>;
> > resets = <&ccu RST_BUS_EPHY>;
> > +   phy-is-integrated;
> 
> You also need to "delete" this property at the board level for
> any board that has the external PHY at address <1>. Otherwise
> they will stop working. This is due to the internal and external
> PHYs having the same path and node name in the device tree, so
> they are effectively the same node.
> 
> ChenYu
> 

They have not the same name, ext_rgmii_phy vs int_mii_phy.

Re: [v6 01/15] x86/mm: reserve only exiting low pages

[Michal Hocko]

On Mon 07-08-17 16:38:35, Pavel Tatashin wrote:
> Struct pages are initialized by going through __init_single_page(). Since
> the existing physical memory in memblock is represented in memblock.memory
> list, struct page for every page from this list goes through
> __init_single_page().

By a page _from_ this list you mean struct pages backing the physical
memory of the memblock lists?
 
> The second memblock list: memblock.reserved, manages the allocated memory.
> The memory that won't be available to kernel allocator. So, every page from
> this list goes through reserve_bootmem_region(), where certain struct page
> fields are set, the assumption being that the struct pages have been
> initialized beforehand.
> 
> In trim_low_memory_range() we unconditionally reserve memoryfrom PFN 0, but
> memblock.memory might start at a later PFN. For example, in QEMU,
> e820__memblock_setup() can use PFN 1 as the first PFN in memblock.memory,
> so PFN 0 is not on memblock.memory (and hence isn't initialized via
> __init_single_page) but is on memblock.reserved (and hence we set fields in
> the uninitialized struct page).
> 
> Currently, the struct page memory is always zeroed during allocation,
> which prevents this problem from being detected. But, if some asserts
> provided by CONFIG_DEBUG_VM_PGFLAGS are tighten, this problem may become
> visible in existing kernels.
> 
> In this patchset we will stop zeroing struct page memory during allocation.
> Therefore, this bug must be fixed in order to avoid random assert failures
> caused by CONFIG_DEBUG_VM_PGFLAGS triggers.
> 
> The fix is to reserve memory from the first existing PFN.

Hmm, I assume this is a result of some assert triggering, right? Which
one? Why don't we need the same treatment for other than x86 arch?

> Signed-off-by: Pavel Tatashin 
> Reviewed-by: Steven Sistare 
> Reviewed-by: Daniel Jordan 
> Reviewed-by: Bob Picco 

I guess that the review happened inhouse. I do not want to question its
value but it is rather strange to not hear the specific review comments
which might be useful in general and moreover even not include those
people on the CC list so they are aware of the follow up discussion.

> ---
>  arch/x86/kernel/setup.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 3486d0498800..489cdc141bcb 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -790,7 +790,10 @@ early_param("reservelow", parse_reservelow);
>  
>  static void __init trim_low_memory_range(void)
>  {
> - memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE));
> + unsigned long min_pfn = find_min_pfn_with_active_regions();
> + phys_addr_t base = min_pfn << PAGE_SHIFT;
> +
> + memblock_reserve(base, ALIGN(reserve_low, PAGE_SIZE));
>  }
>   
>  /*
> -- 
> 2.14.0

-- 
Michal Hocko
SUSE Labs

[PATCH v10 1/2] mmc: dw_mmc: move controller reset before driver init

[Li Wei]

This commit modifies dw_mci_probe(), it moves reset assertion before
drv_data->init(host)

Some driver needs to access controller registers in its .init() ops. So,
in order to make such access safe, we should do controller reset before
.init() being called.

Signed-off-by: Wei Li 
Signed-off-by: Guodong Xu 
Signed-off-by: Chen Jun 
---
 drivers/mmc/host/dw_mmc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a9dfb26972f2..f2fa928e1a12 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3067,6 +3067,12 @@ int dw_mci_probe(struct dw_mci *host)
goto err_clk_ciu;
}
 
+   if (!IS_ERR(host->pdata->rstc)) {
+   reset_control_assert(host->pdata->rstc);
+   usleep_range(10, 50);
+   reset_control_deassert(host->pdata->rstc);
+   }
+
if (drv_data && drv_data->init) {
ret = drv_data->init(host);
if (ret) {
@@ -3076,12 +3082,6 @@ int dw_mci_probe(struct dw_mci *host)
}
}
 
-   if (!IS_ERR(host->pdata->rstc)) {
-   reset_control_assert(host->pdata->rstc);
-   usleep_range(10, 50);
-   reset_control_deassert(host->pdata->rstc);
-   }
-
setup_timer(&host->cmd11_timer,
dw_mci_cmd11_timer, (unsigned long)host);
 
-- 
2.11.0

[PATCH v10 2/2] mmc: dw_mmc-k3: add sd support for hi3660

[Li Wei]

Add sd card support for hi3660 soc

Signed-off-by: Li Wei 
Signed-off-by: Chen Jun 
---
Major changes in v3:
 - solve review comments from Heiner Kallweit.
   *use the GENMASK and FIELD_PREP macros replace the bit shift operation.
   *use usleep_range() replace udelay() and mdelay().

Major changes in v4:
 - solve review comments from Jaehoon Chung.
   *move common register for dwmmc controller to dwmmc header file.
   *modify definitions type of some register variables.
   *get rid of the magic numbers.

Major changes in v5:
 - further improve coding style.

Major changes in v6:
 - solve review comments for Jaehoon Chung.
   *modify dw_mci_hi3660_set_ios() to static.
   *fix the comment style.

Major changes in v7:
 - solve review comments for John Stultz.
   *remove reset code in dw_mmc-k3.c,use reset in core mmc.

Major changes in v8:
 - modify patch v7 name and dependency order.

Major changes in v9:
 - solve review comments for Ulf Hansson.
   *use mmc_regulator_set_vqmmc() instead of regulator_set_voltage().

Major change in v10:
 - solve review comments for Shawn Lin.
   *remove PULL_DOWN/UP macro unused.

 drivers/mmc/host/dw_mmc-k3.c | 298 +++
 drivers/mmc/host/dw_mmc.h|   2 +
 2 files changed, 300 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
index e38fb0020bb1..64cda84b2302 100644
--- a/drivers/mmc/host/dw_mmc-k3.c
+++ b/drivers/mmc/host/dw_mmc-k3.c
@@ -8,6 +8,8 @@
  * (at your option) any later version.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -28,7 +30,35 @@
 #define AO_SCTRL_SEL18 BIT(10)
 #define AO_SCTRL_CTRL3 0x40C
 
+#define DWMMC_SDIO_ID 2
+
+#define SOC_SCTRL_SCPERCTRL5(0x314)
+#define SDCARD_IO_SEL18 BIT(2)
+
+#define SDCARD_RD_THRESHOLD  (512)
+
+#define GENCLK_DIV (7)
+
+#define GPIO_CLK_ENABLE   BIT(16)
+#define GPIO_CLK_DIV_MASK GENMASK(11, 8)
+#define GPIO_USE_SAMPLE_DLY_MASK  GENMASK(13, 13)
+#define UHS_REG_EXT_SAMPLE_PHASE_MASK GENMASK(20, 16)
+#define UHS_REG_EXT_SAMPLE_DRVPHASE_MASK  GENMASK(25, 21)
+#define UHS_REG_EXT_SAMPLE_DLY_MASK   GENMASK(30, 26)
+
+#define TIMING_MODE 3
+#define TIMING_CFG_NUM 10
+
+#define NUM_PHASES (40)
+
+#define ENABLE_SHIFT_MIN_SMPL (4)
+#define ENABLE_SHIFT_MAX_SMPL (12)
+#define USE_DLY_MIN_SMPL (11)
+#define USE_DLY_MAX_SMPL (14)
+
 struct k3_priv {
+   int ctrl_id;
+   u32 cur_speed;
struct regmap   *reg;
 };
 
@@ -38,6 +68,41 @@ static unsigned long dw_mci_hi6220_caps[] = {
0
 };
 
+struct hs_timing {
+   u32 drv_phase;
+   u32 smpl_dly;
+   u32 smpl_phase_max;
+   u32 smpl_phase_min;
+};
+
+struct hs_timing hs_timing_cfg[TIMING_MODE][TIMING_CFG_NUM] = {
+   { /* reserved */ },
+   { /* SD */
+   {7, 0, 15, 15,},  /* 0: LEGACY 400k */
+   {6, 0,  4,  4,},  /* 1: MMC_HS */
+   {6, 0,  3,  3,},  /* 2: SD_HS */
+   {6, 0, 15, 15,},  /* 3: SDR12 */
+   {6, 0,  2,  2,},  /* 4: SDR25 */
+   {4, 0, 11,  0,},  /* 5: SDR50 */
+   {6, 4, 15,  0,},  /* 6: SDR104 */
+   {0},  /* 7: DDR50 */
+   {0},  /* 8: DDR52 */
+   {0},  /* 9: HS200 */
+   },
+   { /* SDIO */
+   {7, 0, 15, 15,},  /* 0: LEGACY 400k */
+   {0},  /* 1: MMC_HS */
+   {6, 0, 15, 15,},  /* 2: SD_HS */
+   {6, 0, 15, 15,},  /* 3: SDR12 */
+   {6, 0,  0,  0,},  /* 4: SDR25 */
+   {4, 0, 12,  0,},  /* 5: SDR50 */
+   {5, 4, 15,  0,},  /* 6: SDR104 */
+   {0},  /* 7: DDR50 */
+   {0},  /* 8: DDR52 */
+   {0},  /* 9: HS200 */
+   }
+};
+
 static void dw_mci_k3_set_ios(struct dw_mci *host, struct mmc_ios *ios)
 {
int ret;
@@ -66,6 +131,10 @@ static int dw_mci_hi6220_parse_dt(struct dw_mci *host)
if (IS_ERR(priv->reg))
priv->reg = NULL;
 
+   priv->ctrl_id = of_alias_get_id(host->dev->of_node, "mshc");
+   if (priv->ctrl_id < 0)
+   priv->ctrl_id = 0;
+
host->priv = priv;
return 0;
 }
@@ -144,7 +213,236 @@ static const struct dw_mci_drv_data hi6220_data = {
.execute_tuning = dw_mci_hi6220_execute_tuning,
 };
 
+static void dw_mci_hs_set_timing(struct dw_mci *host, int timing,
+int smpl_phase)
+{
+   u32 drv_phase;
+   u32 smpl_dly;
+   u32 use_smpl_dly = 0;
+   u32 enable_shift = 0;
+   u32 reg_value;
+   int ctrl_id;
+   struct k3_priv *priv;
+
+   priv = host->priv;
+   ctrl_id = priv->ctrl_id;
+
+   drv_phase = hs_timing_cfg[ctrl_id][timing].drv_phase;
+   smpl_dly   = hs_timing_cfg[ctrl_id][timing].smpl_dly;
+   if (smpl_phase == -1)
+   smpl_phase =

[PATCH v4 0/5] add some properties for Rockchip usb2-phy and add rv1108 SoCs' support

[Frank Wang]

These series of patches add rockchip,usbgrf property and otg_mux interrupt for
rockchip usb2-phy. In addition, this change also add rv1108 usb2-phy support.

Changes from v3:
 - Updated the 'Acked-by' tag from Rob Herring .
 - Matched the SoC specific compatible string instead of companion_grf_quirk.

Changes from v2:
 - Amend otg-mux interrupt to be auto-detectable and update related dt-bindings.

Changes from v1:
 - Send the dt-bindings as a separate patch and cc devicetree list.

Frank Wang (5):
  phy: rockchip-inno-usb2: add support for rockchip,usbgrf property
  dt-bindings: phy-rockchip-inno-usb2: add rockchip,usbgrf property
  phy: rockchip-inno-usb2: add support for otg-mux interrupt
  dt-bindings: phy-rockchip-inno-usb2: add otg-mux interrupt
  phy: rockchip-inno-usb2: add support of usb2-phy for rv1108 SoCs

 .../bindings/phy/phy-rockchip-inno-usb2.txt|  11 +-
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c  | 215 -
 2 files changed, 174 insertions(+), 52 deletions(-)

-- 
2.0.0

[PATCH v4 4/5] dt-bindings: phy-rockchip-inno-usb2: add otg-mux interrupt

[Frank Wang]

Add otg-mux property to support multiplexed interrupt in otg-port
on some Rockchip SoC (e.g RV1108).

Signed-off-by: Frank Wang 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
index 69041373..68230b5 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -32,10 +32,14 @@ Required nodes : a sub-node is required for each port the 
phy provides.
 Required properties (port (child) node):
  - #phy-cells : must be 0. See ./phy-bindings.txt for details.
  - interrupts : specify an interrupt for each entry in interrupt-names.
- - interrupt-names : a list which shall be the following entries:
+ - interrupt-names : a list which should be one of the following cases:
+   Regular case:
* "otg-id" : for the otg id interrupt.
* "otg-bvalid" : for the otg vbus interrupt.
* "linestate" : for the host/otg linestate interrupt.
+   Some SoCs use one interrupt with the above muxed together, so for these
+   * "otg-mux" : otg-port interrupt, which mux otg-id/otg-bvalid/linestate
+   to one.
 
 Optional properties:
  - phy-supply : phandle to a regulator that provides power to VBUS.
-- 
2.0.0

[PATCH v4 3/5] phy: rockchip-inno-usb2: add support for otg-mux interrupt

[Frank Wang]

The otg-id/otg-bvalid/linestate interrupts are multiplexed together
in otg-port on some Rockchip SoC (e.g RV1108), this patch add support
for it.

Signed-off-by: Frank Wang 
---
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 63 +--
 1 file changed, 50 insertions(+), 13 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c 
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index fb593cc..22b7b02 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -172,6 +172,8 @@ struct rockchip_usb2phy_cfg {
  * @vbus_attached: otg device vbus status.
  * @bvalid_irq: IRQ number assigned for vbus valid rise detection.
  * @ls_irq: IRQ number assigned for linestate detection.
+ * @otg_mux_irq: IRQ number which multiplex otg-id/otg-bvalid/linestate
+ *  irqs to one irq in otg-port.
  * @mutex: for register updating in sm_work.
  * @chg_work: charge detect work.
  * @otg_sm_work: OTG state machine work.
@@ -189,6 +191,7 @@ struct rockchip_usb2phy_port {
boolvbus_attached;
int bvalid_irq;
int ls_irq;
+   int otg_mux_irq;
struct mutexmutex;
struct  delayed_work chg_work;
struct  delayed_work otg_sm_work;
@@ -934,6 +937,17 @@ static irqreturn_t rockchip_usb2phy_bvalid_irq(int irq, 
void *data)
return IRQ_HANDLED;
 }
 
+static irqreturn_t rockchip_usb2phy_otg_mux_irq(int irq, void *data)
+{
+   struct rockchip_usb2phy_port *rport = data;
+   struct rockchip_usb2phy *rphy = dev_get_drvdata(rport->phy->dev.parent);
+
+   if (property_enabled(rphy->grf, &rport->port_cfg->bvalid_det_st))
+   return rockchip_usb2phy_bvalid_irq(irq, data);
+   else
+   return IRQ_NONE;
+}
+
 static int rockchip_usb2phy_host_port_init(struct rockchip_usb2phy *rphy,
   struct rockchip_usb2phy_port *rport,
   struct device_node *child_np)
@@ -1010,20 +1024,43 @@ static int rockchip_usb2phy_otg_port_init(struct 
rockchip_usb2phy *rphy,
rport->utmi_avalid =
of_property_read_bool(child_np, "rockchip,utmi-avalid");
 
-   rport->bvalid_irq = of_irq_get_byname(child_np, "otg-bvalid");
-   if (rport->bvalid_irq < 0) {
-   dev_err(rphy->dev, "no vbus valid irq provided\n");
-   ret = rport->bvalid_irq;
-   goto out;
-   }
+   /*
+* Some SoCs use one interrupt with otg-id/otg-bvalid/linestate
+* interrupts muxed together, so probe the otg-mux interrupt first,
+* if not found, then look for the regular interrupts one by one.
+*/
+   rport->otg_mux_irq = of_irq_get_byname(child_np, "otg-mux");
+   if (rport->otg_mux_irq > 0) {
+   ret = devm_request_threaded_irq(rphy->dev, rport->otg_mux_irq,
+   NULL,
+   rockchip_usb2phy_otg_mux_irq,
+   IRQF_ONESHOT,
+   "rockchip_usb2phy_otg",
+   rport);
+   if (ret) {
+   dev_err(rphy->dev,
+   "failed to request otg-mux irq handle\n");
+   goto out;
+   }
+   } else {
+   rport->bvalid_irq = of_irq_get_byname(child_np, "otg-bvalid");
+   if (rport->bvalid_irq < 0) {
+   dev_err(rphy->dev, "no vbus valid irq provided\n");
+   ret = rport->bvalid_irq;
+   goto out;
+   }
 
-   ret = devm_request_threaded_irq(rphy->dev, rport->bvalid_irq, NULL,
-   rockchip_usb2phy_bvalid_irq,
-   IRQF_ONESHOT,
-   "rockchip_usb2phy_bvalid", rport);
-   if (ret) {
-   dev_err(rphy->dev, "failed to request otg-bvalid irq handle\n");
-   goto out;
+   ret = devm_request_threaded_irq(rphy->dev, rport->bvalid_irq,
+   NULL,
+   rockchip_usb2phy_bvalid_irq,
+   IRQF_ONESHOT,
+   "rockchip_usb2phy_bvalid",
+   rport);
+   if (ret) {
+   dev_err(rphy->dev,
+   "failed to request otg-bvalid irq handle\n");
+   goto out;
+   }
}
 
if (!IS_ERR(rphy->edev)) {
-- 
2.0.0

[PATCH v4 1/5] phy: rockchip-inno-usb2: add support for rockchip,usbgrf property

[Frank Wang]

The registers of usb-phy are distributed in grf and usbgrf on some
Rockchip SoCs (e.g RV1108), this patch add a new rockchip,usbgrf
property to support this companion grf design.

Signed-off-by: Frank Wang 
---
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 109 +-
 1 file changed, 71 insertions(+), 38 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c 
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 626883d..fb593cc 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -202,6 +202,7 @@ struct rockchip_usb2phy_port {
 /**
  * struct rockchip_usb2phy: usb2.0 phy driver data.
  * @grf: General Register Files regmap.
+ * @usbgrf: USB General Register Files regmap.
  * @clk: clock struct of phy input clk.
  * @clk480m: clock struct of phy output clk.
  * @clk_hw: clock struct of phy output clk management.
@@ -216,6 +217,7 @@ struct rockchip_usb2phy_port {
 struct rockchip_usb2phy {
struct device   *dev;
struct regmap   *grf;
+   struct regmap   *usbgrf;
struct clk  *clk;
struct clk  *clk480m;
struct clk_hw   clk480m_hw;
@@ -227,7 +229,12 @@ struct rockchip_usb2phy {
struct rockchip_usb2phy_portports[USB2PHY_NUM_PORTS];
 };
 
-static inline int property_enable(struct rockchip_usb2phy *rphy,
+static inline struct regmap *get_reg_base(struct rockchip_usb2phy *rphy)
+{
+   return rphy->usbgrf == NULL ? rphy->grf : rphy->usbgrf;
+}
+
+static inline int property_enable(struct regmap *base,
  const struct usb2phy_reg *reg, bool en)
 {
unsigned int val, mask, tmp;
@@ -236,17 +243,17 @@ static inline int property_enable(struct rockchip_usb2phy 
*rphy,
mask = GENMASK(reg->bitend, reg->bitstart);
val = (tmp << reg->bitstart) | (mask << BIT_WRITEABLE_SHIFT);
 
-   return regmap_write(rphy->grf, reg->offset, val);
+   return regmap_write(base, reg->offset, val);
 }
 
-static inline bool property_enabled(struct rockchip_usb2phy *rphy,
+static inline bool property_enabled(struct regmap *base,
const struct usb2phy_reg *reg)
 {
int ret;
unsigned int tmp, orig;
unsigned int mask = GENMASK(reg->bitend, reg->bitstart);
 
-   ret = regmap_read(rphy->grf, reg->offset, &orig);
+   ret = regmap_read(base, reg->offset, &orig);
if (ret)
return false;
 
@@ -258,11 +265,12 @@ static int rockchip_usb2phy_clk480m_prepare(struct clk_hw 
*hw)
 {
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
+   struct regmap *base = get_reg_base(rphy);
int ret;
 
/* turn on 480m clk output if it is off */
-   if (!property_enabled(rphy, &rphy->phy_cfg->clkout_ctl)) {
-   ret = property_enable(rphy, &rphy->phy_cfg->clkout_ctl, true);
+   if (!property_enabled(base, &rphy->phy_cfg->clkout_ctl)) {
+   ret = property_enable(base, &rphy->phy_cfg->clkout_ctl, true);
if (ret)
return ret;
 
@@ -277,17 +285,19 @@ static void rockchip_usb2phy_clk480m_unprepare(struct 
clk_hw *hw)
 {
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
+   struct regmap *base = get_reg_base(rphy);
 
/* turn off 480m clk output */
-   property_enable(rphy, &rphy->phy_cfg->clkout_ctl, false);
+   property_enable(base, &rphy->phy_cfg->clkout_ctl, false);
 }
 
 static int rockchip_usb2phy_clk480m_prepared(struct clk_hw *hw)
 {
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
+   struct regmap *base = get_reg_base(rphy);
 
-   return property_enabled(rphy, &rphy->phy_cfg->clkout_ctl);
+   return property_enabled(base, &rphy->phy_cfg->clkout_ctl);
 }
 
 static unsigned long
@@ -409,13 +419,13 @@ static int rockchip_usb2phy_init(struct phy *phy)
if (rport->mode != USB_DR_MODE_HOST &&
rport->mode != USB_DR_MODE_UNKNOWN) {
/* clear bvalid status and enable bvalid detect irq */
-   ret = property_enable(rphy,
+   ret = property_enable(rphy->grf,
  &rport->port_cfg->bvalid_det_clr,
  true);
if (ret)
goto out;
 
-   ret = property_enable(rphy,
+   ret = property_enable(rphy->grf,
  &rport->port_cfg->bvalid_det_en,
  true);
if (ret)
@@ -429,11 +439,13 @@ static int rockchip_usb2phy_init(struct phy *phy)
}
} else if (rport->port_id == USB2PHY_PORT_HOST) 

[PATCH v4 2/5] dt-bindings: phy-rockchip-inno-usb2: add rockchip,usbgrf property

[Frank Wang]

Add rockchip,usbgrf property to support the registers of usb-phy
that are distributed in grf and usbgrf on some special Rockchip
SoCs (e.g RV1108).

Signed-off-by: Frank Wang 
---
 Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
index 84d59b0..69041373 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -18,6 +18,10 @@ Optional properties:
 usb-phy output 480m and xin24m.
 Refer to clk/clock-bindings.txt for generic clock
 consumer properties.
+ - rockchip,usbgrf : phandle to the syscon managing the "usb general
+register files". When set driver will request its
+phandle as one companion-grf for some special SoCs
+(e.g RV1108).
 
 Required nodes : a sub-node is required for each port the phy provides.
 The sub-node name is used to identify host or otg port,
-- 
2.0.0

[PATCH v4 5/5] phy: rockchip-inno-usb2: add support of usb2-phy for rv1108 SoCs

[Frank Wang]

This adds support usb2-phy for rv1108 SoCs and amend phy Documentation.

Signed-off-by: Frank Wang 
Acked-by: Rob Herring 
---
 .../bindings/phy/phy-rockchip-inno-usb2.txt|  1 +
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c  | 43 ++
 2 files changed, 44 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
index 68230b5..a67ef2a 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -6,6 +6,7 @@ Required properties (phy (parent) node):
* "rockchip,rk3328-usb2phy"
* "rockchip,rk3366-usb2phy"
* "rockchip,rk3399-usb2phy"
+   * "rockchip,rv1108-usb2phy"
  - reg : the address offset of grf for usb-phy configuration.
  - #clock-cells : should be 0.
  - clock-output-names : specify the 480m output clock name.
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c 
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 22b7b02..994cc1a 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -1397,11 +1397,54 @@ static const struct rockchip_usb2phy_cfg 
rk3399_phy_cfgs[] = {
{ /* sentinel */ }
 };
 
+static const struct rockchip_usb2phy_cfg rv1108_phy_cfgs[] = {
+   {
+   .reg = 0x100,
+   .num_ports  = 2,
+   .clkout_ctl = { 0x108, 4, 4, 1, 0 },
+   .port_cfgs  = {
+   [USB2PHY_PORT_OTG] = {
+   .phy_sus= { 0x0100, 15, 0, 0, 0x1d1 },
+   .bvalid_det_en  = { 0x0680, 3, 3, 0, 1 },
+   .bvalid_det_st  = { 0x0690, 3, 3, 0, 1 },
+   .bvalid_det_clr = { 0x06a0, 3, 3, 0, 1 },
+   .ls_det_en  = { 0x0680, 2, 2, 0, 1 },
+   .ls_det_st  = { 0x0690, 2, 2, 0, 1 },
+   .ls_det_clr = { 0x06a0, 2, 2, 0, 1 },
+   .utmi_bvalid= { 0x0804, 10, 10, 0, 1 },
+   .utmi_ls= { 0x0804, 13, 12, 0, 1 },
+   },
+   [USB2PHY_PORT_HOST] = {
+   .phy_sus= { 0x0104, 15, 0, 0, 0x1d1 },
+   .ls_det_en  = { 0x0680, 4, 4, 0, 1 },
+   .ls_det_st  = { 0x0690, 4, 4, 0, 1 },
+   .ls_det_clr = { 0x06a0, 4, 4, 0, 1 },
+   .utmi_ls= { 0x0804, 9, 8, 0, 1 },
+   .utmi_hstdet= { 0x0804, 7, 7, 0, 1 }
+   }
+   },
+   .chg_det = {
+   .opmode = { 0x0100, 3, 0, 5, 1 },
+   .cp_det = { 0x0804, 1, 1, 0, 1 },
+   .dcp_det= { 0x0804, 0, 0, 0, 1 },
+   .dp_det = { 0x0804, 2, 2, 0, 1 },
+   .idm_sink_en= { 0x0108, 8, 8, 0, 1 },
+   .idp_sink_en= { 0x0108, 7, 7, 0, 1 },
+   .idp_src_en = { 0x0108, 9, 9, 0, 1 },
+   .rdm_pdwn_en= { 0x0108, 10, 10, 0, 1 },
+   .vdm_src_en = { 0x0108, 12, 12, 0, 1 },
+   .vdp_src_en = { 0x0108, 11, 11, 0, 1 },
+   },
+   },
+   { /* sentinel */ }
+};
+
 static const struct of_device_id rockchip_usb2phy_dt_match[] = {
{ .compatible = "rockchip,rk3228-usb2phy", .data = &rk3228_phy_cfgs },
{ .compatible = "rockchip,rk3328-usb2phy", .data = &rk3328_phy_cfgs },
{ .compatible = "rockchip,rk3366-usb2phy", .data = &rk3366_phy_cfgs },
{ .compatible = "rockchip,rk3399-usb2phy", .data = &rk3399_phy_cfgs },
+   { .compatible = "rockchip,rv1108-usb2phy", .data = &rv1108_phy_cfgs },
{}
 };
 MODULE_DEVICE_TABLE(of, rockchip_usb2phy_dt_match);
-- 
2.0.0

Re: [PATCH] KVM/x86: Increase max vcpu number to 352

[David Hildenbrand]

On 11.08.2017 09:49, Lan Tianyu wrote:
> Hi Konrad:
>   Thanks for your review.
> 
> On 2017年08月11日 01:50, Konrad Rzeszutek Wilk wrote:
>> On Thu, Aug 10, 2017 at 06:00:59PM +0800, Lan Tianyu wrote:
>>> Intel Xeon phi chip will support 352 logical threads. For HPC usage
>>> case, it will create a huge VM with vcpu number as same as host cpus. This
>>> patch is to increase max vcpu number to 352.
>>
>> Why not 1024 or 4096?
> 
> This is on demand. We can set a higher number since KVM already has
> x2apic and vIOMMU interrupt remapping support.
> 
>>
>> Are there any issues with increasing the value from 288 to 352 right now?
> 
> No found.
> 
>>
>> Also perhaps this should be made in an Kconfig entry?
> 
> That will be anther option but I find different platforms will define
> different MAX_VCPU. If we introduce a generic Kconfig entry, different
> platforms should have different range.
> 
> Radim & Paolo, Could you give some input? In qemu thread, we will set
> max vcpu to 8192 for x86 VM. In KVM, The length of vcpu pointer array in
> struct kvm and dest_vcpu_bitmap in kvm_irq_delivery_to_apic() are
> specified by KVM_MAX_VCPUS. Should we keep align with Qemu?
> 

commit 682f732ecf7396e9d6fe24d44738966699fae6c0
Author: Radim Krčmář 
Date:   Tue Jul 12 22:09:29 2016 +0200

KVM: x86: bump MAX_VCPUS to 288

288 is in high demand because of Knights Landing CPU.
We cannot set the limit to 640k, because that would be wasting space.

I think we want to keep it small as long as possible. I remember a patch
series from Radim which would dynamically allocate memory for these
arrays (using a new VM creation ioctl, specifying the max # of vcpus).
Wonder what happened to that (I remember requesting a simply remalloc
instead of a new VM creation ioctl :] ).

-- 

Thanks,

David

Re: [PATCH 2/3] ARM: sun8i: sunxi-h3-h5: add phy-is-integrated property to internal PHY

[Chen-Yu Tsai]

On Fri, Aug 11, 2017 at 4:05 PM, Corentin Labbe
 wrote:
> On Fri, Aug 11, 2017 at 10:42:51AM +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Thu, Aug 10, 2017 at 4:51 PM, Corentin Labbe
>>  wrote:
>> > This patch add the new phy-is-integrated property to the internal PHY
>> > node.
>> >
>> > Signed-off-by: Corentin Labbe 
>> > ---
>> >  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
>> > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
>> > index 4b599b5d26f6..54fc24e4c569 100644
>> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
>> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
>> > @@ -425,6 +425,7 @@
>> > reg = <1>;
>> > clocks = <&ccu CLK_BUS_EPHY>;
>> > resets = <&ccu RST_BUS_EPHY>;
>> > +   phy-is-integrated;
>>
>> You also need to "delete" this property at the board level for
>> any board that has the external PHY at address <1>. Otherwise
>> they will stop working. This is due to the internal and external
>> PHYs having the same path and node name in the device tree, so
>> they are effectively the same node.
>>
>> ChenYu
>>
>
> They have not the same name, ext_rgmii_phy vs int_mii_phy.

That is just the label. The label plays no part in device tree merging. The path

/soc/ethernet@1c3/mdio/ethernet-phy@1

is the same. You can look under

/proc/device-tree/soc/ethernet@1c3/mdio

on the OrangePI Plus 2E or any other H3 board that uses an
external PHY at address 1.

ChenYu

Re: [patch-rt] hotplug, hrtimer: Migrate expired/deferred timers during cpu offline

[Mike Galbraith]

On Fri, 2017-08-11 at 09:55 +0200, Mike Galbraith wrote:
> The below fixes the list debug explosion up.
> 
> If we do not migrate expired/deferred timers during cpu offline, ->cb_entry
> will be corrupted by online initialization of base->expired, leading to a
> loud list debug complaint should someone call __remove_hrtimer() thereafter.
> 
> Signed-off-by: Mike Galvraith 
ahem.b

> ---
>  kernel/time/hrtimer.c |   13 +
>  1 file changed, 13 insertions(+)
> 
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -1802,6 +1802,19 @@ static void migrate_hrtimer_list(struct
>*/
>   enqueue_hrtimer(timer, new_base);
>   }
> +
> + /*
> +  * Finally, migrate any expired timers deferred by RT.
> +  */
> + while (!list_empty(&old_base->expired)) {
> + struct list_head *entry = old_base->expired.next;
> +
> + timer = container_of(entry, struct hrtimer, cb_entry);
> + /* XXX: hm, perhaps defer again instead of enqueueing. */
> + __remove_hrtimer(timer, old_base, HRTIMER_STATE_ENQUEUED, 0);
> + timer->base = new_base;
> + enqueue_hrtimer(timer, new_base);
> + }
>  }
>  
>  int hrtimers_dead_cpu(unsigned int scpu)

[no subject]

[администратор]

внимания;

Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных 
администратором, который в настоящее время работает на 10.9GB, Вы не сможете 
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый 
ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, 
отправьте следующую информацию ниже:

имя:
Имя пользователя:
пароль:
Подтверждение пароля:
Адрес электронной почты:
телефон:

Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет
отключен!

Приносим извинения за неудобства.
Проверочный код: EN: Ru...9o76ypp2345t..2017
Почты технической поддержки ©2017

спасибо
системы администратор 

Re: [PATCH 2/3] ARM: sun8i: sunxi-h3-h5: add phy-is-integrated property to internal PHY

[Corentin Labbe]

On Fri, Aug 11, 2017 at 04:11:13PM +0800, Chen-Yu Tsai wrote:
> On Fri, Aug 11, 2017 at 4:05 PM, Corentin Labbe
>  wrote:
> > On Fri, Aug 11, 2017 at 10:42:51AM +0800, Chen-Yu Tsai wrote:
> >> Hi,
> >>
> >> On Thu, Aug 10, 2017 at 4:51 PM, Corentin Labbe
> >>  wrote:
> >> > This patch add the new phy-is-integrated property to the internal PHY
> >> > node.
> >> >
> >> > Signed-off-by: Corentin Labbe 
> >> > ---
> >> >  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
> >> > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> >> > index 4b599b5d26f6..54fc24e4c569 100644
> >> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> >> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> >> > @@ -425,6 +425,7 @@
> >> > reg = <1>;
> >> > clocks = <&ccu CLK_BUS_EPHY>;
> >> > resets = <&ccu RST_BUS_EPHY>;
> >> > +   phy-is-integrated;
> >>
> >> You also need to "delete" this property at the board level for
> >> any board that has the external PHY at address <1>. Otherwise
> >> they will stop working. This is due to the internal and external
> >> PHYs having the same path and node name in the device tree, so
> >> they are effectively the same node.
> >>
> >> ChenYu
> >>
> >
> > They have not the same name, ext_rgmii_phy vs int_mii_phy.
> 
> That is just the label. The label plays no part in device tree merging. The 
> path
> 
> /soc/ethernet@1c3/mdio/ethernet-phy@1
> 
> is the same. You can look under
> 
> /proc/device-tree/soc/ethernet@1c3/mdio
> 
> on the OrangePI Plus 2E or any other H3 board that uses an
> external PHY at address 1.
> 
> ChenYu

Since we get the phy node by phy-handle and not by path, I think all should be 
good.

[PATCH kernel] PCI: Disable IOV before pcibios_sriov_disable()

[Alexey Kardashevskiy]

From: Gavin Shan 

The PowerNV platform is the only user of pcibios_sriov_disable().
The IOV BAR could be shifted by pci_iov_update_resource(). The
warning message in the function is printed if the IOV capability
is in enabled (PCI_SRIOV_CTRL_VFE && PCI_SRIOV_CTRL_MSE) state.

This is the backtrace of what is happening:
   pci_disable_sriov
   sriov_disable
   pnv_pci_sriov_disable
   pnv_pci_vf_resource_shift
   pci_update_resource
   pci_iov_update_resource

This fixes the issue by disabling IOV capability before calling
pcibios_sriov_disable(). With it, the disabling path matches
the enabling path: pcibios_sriov_enable() is called before the
IOV capability is enabled.

Cc: shan.ga...@gmail.com
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Reported-by: Carol L Soto 
Signed-off-by: Gavin Shan 
Tested-by: Carol L Soto 
Signed-off-by: Alexey Kardashevskiy 
---

This is repost. Since Gavin left the team, I am trying to push it out.
The previos converstion is here: https://patchwork.ozlabs.org/patch/732653/

Two questions were raised then. I'll try to comment on this below.

>1) "res" is already in the resource tree, so we shouldn't be changing
>   its start address, because that may make the tree inconsistent,
>   e.g., the resource may no longer be completely contained in its
>   parent, it may conflict with a sibling, etc.

We should not, yes. But...

At the boot time IOV BAR gets as much MMIO space as it can possibly use.
(Embarassingly I cannot trace where this is coming from, 8GB is selected
via pci_assign_unassigned_root_bus_resources() path somehow).
For example, it is 256*32MB=8GB where 256 is maximum PEs number and 32MB
is a PF/VF BAR size. Whatever shifting we do afterwards, the boudaries of
that 8GB area do not change and we test it in pnv_pci_vf_resource_shift():

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/platforms/powernv/pci-ioda.c#n987

> 2) If we update "res->start", shouldn't we update "res->end"
>   correspondingly?

We have to update the PF's IOV BAR address as we allocate PEs dynamically
and we do not know in advance where our VF numbers start in that
8GB window. So we change IOV BASR start. Changing the end may make it
look more like there is a free area to use but in reality it won't be
usable as well as the area we "release" by shifting the start address.

We could probably move that M64 MMIO window by the same delta in
opposite direction so the IOV BAR start address would remain the same
but its VF#0 would be mapped to let's say PF#5. I am just afraid there
is an alignment requirement for these M64 window start address; and this
would be even more tricky to manage.

We could also create reserved areas for the amount of space "release" by
moving the start address, not sure how though.

So how do we proceed with this particular patch now? Thanks.
---
 drivers/pci/iov.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 120485d6f352..ac41c8be9200 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -331,7 +331,6 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn)
while (i--)
pci_iov_remove_virtfn(dev, i, 0);
 
-   pcibios_sriov_disable(dev);
 err_pcibios:
iov->ctrl &= ~(PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE);
pci_cfg_access_lock(dev);
@@ -339,6 +338,8 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn)
ssleep(1);
pci_cfg_access_unlock(dev);
 
+   pcibios_sriov_disable(dev);
+
if (iov->link != dev->devfn)
sysfs_remove_link(&dev->dev.kobj, "dep_link");
 
@@ -357,14 +358,14 @@ static void sriov_disable(struct pci_dev *dev)
for (i = 0; i < iov->num_VFs; i++)
pci_iov_remove_virtfn(dev, i, 0);
 
-   pcibios_sriov_disable(dev);
-
iov->ctrl &= ~(PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE);
pci_cfg_access_lock(dev);
pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL, iov->ctrl);
ssleep(1);
pci_cfg_access_unlock(dev);
 
+   pcibios_sriov_disable(dev);
+
if (iov->link != dev->devfn)
sysfs_remove_link(&dev->dev.kobj, "dep_link");
 
-- 
2.11.0

Re: simple-reset to de-duplicate reset drivers

[Philipp Zabel]

Hi Alexandru,

On Thu, 2017-08-10 at 17:16 -0700, Alexandru Gagniuc wrote:
> Hi,
> 
> I was looking at implementing a reset driver for our in-house SoC.
> It's 
> essentially a long bitfield, each bit controlling one sort of reset. 
> That seems to be surprisingly common. I've identified the following 
> drivers which control a very similar reset:
> 
> * reset-zynq
> * reset-zx2967
> * reset-sunxi
> * reset-stm32
> * reset-socfpga
> * reset-oxynas
> * reset-meson
> * reset-berlin

I think zx2967, sunxi, stm32, and socfpga could be unified using common
ops.

zynq, oxnas, and berlin are special because they use regmap to access
shared syscon register space, or have special delays, or both. meson is
different because the resets are self-clearing. It doesn't implement
assert/deassert at all.

> All of these have in common some form of another of:
> 
>   int bank = id / BITS_PER_LONG;
>   int offset = id % BITS_PER_LONG;
> 
> It doesn't make sense to me why all these would be duplicated for every 
> reset controller. I think it would make sense to have a common driver to 
> handle these simple resets -- call it "simple-reset". I'm thinking of 
> something similar to drivers/tty/serial/8250, where the following 
> parameters can be specified:
> 
> - reg-offset
> - reg-shift
> - reg-io-width

Drivers have to keep working with the existing, documented bindings, so
we can't introduce new required device tree properties for them. That
being said, adding optional properties with documented defaults that
fit the current drivers should be possible.

> I think a generic "simple-reset" driver which is configurable by a 
> similar set of parameters would be a suitable replacement for all the 
> aforementioned drivers. As far as our SoC goes, I've just added
> 
>   compatible = "st,stm32-rcc";
> 
> to our devicetree, and I already have a fully-working reset driver. Do 
> you think we should proceed in the direction of "simple-reset", and what 
> other features do you estimate we'll need?

Another difference between the simple reset controllers is whether the
bits are set to assert or cleared to assert.

Even without touching device trees, we can share the backend code by
providing common ops to use for all compatible drivers, and we could
also merge them into a single driver that determines the parameters
from the compatible string.

What do you think about this previous attempt to unify sunxi, stm32,
and socfpga:

https://patchwork.kernel.org/patch/9610709/

regards
Philipp

Re: [PATCH 1/3 v2] thermal: core: Add some new helper functions to free resources

[Zhang Rui]

On Fri, 2017-08-11 at 09:30 +0200, walter harms wrote:
> 
> Am 08.08.2017 16:39, schrieb Christophe JAILLET:
> > 
> > In order to easily free resources allocated by
> > 'thermal_zone_create_device_groups()' we need 2 new helper
> > functions.
> > 
> > The first one undoes 'thermal_zone_create_device_groups()'.
> > The 2nd one undoes 'create_trip_attrs()', which is a function
> > called by
> > 'thermal_zone_create_device_groups()'.
> > 
> > Signed-off-by: Christophe JAILLET 
> > ---
> > These functions will be used in patch 2/3 in order to simplify
> > 'thermal_release()'
> > I've tried to implement it as close a possible as the way the
> > resources have
> > been allocated.
> > However, in 'thermal_release()', the code is simplier without some
> > additionnal 'if'.
> > No sure if we should prefer consistancy with allocation or
> > simplicity of code.
> > ---
> >  drivers/thermal/thermal_core.h  |  1 +
> >  drivers/thermal/thermal_sysfs.c | 29 +
> >  2 files changed, 30 insertions(+)
> > 
> > diff --git a/drivers/thermal/thermal_core.h
> > b/drivers/thermal/thermal_core.h
> > index 2412b3759e16..27e3b1df7360 100644
> > --- a/drivers/thermal/thermal_core.h
> > +++ b/drivers/thermal/thermal_core.h
> > @@ -71,6 +71,7 @@ int thermal_build_list_of_policies(char *buf);
> >  
> >  /* sysfs I/F */
> >  int thermal_zone_create_device_groups(struct thermal_zone_device
> > *, int);
> > +void thermal_zone_destroy_device_groups(struct thermal_zone_device
> > *);
> >  void thermal_cooling_device_setup_sysfs(struct
> > thermal_cooling_device *);
> >  /* used only at binding time */
> >  ssize_t
> > diff --git a/drivers/thermal/thermal_sysfs.c
> > b/drivers/thermal/thermal_sysfs.c
> > index a694de907a26..eb95d64b9446 100644
> > --- a/drivers/thermal/thermal_sysfs.c
> > +++ b/drivers/thermal/thermal_sysfs.c
> > @@ -605,6 +605,24 @@ static int create_trip_attrs(struct
> > thermal_zone_device *tz, int mask)
> >     return 0;
> >  }
> >  
> > +/**
> > + * destroy_trip_attrs() - create attributes for trip points
> > + * @tz:the thermal zone device
> > + *
> > + * helper function to free resources alocated by
> > create_trip_attrs()
> > + */
> > +static void(struct thermal_zone_device *tz)
> > +{
> > +   if (!tz)
> > +   return;
> > +
> > +   kfree(tz->trip_type_attrs);
> > +   kfree(tz->trip_temp_attrs);
> > +   if (tz->ops->get_trip_hyst)
> > +   kfree(tz->trip_hyst_attrs);
> > +   kfree(tz->trips_attribute_group.attrs);
> > +}
> > +
> >  int thermal_zone_create_device_groups(struct thermal_zone_device
> > *tz,
> >       int mask)
> >  {
> > @@ -637,6 +655,17 @@ int thermal_zone_create_device_groups(struct
> > thermal_zone_device *tz,
> >     return 0;
> >  }
> >  
> > +void thermal_zone_destroy_device_groups(struct thermal_zone_device
> > *tz)
> > +{
> > +   if (!tz)
> > +   return;
> > +
> > +   if (tz->trips)
> > +   destroy_trip_attrs(tz);
> why the check for tz->trips ?
> destroy_trip_attrs does not access tz->trips->
> 
tz->trips is an integer represents the number of trip points.

We add this check because there is not any trips attributes if we don't
have any trip points.
It is true that the code also works if we don't have this check as
destroy_trip_attrs() would be no-op when tz->trips equals 0.
But I won't say this check is wrong.

thanks,
rui
> re,
>  wh
> 
> > 
> > +
> > +   kfree(tz->device.groups);
> > +}
> > +
> >  /* sys I/F for cooling device */
> >  static ssize_t
> >  thermal_cooling_device_type_show(struct device *dev,

Re: [PATCH 2/3] ARM: sun8i: sunxi-h3-h5: add phy-is-integrated property to internal PHY

[Chen-Yu Tsai]

On Fri, Aug 11, 2017 at 4:19 PM, Corentin Labbe
 wrote:
> On Fri, Aug 11, 2017 at 04:11:13PM +0800, Chen-Yu Tsai wrote:
>> On Fri, Aug 11, 2017 at 4:05 PM, Corentin Labbe
>>  wrote:
>> > On Fri, Aug 11, 2017 at 10:42:51AM +0800, Chen-Yu Tsai wrote:
>> >> Hi,
>> >>
>> >> On Thu, Aug 10, 2017 at 4:51 PM, Corentin Labbe
>> >>  wrote:
>> >> > This patch add the new phy-is-integrated property to the internal PHY
>> >> > node.
>> >> >
>> >> > Signed-off-by: Corentin Labbe 
>> >> > ---
>> >> >  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 1 +
>> >> >  1 file changed, 1 insertion(+)
>> >> >
>> >> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
>> >> > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
>> >> > index 4b599b5d26f6..54fc24e4c569 100644
>> >> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
>> >> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
>> >> > @@ -425,6 +425,7 @@
>> >> > reg = <1>;
>> >> > clocks = <&ccu CLK_BUS_EPHY>;
>> >> > resets = <&ccu RST_BUS_EPHY>;
>> >> > +   phy-is-integrated;
>> >>
>> >> You also need to "delete" this property at the board level for
>> >> any board that has the external PHY at address <1>. Otherwise
>> >> they will stop working. This is due to the internal and external
>> >> PHYs having the same path and node name in the device tree, so
>> >> they are effectively the same node.
>> >>
>> >> ChenYu
>> >>
>> >
>> > They have not the same name, ext_rgmii_phy vs int_mii_phy.
>>
>> That is just the label. The label plays no part in device tree merging. The 
>> path
>>
>> /soc/ethernet@1c3/mdio/ethernet-phy@1
>>
>> is the same. You can look under
>>
>> /proc/device-tree/soc/ethernet@1c3/mdio
>>
>> on the OrangePI Plus 2E or any other H3 board that uses an
>> external PHY at address 1.
>>
>> ChenYu
>
> Since we get the phy node by phy-handle and not by path, I think all should 
> be good.

You are not getting me. The fact that the two seemingly separate
nodes are merged together means, whatever properties you put in
the internal PHY node, also affect the external PHY node. Once
compiled, they are the SAME node.

[PATCH] pinctrl: intel: Disable GPIO pin interrupts in suspend

[Rushikesh S Kadam]

The fix prevents unintended wakes from second level GPIO pin interrupts.

On some Intel Kabylake platforms, it is observed that GPIO pin interrupts
can wake the platform from suspend-to-idle, even though the IRQ is not
configured as IRQF_NO_SUSPEND or enable_irq_wake().

This can cause undesired wakes on Mobile devices such as Laptops and
Chromebook devices. For example a headset jack insertion is not a desired
wake source on Chromebook devices.

The pinctrl-intel (GPIO controller) driver implements a "Shared IRQ" model.
All GPIO pin interrupts are OR'ed and mapped to a first level IRQ14 (or
IRQ15). The driver registers an irq_chip struct and maps an irq_domain for
the GPIO pin interrupts. The IRQ14 handler demuxes and calls the second
level IRQ for the respective pin.

In the suspend entry flow, at suspend_noirq stage, the kernel disables IRQs
that are not marked for wake. The pinctrl-intel driver does not implement a
irq_disable()  callback (to take advantage of lazy disabling). The
pinctrl-intel GPIO interrupts are not disabled in hardware during suspend
entry, and thus are able to wake the SoC out of suspend-to-idle.

This patch sets the IRQCHIP_MASK_ON_SUSPEND flag for the GPIO irq_chip, to
disable the second level interrupts at suspend_noirq stage via the irq_mask
callbacks. The irq_mask callback disables the IRQs in hardware by
programming the corresponding GPIO pad registers. Only IRQs that are not
marked for wake are disabled.

Signed-off-by: Rushikesh S Kadam 
---
 drivers/pinctrl/intel/pinctrl-intel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/intel/pinctrl-intel.c 
b/drivers/pinctrl/intel/pinctrl-intel.c
index 6dc1096..8f87215 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -1035,6 +1035,7 @@ static irqreturn_t intel_gpio_irq(int irq, void *data)
.irq_unmask = intel_gpio_irq_unmask,
.irq_set_type = intel_gpio_irq_type,
.irq_set_wake = intel_gpio_irq_wake,
+   .flags = IRQCHIP_MASK_ON_SUSPEND,
 };
 
 static int intel_gpio_probe(struct intel_pinctrl *pctrl, int irq)
-- 
1.9.1

Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches

[Henrik Rydberg]

Hi Dmitry,


The meaning of confidence is literally "contact is too large to be a
finger", so it is not touch state, but really tool identity. We do
allow tool identity to change over time.
What I am arguing is rather that since "palm" is a property, just like 
contact size, there should be no need to confuse that property with the 
touch state, which is, as you state, what happens in userland when the 
tool type is modified. Using a different event for the palm property 
ought to remove that confusion.



The additional state is simply because we have never updated the tool
type on release events and userspace is not expecting it and is likely
to ignore any data in the slot that is accompanied with
ABS_TRACKING_ID == -1. So we synthesize an extra event to have
distinct tool change and release.


We update all other properties of a contact freely at release, so logically 
there is no good reason to treat palm, the binary version of max contact size, 
differently.
 


Mostly because with BTN_TOOL_PALM we are not able to decide which
contact is turning into palm. Also, other drivers (RMI) use
MT_TOOL_PALM and I would like to report palm state in unified way.
Precedent certainly matters, but in this case, I think the modification 
promises problems down the road. I would rather suggest to add a new 
binary palm property, with the precise meaning "contact size = max 
contact size", and take it from there. I dont mind writing a patch for 
it if you agree.


Henrik

[PATCH] ASoC: hdmi-codec: Use different name for playback streams

[Jeffy Chen]

Currently the hdmi i2s playback stream and hdmi spdif playback stream
are using the same name. So when they are enabled at the same time,
kernel will print this warning:

[2.201835] hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: Failed to
create Playback debugfs file

Assign different names to them to avoid that.

Signed-off-by: Jeffy Chen 
---

 sound/soc/codecs/hdmi-codec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 509ab51..a2af440 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -696,7 +696,7 @@ static struct snd_soc_dai_driver hdmi_i2s_dai = {
.name = "i2s-hifi",
.id = DAI_ID_I2S,
.playback = {
-   .stream_name = "Playback",
+   .stream_name = "I2S Playback",
.channels_min = 2,
.channels_max = 8,
.rates = HDMI_RATES,
@@ -711,7 +711,7 @@ static const struct snd_soc_dai_driver hdmi_spdif_dai = {
.name = "spdif-hifi",
.id = DAI_ID_SPDIF,
.playback = {
-   .stream_name = "Playback",
+   .stream_name = "SPDIF Playback",
.channels_min = 2,
.channels_max = 2,
.rates = HDMI_RATES,
-- 
2.1.4

linux-next: Tree for Aug 11

[Stephen Rothwell]

Hi all,

Changes since 20170810:

New tree: clk-samsung

The pm tree gained a conflict against the tty.current tree.

The tip tree gained a conflict against the pm tree.

The rcu tree gained a build failure due to an interaction with the tip
tree for which I applied a temporary hack.

I again reverted a commit from the staging tree that was causing overnight
build failures.

The akpm-current tree a gained complex conflict against the tip tree.
Since the conflicting commits in the akpm-current tree are now in Linus'
tree, I reverted the conflicting commits from the tip tree.

Non-merge commits (relative to Linus' tree): 5639
 5749 files changed, 226870 insertions(+), 113076 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 and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) 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.

Below is a summary of the state of the merge.

I am currently merging 268 trees (counting Linus' and 41 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 (26273939ace9 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (4e433fc4d1a9 fixdep: trivial: typo fix and 
correction)
Merging arc-current/for-curr (b5ddb6d54729 ARCv2: PAE40: set MSB even if 
!CONFIG_ARC_HAS_PAE40 but PAE exists in SoC)
Merging arm-current/fixes (ce184a0dee92 ARM: 8687/1: signal: Fix unparseable 
iwmmxt_sigframe in uc_regspace[])
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (96ea91e7b6ee powerpc/watchdog: add locking around 
init/exit functions)
Merging sparc/master (9157259d16a8 mm: add pmd_t initializer __pmd() to work 
around a GCC bug.)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (26273939ace9 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (4ff0308f06da esp: Fix error handling on layer 2 xmit.)
Merging netfilter/master (9beceb54fa2c netfilter: x_tables: Fix use-after-free 
in ipt_do_table.)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (9d6b9b8d1cdb Merge tag 
'iwlwifi-for-kalle-2018-08-09' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (5ef26e966d3f Merge tag 'asoc-fix-v4.13-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (8466489ef5ba xhci: Reset Renesas uPD72020x USB 
controller for 32-bit DMA issue)
Merging driver-core.current/driver-core-linus (260d9f2fc565 firmware: avoid 
invalid fallback aborts by using killable wait)
Merging tty.current/tty-linus (9527b82ae3af Revert "serial: Delete dead code 
for CIR serial ports")
Merging usb.current/usb-linus (3b6bcd3d093c USB: serial: pl2303: add new ATEN 
device id)
Merging usb-gadget-fixes/fixes (b7d44c36a6f6 usb: renesas_usbhs: gadget: fix 
unused-but-set-variable warning)
Merging usb-serial-fixes/usb-linus (fd1b8668af59 USB: serial: option: add 
D-Link DWM-222 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
c

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

[Christoph Hellwig]

My point was that we now gurantee that that the sense data is not
a stack pointer an a driver can DMA to it.  Now for BSG the sense
data is "just" abused as reply, but the point still stands - we
don't want to pass a possible stack pointer to drivers in a data
buffer because we want to allow DMA to it.

That being said with your patch 4 that becomes a moot point as we'll
now always dynamically allocate it.  So maybe just reorder that to go
first and we should be fine.

Re: [PATCH 2/3] ARM: sun8i: sunxi-h3-h5: add phy-is-integrated property to internal PHY

[Corentin Labbe]

On Fri, Aug 11, 2017 at 04:22:11PM +0800, Chen-Yu Tsai wrote:
> On Fri, Aug 11, 2017 at 4:19 PM, Corentin Labbe
>  wrote:
> > On Fri, Aug 11, 2017 at 04:11:13PM +0800, Chen-Yu Tsai wrote:
> >> On Fri, Aug 11, 2017 at 4:05 PM, Corentin Labbe
> >>  wrote:
> >> > On Fri, Aug 11, 2017 at 10:42:51AM +0800, Chen-Yu Tsai wrote:
> >> >> Hi,
> >> >>
> >> >> On Thu, Aug 10, 2017 at 4:51 PM, Corentin Labbe
> >> >>  wrote:
> >> >> > This patch add the new phy-is-integrated property to the internal PHY
> >> >> > node.
> >> >> >
> >> >> > Signed-off-by: Corentin Labbe 
> >> >> > ---
> >> >> >  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 1 +
> >> >> >  1 file changed, 1 insertion(+)
> >> >> >
> >> >> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
> >> >> > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> >> >> > index 4b599b5d26f6..54fc24e4c569 100644
> >> >> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> >> >> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> >> >> > @@ -425,6 +425,7 @@
> >> >> > reg = <1>;
> >> >> > clocks = <&ccu CLK_BUS_EPHY>;
> >> >> > resets = <&ccu RST_BUS_EPHY>;
> >> >> > +   phy-is-integrated;
> >> >>
> >> >> You also need to "delete" this property at the board level for
> >> >> any board that has the external PHY at address <1>. Otherwise
> >> >> they will stop working. This is due to the internal and external
> >> >> PHYs having the same path and node name in the device tree, so
> >> >> they are effectively the same node.
> >> >>
> >> >> ChenYu
> >> >>
> >> >
> >> > They have not the same name, ext_rgmii_phy vs int_mii_phy.
> >>
> >> That is just the label. The label plays no part in device tree merging. 
> >> The path
> >>
> >> /soc/ethernet@1c3/mdio/ethernet-phy@1
> >>
> >> is the same. You can look under
> >>
> >> /proc/device-tree/soc/ethernet@1c3/mdio
> >>
> >> on the OrangePI Plus 2E or any other H3 board that uses an
> >> external PHY at address 1.
> >>
> >> ChenYu
> >
> > Since we get the phy node by phy-handle and not by path, I think all should 
> > be good.
> 
> You are not getting me. The fact that the two seemingly separate
> nodes are merged together means, whatever properties you put in
> the internal PHY node, also affect the external PHY node. Once
> compiled, they are the SAME node.

So why not changing the internal node name from ethernet-phy to integrated-phy ?

Re: [PATCH] pinctrl: aspeed: Fix hardware strap register write logic

[Andrew Jeffery]

Hi Yong,

On Fri, 2017-08-11 at 15:27 +0800, Yong Li wrote:
> The hardware strap register(SCU70) only accepts write ‘1’,
> to clear it to ‘0’, must set bits(write  ‘1’) to SCU7C
> 
> > Signed-off-by: Yong Li 
> ---
>  drivers/pinctrl/aspeed/pinctrl-aspeed.c | 9 +++--
>  drivers/pinctrl/aspeed/pinctrl-aspeed.h | 1 +
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c 
> b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> index a86a4d6..4305052 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> @@ -213,8 +213,13 @@ static int aspeed_sig_expr_set(const struct 
> aspeed_sig_expr *expr,
> >     if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP2)
> >     continue;
>  
> > -   ret = regmap_update_bits(maps[desc->ip], desc->reg,
> > -    desc->mask, val);
> > +   if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP1 &&
> > +   val == 0)
> > +   ret = regmap_update_bits(maps[desc->ip], HW_REVISION_ID,
> > +   desc->mask, desc->mask);
> > +   else
> > +   ret = regmap_update_bits(maps[desc->ip], desc->reg,
> + desc->mask, val);

Good catch! However, this looks like it's only true on the AST2500 (and
related) SoCs. The AST2400 will clear the bits on writing 0 to
HW_STRAP1, so you will need some strategy to differentiate the two.
You're adding the HW_REVISION_ID offset, so maybe we could read that
back and write HW_REVISION_ID if the top byte is 0x04. This would save
some pain propagating the compatible through to here.

For reference, HW_REVISION_ID is structured as:

31:24: Reserved - SoC generation
AST11xx: 0x00
AST20xx: 0x00
AST21xx: 0x00
AST22xx: 0x00
AST23xx: 0x01
AST13xx: 0x01
AST10xx: 0x01
AST24xx: 0x02
AST14xx: 0x02
AST12xx: 0x02
AST25xx: 0x04

23:16: Hardware revision
A0: 0x00
A1: 0x01
A2: 0x03

15:8: Chip bonding option

7:0: Reserved

Cheers,

Andrew

>  
> >     if (ret)
> >     return ret;
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.h 
> b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> index fa125db..d4d7f03 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> @@ -251,6 +251,7 @@
>  #define SCU3C   0x3C /* System Reset Control/Status Register */
>  #define SCU48   0x48 /* MAC Interface Clock Delay Setting */
>  #define HW_STRAP1   0x70 /* AST2400 strapping is 33 bits, is split */
> +#define HW_REVISION_ID  0x7C /* Silicon revision ID register */
>  #define SCU80   0x80 /* Multi-function Pin Control #1 */
>  #define SCU84   0x84 /* Multi-function Pin Control #2 */
>  #define SCU88   0x88 /* Multi-function Pin Control #3 */

signature.asc
Description: This is a digitally signed message part

RE: [PATCH net-next] fsl/fman: implement several errata workarounds

[Madalin-cristian Bucur]

> -Original Message-
> From: Florinel Iordache [mailto:florinel.iorda...@nxp.com]
> Subject: [PATCH net-next] fsl/fman: implement several errata workarounds
> 
> Implemented workarounds for the following dTSEC Erratum:
> A002, A004, A0012, A0014, A004839 on several operations
> that involve MAC CFG register changes: adjust link,
> rx pause frames, modify MAC address.
> 
> Signed-off-by: Florinel Iordache 

Acked-by: Madalin Bucur 

Re: [PATCH 07/11] arm64: add basic pointer authentication support

[Dave Martin]

On Fri, Aug 11, 2017 at 08:46:28AM +0100, Yao Qi wrote:
> Hi Mark,
> 
> On 19/07/17 17:01, Mark Rutland wrote:
> >+#define HWCAP_APIA   (1 << 16)
> 
> Can you rename it to HWCAP_ARM64_APIA or HWCAP_ARM_APIA?  When we
> use it in user space, at least in GDB, we usually do this,
> 
> #ifndef HWCAP_APIA
> #define HWCAP_APIA (1 << 16)
> #endif
> 
> However, the code use this macro can be compiled on !arm64 host.
> If HWCAP_APIA is defined on other !arm64 host and its value is not
> (1 << 16), the program "aarch64_hwcap & HWCAP_APIA ? XXX : XXX;" is
> wrong, and compiler doesn't complain.
> 
> I notice that mips, mn10300, sparc, and s390 define their HWCAP this
> way, like HWCAP_SPARC_FLUSH, HWCAP_MIPS_R6, HWCAP_S390_DFP, etc.

(Sticking my oar in because this would apply to HWCAP_SVE too.)

It would have been a good idea I guess, but historically arm, arm64, x86
(for the one HWCAP2_* flag I can find) and unicore32 don't do this.
That can't change now without an API break, and changing the naming
scheme just for new hwcaps just seems messy.

Including multiple arches' headers in the same compilation unit isn't
guaranteed to work sensibly at all AFAICT -- it seems best no to rely
on it.

In the above, you could be doing something like

#ifdef HWCAP_APIA
#if HWCAP_APIA != (1 << 16)
#error "HWCAP_APIA value mismatch"
#else
#undef HWCAP_APIA
#endif
#endif

#define HWCAP_APIA (1 << 16)

...or...

#define HWCAP_ARM64_APIA (1 << 16)

(i.e., unconditionally, and with a well-behaved compile-time error if
there is a definition already).

[...]

Cheers
---Dave

Re: [PATCH v3 0/5] ACPI: DMA ranges management

[Lorenzo Pieralisi]

On Wed, Aug 09, 2017 at 04:14:43PM -0500, Jeremy Linton wrote:
> Hi,
> 
> Better late than never I guess..
> 
> On 08/03/2017 07:32 AM, Lorenzo Pieralisi wrote:
> >This patch series is v3 of a previous posting:
> >
> >v2->v3:
> > - Fixed DMA masks computation
> > - Fixed size computation overflow in acpi_dma_get_range()
> >
> >v1->v2:
> > - Reworked acpi_dma_get_range() flow and logs
> > - Added IORT named component address limits
> > - Renamed acpi_dev_get_resources() helper function
> > - Rebased against v4.13-rc3
> >
> >v2: http://lkml.kernel.org/r/20170731152323.32488-1-lorenzo.pieral...@arm.com
> >v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieral...@arm.com
> >
> >-- Original cover letter --
> >
> >As reported in:
> >
> >http://lkml.kernel.org/r/cal85gma_sscwm80tkdkzqee+s1bewzdevdki1kpkmutdrms...@mail.gmail.com
> >
> >the bus connecting devices to an IOMMU bus can be smaller in size than
> >the IOMMU input address bits which results in devices DMA HW bugs in
> >particular related to IOVA allocation (ie chopping of higher address
> >bits owing to system bus HW capabilities mismatch with the IOMMU).
> >
> >Fortunately this problem can be solved through an already present but never
> >used ACPI 6.2 firmware bindings (ie _DMA object) allowing to define the DMA
> >window for a specific bus in ACPI and therefore all upstream devices
> >connected to it.
> >
> >This small patch series enables _DMA parsing in ACPI core code and
> >use it in ACPI IORT code in order to detect DMA ranges for devices and
> >update their data structures to make them work with their related DMA
> >addressing restrictions.
> >
> >Cc: Will Deacon 
> >Cc: Hanjun Guo 
> >Cc: Feng Kan 
> >Cc: Jon Masters 
> >Cc: Robert Moore 
> >Cc: Robin Murphy 
> >Cc: Zhang Rui 
> >Cc: "Rafael J. Wysocki" 
> >
> >Lorenzo Pieralisi (5):
> >   ACPICA: resource_mgr: Allow _DMA method in walk resources
> >   ACPI: Make acpi_dev_get_resources() method agnostic
> >   ACPI: Introduce DMA ranges parsing
> >   ACPI: Make acpi_dma_configure() DMA regions aware
> >   ACPI/IORT: Add IORT named component memory address limits
> >
> >  drivers/acpi/acpica/rsxface.c |  7 ++--
> >  drivers/acpi/arm64/iort.c | 57 ++-
> >  drivers/acpi/resource.c   | 82 +-
> >  drivers/acpi/scan.c   | 91 
> > +++
> >  include/acpi/acnames.h|  1 +
> >  include/acpi/acpi_bus.h   |  2 +
> >  include/linux/acpi.h  |  8 
> >  include/linux/acpi_iort.h |  5 ++-
> >  8 files changed, 219 insertions(+), 34 deletions(-)
> 
> Ok, despite being merged already I think its worthwhile to say that
> I've been testing this with:
> 
> Method(_DMA, 0, Serialized)
> {
>   Return (ResourceTemplate()
>   {
>   QWORDMemory(
>   ResourceConsumer,

I asked to update the ACPI specifications because this should be
ResourceProducer, we need an errata to sort this out before it
becomes a problem.

>   PosDecode,  // _DEC
>   MinFixed,   // _MIF
>   MaxFixed,   // _MAF
>   Prefetchable,   // _MEM
>   ReadWrite,  // _RW
>   0,  // _GRA
>   0x1000, // _MIN
>   0x1fff, // _MAX
>   0x0,// _TRA
>   0x1000, // _LEN
>   ,
>   ,
>   ,
>   )
>   })
> } // Method(_DMA)
> 
> (and a couple minor variations)
> 
> and a fair number of debug statements sprinkled around to verify
> that the IOVAs are appropriately limited. So I don't see anything
> wrong with the code and it appears to work and the devices behind a
> bridge limited like this continue to work as long as sane values are
> placed in the min/max/len fields.
> 
> Thanks,
> 
> Tested-by: Jeremy Linton 

Thank you very much Jeremy for testing it, appreciated please let me
know if you spot anything wrong with it on the machines you are
running tests on.

Lorenzo

Re: [PATCH v8 06/14] lockdep: Detect and handle hist_lock ring buffer overwrite

[Byungchul Park]

On Fri, Aug 11, 2017 at 04:03:29PM +0800, Boqun Feng wrote:
> Thanks for taking a look at it ;-)

I rather appriciate it.

> > > @@ -5005,7 +5003,7 @@ static int commit_xhlock(struct cross_lock *xlock, 
> > > struct hist_lock *xhlock)
> > >  static void commit_xhlocks(struct cross_lock *xlock)
> > >  {
> > >   unsigned int cur = current->xhlock_idx;
> > > - unsigned int prev_hist_id = xhlock(cur).hist_id;
> > > + unsigned int prev_hist_id = cur + 1;
> > 
> > I should have named it another. Could you suggest a better one?
> > 
> 
> I think "prev" is fine, because I thought the "previous" means the
> xhlock item we visit _previously_.
> 
> > >   unsigned int i;
> > >  
> > >   if (!graph_lock())
> > > @@ -5030,7 +5028,7 @@ static void commit_xhlocks(struct cross_lock *xlock)
> > >* hist_id than the following one, which is impossible
> > >* otherwise.
> > 
> > Or we need to modify the comment so that the word 'prev' does not make
> > readers confused. It was my mistake.
> > 
> 
> I think the comment needs some help, but before you do it, could you
> have another look at what Peter proposed previously? Note you have a
> same_context_xhlock() check in the commit_xhlocks(), so the your
> previous overwrite case actually could be detected, I think.

What is the previous overwrite case?

ppi
iii

Do you mean this one? I missed the check of same_context_xhlock(). Yes,
peterz's suggestion also seems to work.

> However, one thing may not be detected is this case:
> 
>   pp
> wrapped > www

To be honest, I think your suggestion is more natual, with which this
case would be also covered.

> 
>   where p: process and w: worker.
> 
> , because p and w are in the same task_irq_context(). I discussed this
> with Peter yesterday, and he has a good idea: unconditionally do a reset
> on the ring buffer whenever we do a crossrelease_hist_end(XHLOCK_PROC).
> Basically it means we empty the lock history whenever we finished a
> worker function in a worker thread or we are about to return to
> userspace after we finish the syscall. This could further save some
> memory and so I think this may be better than my approach.

Do you mean reset _whenever_ hard irq exit, soft irq exit or work exit?
Why should we give up chances to check dependencies of remaining xhlocks
whenever each exit? Am I understanding correctly?

I am just curious. Does your approach have some problems?

Thanks,
Byungchul

[no subject]

[Sistemi amministratore]

ATTENZIONE;

La cassetta postale ha superato il limite di archiviazione, che è 5 GB 
come definiti dall'amministratore, che è attualmente in esecuzione 
su 10.9GB, non si può essere in grado di inviare o ricevere nuovi 
messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella 
di posta, inviare le seguenti informazioni qui di seguito:

nome:
Nome utente:
Password:
Conferma Password:
E-mail:
telefono:

Se non si riesce a rinnovare la vostra casella di posta, la vostra caselladi 
posta sarà disabilitato!

Ci dispiace per l'inconvenienza.
Codice di verifica: en:0085362LK.ft6789000.2017
Mail Technical Support ©2017

grazie
Sistemi amministratore

Re: [PATCH] pinctrl: intel: Disable GPIO pin interrupts in suspend

[Mika Westerberg]

On Fri, Aug 11, 2017 at 01:53:44PM +0530, Rushikesh S Kadam wrote:
> The fix prevents unintended wakes from second level GPIO pin interrupts.
> 
> On some Intel Kabylake platforms, it is observed that GPIO pin interrupts
> can wake the platform from suspend-to-idle, even though the IRQ is not
> configured as IRQF_NO_SUSPEND or enable_irq_wake().
> 
> This can cause undesired wakes on Mobile devices such as Laptops and
> Chromebook devices. For example a headset jack insertion is not a desired
> wake source on Chromebook devices.
> 
> The pinctrl-intel (GPIO controller) driver implements a "Shared IRQ" model.
> All GPIO pin interrupts are OR'ed and mapped to a first level IRQ14 (or
> IRQ15). The driver registers an irq_chip struct and maps an irq_domain for
> the GPIO pin interrupts. The IRQ14 handler demuxes and calls the second
> level IRQ for the respective pin.
> 
> In the suspend entry flow, at suspend_noirq stage, the kernel disables IRQs
> that are not marked for wake. The pinctrl-intel driver does not implement a
> irq_disable()  callback (to take advantage of lazy disabling). The
> pinctrl-intel GPIO interrupts are not disabled in hardware during suspend
> entry, and thus are able to wake the SoC out of suspend-to-idle.
> 
> This patch sets the IRQCHIP_MASK_ON_SUSPEND flag for the GPIO irq_chip, to
> disable the second level interrupts at suspend_noirq stage via the irq_mask
> callbacks. The irq_mask callback disables the IRQs in hardware by
> programming the corresponding GPIO pad registers. Only IRQs that are not
> marked for wake are disabled.

This is really good changelog!

> Signed-off-by: Rushikesh S Kadam 

Acked-by: Mika Westerberg 

Re: [PATCH v3 18/20] dt-bindings: qcom_nandc: IPQ8074 QPIC NAND documentation

[Abhishek Sahu]

On 2017-08-11 02:00, Rob Herring wrote:

On Sat, Aug 05, 2017 at 09:49:56PM +0530, Abhishek Sahu wrote:

Qualcom IPQ8074 SoC uses QPIC NAND controller version 1.5.0
which uses BAM DMA Engine.

Signed-off-by: Abhishek Sahu 
---
 Documentation/devicetree/bindings/mtd/qcom_nandc.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt

index d93b952..8dfa543 100644
--- a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -6,6 +6,8 @@ Required properties:
SoC and it uses ADM DMA
 * "qcom,ipq4019-nand" - for QPIC NAND controller v1.4.0 being 
used in

 IPQ4019 SoC and it uses BAM DMA
+* "qcom,ipq8074-nand" - for QPIC NAND controller v1.5.0 being 
used in

+IPQ8074 SoC and it uses BAM DMA

 - reg: MMIO address range
 - clocks:  must contain core clock and always on clock
@@ -97,7 +99,7 @@ nand-controller@1ac0 {
 };

 nand-controller@79b {
-   compatible = "qcom,ipq4019-nand";
+   compatible = "qcom,ipq4019-nand", "qcom,ipq8074-nand";


The order here should be reversed as 8074 is the newer one. And if 4019
is the fallback compatible, that needs to be documented above.



 Thanks Rob for review.

 This is not fallback compatible. I checked the other device tree
 binding examples and it seems, we don't have to add every
 similar compatible string in example. I will remove the
 qcom,ipq8074-nand from example which is causing confusion.


Rob

Re: [v6 02/15] x86/mm: setting fields in deferred pages

[Michal Hocko]

[CC Mel - the full series is here
http://lkml.kernel.org/r/1502138329-123460-1-git-send-email-pasha.tatas...@oracle.com]

On Mon 07-08-17 16:38:36, Pavel Tatashin wrote:
> Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT),
> flags and other fields in "struct page"es are never changed prior to first
> initializing struct pages by going through __init_single_page().
> 
> With deferred struct page feature enabled there is a case where we set some
> fields prior to initializing:
> 
> mem_init() {
> register_page_bootmem_info();
> free_all_bootmem();
> ...
> }
> 
> When register_page_bootmem_info() is called only non-deferred struct pages
> are initialized. But, this function goes through some reserved pages which
> might be part of the deferred, and thus are not yet initialized.
> 
>   mem_init
>register_page_bootmem_info
> register_page_bootmem_info_node
>  get_page_bootmem
>   .. setting fields here ..
>   such as: page->freelist = (void *)type;
> 
> We end-up with similar issue as in the previous patch, where currently we
> do not observe problem as memory is zeroed. But, if flag asserts are
> changed we can start hitting issues.
> 
> Also, because in this patch series we will stop zeroing struct page memory
> during allocation, we must make sure that struct pages are properly
> initialized prior to using them.
> 
> The deferred-reserved pages are initialized in free_all_bootmem().
> Therefore, the fix is to switch the above calls.

I have to confess that this part of the early struct page initialization
is not my strongest point and I have to always re-read the code from the
scratch but I really do not undestand what you are trying to achieve
here.

AFAIU register_page_bootmem_info_node is only about struct pages backing
pgdat, usemap and memmap. Those should be in reserved memblocks and we
do not initialize those at later times, they are not relevant to the
deferred initialization as your changelog suggests so the ordering with
get_page_bootmem shouldn't matter. Or am I missing something here?
 
> Signed-off-by: Pavel Tatashin 
> Reviewed-by: Steven Sistare 
> Reviewed-by: Daniel Jordan 
> Reviewed-by: Bob Picco 
> ---
>  arch/x86/mm/init_64.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 136422d7d539..1e863baec847 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1165,12 +1165,17 @@ void __init mem_init(void)
>  
>   /* clear_bss() already clear the empty_zero_page */
>  
> - register_page_bootmem_info();
> -
>   /* this will put all memory onto the freelists */
>   free_all_bootmem();
>   after_bootmem = 1;
>  
> + /* Must be done after boot memory is put on freelist, because here we
> +  * might set fields in deferred struct pages that have not yet been
> +  * initialized, and free_all_bootmem() initializes all the reserved
> +  * deferred pages for us.
> +  */
> + register_page_bootmem_info();
> +
>   /* Register memory areas for /proc/kcore */
>   kclist_add(&kcore_vsyscall, (void *)VSYSCALL_ADDR,
>PAGE_SIZE, KCORE_OTHER);
> -- 
> 2.14.0

-- 
Michal Hocko
SUSE Labs

Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Peter Zijlstra]

On Fri, Aug 11, 2017 at 01:15:18AM +, Jork Loeser wrote:

> > > HvFlushVirtualAddressList() states:
> > > This call guarantees that by the time control returns back to the
> > > caller, the observable effects of all flushes on the specified virtual
> > > processors have occurred.
> > >
> > > HvFlushVirtualAddressListEx() refers to HvFlushVirtualAddressList() as 
> > > adding
> > > sparse target VP lists.
> > >
> > > Is this enough of a guarantee, or do you see other races?
> > 
> > That's nowhere near enough. We need the remote CPU to have completed any
> > guest IF section that was in progress at the time of the call.
> > 
> > So if a host IPI can interrupt a guest while the guest has IF cleared, and 
> > we then
> > process the host IPI -- clear the TLBs -- before resuming the guest, which 
> > still has
> > IF cleared, we've got a problem.
> > 
> > Because at that point, our software page-table walker, that relies on IF 
> > being
> > clear to guarantee the page-tables exist, because it holds off the TLB 
> > invalidate
> > and thereby the freeing of the pages, gets its pages ripped out from under 
> > it.
> 
> I see, IF is used as a locking mechanism for the pages. Would
> CONFIG_HAVE_RCU_TABLE_FREE be an option for x86? There are caveats
> (statically enabled, RCU for page-free), yet if the resulting perf is
> still a gain it would be worthwhile for Hyper-V targeted kernels.

I'm sure we talked about using HAVE_RCU_TABLE_FREE for x86 (and yes that
would make it work again), but this was some years ago and I cannot
readily find those emails.

Kirill would you have any opinions?

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

[Borislav Petkov]

On Mon, Aug 07, 2017 at 05:59:15PM +, Kani, Toshimitsu wrote:
> I think we should keep the current scheme, which registers an mci for

No we shouldn't.

> each GHES entry.  ghes_edac_report_mem_error() expects that error-
> reporting is serialized per a GHES entry.  Sharing a single mci among
> all GHES entries / error interfaces might lead to a race condition.

See how I solved it in my patchset and feel free to reuse it.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RESEND PATCH v5] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

[Peter Zijlstra]

On Thu, Aug 10, 2017 at 02:18:30PM -0400, Waiman Long wrote:
> On 08/10/2017 12:22 PM, Waiman Long wrote:
> > On 08/10/2017 12:15 PM, Peter Zijlstra wrote:

> >> Might as well do an explicit:
> >>
> >>smp_mb__before_atomic()
> >>cmpxchg_relaxed()
> >>smp_mb__after_atomic()
> >>
> >> I suppose and not introduce new primitives.
> 
> I think we don't need smp_mb__after_atomic(). The read has to be fully
> ordered, but the write part may not need it as the control dependency of
> the old value should guard against incorrect action. Right?

You'd think that, but IIRC there was something funny about using the SC
return flag for control dependencies. Will?

Re: [PATCH v2 2/6] edac: synopsys: Add platform specific structures for ddrc controller

[Borislav Petkov]

On Mon, Aug 07, 2017 at 09:39:24AM +0200, Michal Simek wrote:
> From: Naga Sureshkumar Relli 
> 
> Adds platform specific structures, so that we can add
> different IP support later using quirks.
> 
> Signed-off-by: Naga Sureshkumar Relli 
> Signed-off-by: Michal Simek 
> ---
> 
> Changes in v2:

Subject says "2/6" but I can't find 1/6 in my mbox. Nothing in spam
folder either. What's up?

Are you using the --cover-letter option to git format-patch ?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RESEND PATCH 4/4] EDAC: add support for reduced-width Armada-XP SDRAM

[Borislav Petkov]

On Mon, Aug 07, 2017 at 01:46:41PM +1200, Chris Packham wrote:
> Some integrated Armada XP SoCs use a reduced pin count so the width of
> the SDRAM interface is smaller than the traditional discrete SoCs. This
> means that the definition of "full" and "half" width is further reduced.
> 
> Signed-off-by: Chris Packham 
> ---
>  drivers/edac/armada_xp_edac.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
> index 68e88b180928..d8edcaac87c0 100644
> --- a/drivers/edac/armada_xp_edac.c
> +++ b/drivers/edac/armada_xp_edac.c
> @@ -350,6 +350,9 @@ static int armada_xp_mc_edac_probe(struct platform_device 
> *pdev)
>   if (armada_xp_mc_edac_read_config(mci))
>   return -EINVAL;
>  
> + if (of_property_read_bool(pdev->dev.of_node, "marvell,reduced-width"))
> + drvdata->width /= 2;

If the compiler doesn't already convert it to a shift on ARM, you
probably should do

>>= 1;

here, just in case.

With that you can add my

Acked-by: Borislav Petkov 

and route it through an ARM tree.

Thx.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

[Christoph Hellwig]

But patch 1 still creates an additional copy of the sense data for
all bsg users.

Can you test the patch below which implements my suggestion?  Your
other patches should still apply fine on top modulo minor context
changes.

---
>From 4cd32ee48e334b62b55bff0d380833b978454040 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig 
Date: Fri, 11 Aug 2017 11:03:29 +0200
Subject: bsg-lib: allocate sense data for each request

Since we split the scsi_request out of the request the driver is supposed
to provide storage for the sense buffer.  The bsg-lib code failed to do so,
though and will crash anytime it is used.

This patch moves bsg-lib to allocate and setup the bsg_job ahead of time,
and allocate the sense data, which is used as reply buffer in bsg.

Reported-by: Steffen Maier 
Signed-off-by: Benjamin Block 
Fixes: 82ed4db499b8 ("block: split scsi_request out of struct request")
Cc:  #4.11+
---
 block/bsg-lib.c | 53 +++--
 include/linux/blkdev.h  |  1 -
 include/linux/bsg-lib.h |  2 ++
 3 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/block/bsg-lib.c b/block/bsg-lib.c
index c4513b23f57a..215893dbd038 100644
--- a/block/bsg-lib.c
+++ b/block/bsg-lib.c
@@ -100,7 +100,7 @@ EXPORT_SYMBOL_GPL(bsg_job_done);
  */
 static void bsg_softirq_done(struct request *rq)
 {
-   struct bsg_job *job = rq->special;
+   struct bsg_job *job = blk_mq_rq_to_pdu(rq);
 
bsg_job_put(job);
 }
@@ -129,26 +129,9 @@ static int bsg_map_buffer(struct bsg_buffer *buf, struct 
request *req)
 static int bsg_create_job(struct device *dev, struct request *req)
 {
struct request *rsp = req->next_rq;
-   struct request_queue *q = req->q;
-   struct scsi_request *rq = scsi_req(req);
-   struct bsg_job *job;
+   struct bsg_job *job = blk_mq_rq_to_pdu(req);
int ret;
 
-   BUG_ON(req->special);
-
-   job = kzalloc(sizeof(struct bsg_job) + q->bsg_job_size, GFP_KERNEL);
-   if (!job)
-   return -ENOMEM;
-
-   req->special = job;
-   job->req = req;
-   if (q->bsg_job_size)
-   job->dd_data = (void *)&job[1];
-   job->request = rq->cmd;
-   job->request_len = rq->cmd_len;
-   job->reply = rq->sense;
-   job->reply_len = SCSI_SENSE_BUFFERSIZE; /* Size of sense buffer
-* allocated */
if (req->bio) {
ret = bsg_map_buffer(&job->request_payload, req);
if (ret)
@@ -187,7 +170,6 @@ static void bsg_request_fn(struct request_queue *q)
 {
struct device *dev = q->queuedata;
struct request *req;
-   struct bsg_job *job;
int ret;
 
if (!get_device(dev))
@@ -207,8 +189,7 @@ static void bsg_request_fn(struct request_queue *q)
continue;
}
 
-   job = req->special;
-   ret = q->bsg_job_fn(job);
+   ret = q->bsg_job_fn(blk_mq_rq_to_pdu(req));
spin_lock_irq(q->queue_lock);
if (ret)
break;
@@ -219,6 +200,29 @@ static void bsg_request_fn(struct request_queue *q)
spin_lock_irq(q->queue_lock);
 }
 
+static int bsg_init_rq(struct request_queue *q, struct request *req, gfp_t gfp)
+{
+   struct bsg_job *job = blk_mq_rq_to_pdu(req);
+
+   memset(job, 0, sizeof(*job));
+   job->req = req;
+   job->dd_data = job + 1;
+   job->request = job->sreq.cmd;
+   job->request_len = job->sreq.cmd_len;
+   job->reply_len = SCSI_SENSE_BUFFERSIZE;
+   job->reply = job->sreq.sense = kzalloc(job->reply_len, gfp);
+   if (!job->reply)
+   return -ENOMEM;
+   return 0;
+}
+
+static void bsg_exit_rq(struct request_queue *q, struct request *req)
+{
+   struct bsg_job *job = blk_mq_rq_to_pdu(req);
+
+   kfree(job->reply);
+}
+
 /**
  * bsg_setup_queue - Create and add the bsg hooks so we can receive requests
  * @dev: device to attach bsg device to
@@ -235,7 +239,9 @@ struct request_queue *bsg_setup_queue(struct device *dev, 
char *name,
q = blk_alloc_queue(GFP_KERNEL);
if (!q)
return ERR_PTR(-ENOMEM);
-   q->cmd_size = sizeof(struct scsi_request);
+   q->cmd_size = sizeof(struct bsg_job) + dd_job_size;
+   q->init_rq_fn = bsg_init_rq;
+   q->exit_rq_fn = bsg_exit_rq;
q->request_fn = bsg_request_fn;
 
ret = blk_init_allocated_queue(q);
@@ -243,7 +249,6 @@ struct request_queue *bsg_setup_queue(struct device *dev, 
char *name,
goto out_cleanup_queue;
 
q->queuedata = dev;
-   q->bsg_job_size = dd_job_size;
q->bsg_job_fn = job_fn;
queue_flag_set_unlocked(QUEUE_FLAG_BIDI, q);
queue_flag_set_unlocked(QUEUE_FLAG_SCSI_PASSTHROUGH, q);
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index f45f157b2910..6ae9aa6f93f0 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -568,7 +

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

[Peter Zijlstra]

On Thu, Aug 10, 2017 at 09:54:53PM -0700, Paul E. McKenney wrote:
> On Fri, Aug 11, 2017 at 02:43:52PM +1000, Stephen Rothwell wrote:
> 
> Looks like I need to rebase my patch on top of a9668cd6ee28, and
> than put an smp_mb__after_spinlock() between the lock and the unlock.
> 
> Peter, any objections to that approach?  Other suggestions?

Hurm.. I'll have to try and understand that comment there again it
seems.

[PATCH 0/1] rtc: rtctest: Support opal-rtc and rtc-generic

[Lukáš Doktor]

On ppc64le machines the opal-rtc, resp rtc-generic in guest is used. They only
support minimal set of functionality and fail this test in not-yet treated
way. This extends the checks and skips to the next test when feature is not
supported.

Lukáš Doktor (1):
  rtc: rtctest: Improve support detection

 tools/testing/selftests/timers/rtctest.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

-- 
2.9.4

Re: [RFC PATCH] sched/topology: Introduce NUMA identity node sched domain

[Peter Zijlstra]

On Fri, Aug 11, 2017 at 12:58:22PM +0700, Suravee Suthikulpanit wrote:
> 
> 
> On 8/11/17 11:57, Suravee Suthikulpanit wrote:
> > 
> > > > [...]
> > > > @@ -1445,9 +1448,24 @@ void sched_init_numa(void)
> > > >  tl[i] = sched_domain_topology[i];
> > > > 
> > > >  /*
> > > > + * Ignore the NUMA identity level if it has the same cpumask
> > > > + * as previous level. This is the case for:
> > > > + *   - System with last-level-cache (MC) sched domain span a NUMA 
> > > > node.
> > > > + *   - System with DIE sched domain span a NUMA node.
> > > > + *
> > > > + * Assume all NUMA nodes are identical, so only check node 0.
> > > > + */
> > > > +if (!cpumask_equal(sched_domains_numa_masks[0][0], 
> > > > tl[i-1].mask(0)))
> > > > +tl[i++] = (struct sched_domain_topology_level){
> > > > +.mask = sd_numa_mask,
> > > > +.numa_level = 0,
> > > > +SD_INIT_NAME(NODE)
> > > > +};
> > > 
> > > So what you've forgotten to mention is that for those systems where the
> > > LLC == NODE this now superfluous level gets removed by the degenerate
> > > code. Have you verified that does the right thing?
> > 
> > Let me check with that one and get back.
> 
> Actually, it is not removed by the degenerate code. That is what this logic
> is for. It checks for LCC == NODE or DIE == NODE before setting up the NODE
> sched level. I can update the comment. This has also been tested on system
> w/ LLC == NODE.

Why does the degenerate code fail to remove things?

[PATCH] rtc: rtctest: Improve support detection

[Lukáš Doktor]

The rtc-generic and opal-rtc are failing to run this test as they do not
support all the features. Let's treat the error returns and skip to the
following test.

Theoretically the test_DATE should be also adjusted, but as it's enabled
on demand I think it makes sense to fail in such case.

Signed-off-by: Lukáš Doktor 
---
 tools/testing/selftests/timers/rtctest.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/timers/rtctest.c 
b/tools/testing/selftests/timers/rtctest.c
index f61170f..6344842 100644
--- a/tools/testing/selftests/timers/rtctest.c
+++ b/tools/testing/selftests/timers/rtctest.c
@@ -125,7 +125,7 @@ int main(int argc, char **argv)
/* Turn on update interrupts (one per second) */
retval = ioctl(fd, RTC_UIE_ON, 0);
if (retval == -1) {
-   if (errno == EINVAL) {
+   if (errno == EINVAL || errno == EINVAL) {
fprintf(stderr,
"\n...Update IRQs not supported.\n");
goto test_READ;
@@ -221,6 +221,11 @@ int main(int argc, char **argv)
/* Read the current alarm settings */
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
if (retval == -1) {
+   if (errno == EINVAL) {
+   fprintf(stderr,
+   "\n...EINVAL reading current alarm 
setting.\n");
+   goto test_PIE;
+   }
perror("RTC_ALM_READ ioctl");
exit(errno);
}
@@ -231,7 +236,7 @@ int main(int argc, char **argv)
/* Enable alarm interrupts */
retval = ioctl(fd, RTC_AIE_ON, 0);
if (retval == -1) {
-   if (errno == EINVAL) {
+   if (errno == EINVAL || errno ==EIO) {
fprintf(stderr,
"\n...Alarm IRQs not supported.\n");
goto test_PIE;
-- 
2.9.4

Re: [PATCH v2 2/6] edac: synopsys: Add platform specific structures for ddrc controller

[Michal Simek]

On 11.8.2017 11:09, Borislav Petkov wrote:
> On Mon, Aug 07, 2017 at 09:39:24AM +0200, Michal Simek wrote:
>> From: Naga Sureshkumar Relli 
>>
>> Adds platform specific structures, so that we can add
>> different IP support later using quirks.
>>
>> Signed-off-by: Naga Sureshkumar Relli 
>> Signed-off-by: Michal Simek 
>> ---
>>
>> Changes in v2:
> 
> Subject says "2/6" but I can't find 1/6 in my mbox. Nothing in spam
> folder either. What's up?

https://lkml.org/lkml/2017/8/7/105
ACK by Rob yesterday.

> 
> Are you using the --cover-letter option to git format-patch ?

I am using patman - u-boot tools for sending patch. It read MAINTAINERS
file and copy right people.
It has option to explicitly CC people. I need to resend this as v3
anyway that's why I will add you there.

Thanks,
Michal

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Linus Walleij]

On Thu, Aug 10, 2017 at 4:38 PM, Danilo Krummrich
 wrote:
> On 2017-08-07 18:22, Danilo Krummrich wrote:
>>>
>>> > +static int ps2_gpio_write(struct serio *serio, unsigned char val)
>>> > +{
>>> > +   struct ps2_gpio_data *drvdata = serio->port_data;
>>> > +
>>> > +   drvdata->mode = PS2_MODE_TX;
>>> > +   drvdata->tx_byte = val;
>>> > +   /* Make sure ISR running on other CPU notice changes. */
>>> > +   barrier();
>>>
>>> This seems overengineered, is this really needed?
>>>
>>> If we have races like this, the error is likely elsewhere, and should be
>>> fixed in the GPIO driver MMIO access or so.
>>>
>> Yes, seems it can be removed. I didn't saw any explicit barriers in the
>> GPIO
>> driver (I'm testing on bcm2835), but it seems MMIO operations on SMP archs
>> does contain barriers. Not sure if all do. If some do not this barrier
>> might
>> be needed to ensure ISR on other CPU notice the correct mode and byte to
>> send.
>>
> I couldn't find any guarantee that the mode and tx_byte change is implicitly
> covered by a barrier in this case. E.g. the bcm2835 driver does not make
> sure stores are completed before the particular interrupt is enabled, except 
> by
> the fact that writel on ARM contains a wmb(). But this is nothing to rely on.
> (Please tell me if I miss something.)

writel() should be guaranteeing that the values hit the hardware, wmb() is
spelled out "write memory barrier" I don't see what you're after here.

If you think writel() doesn't do its job on some platform, then fix writel()
on that platform.

We can't randomly sprinkle things like this all over the kernel it makes
no sense.

> Therefore I would like to keep this barrier and replace it with smp_wmb() if
> you are fine with that.

I do not think this is proper.

Yours,
Linus Walleij

Re: perf test BPF subtest bpf-prologue test fails on s390x

[Thomas-Mich Richter]

On 08/11/2017 07:19 AM, Wangnan (F) wrote:
> 
> 
> On 2017/8/11 2:13, Arnaldo Carvalho de Melo wrote:
>> Thomas, please try to find who wrote that test and CC him, I'm doing it
>> this time, Wang, can you please take a look at this?
>>
>> I also added lkml to the CC list, here we have more users of perf, lkml
>> is the more developer centric perf list, as perf touches way too many
>> places in the kernel.
>>
>> Best regards,
>>
>> - Arnaldo
>>
>> Em Wed, Aug 09, 2017 at 11:24:19AM +0200, Thomas Richter escreveu:
>>> I investigate perf test BPF for s390x and have a question regarding
>>> the 38.3 subtest (bpf-prologue test) which fails on s390x.
>>>
>>> When I turn on trace_printk in tests/bpf-script-test-prologue.c
>>> I see this output in /sys/kernel/debug/tracing/trace:
>>>
>>> [root@s8360047 perf]# cat /sys/kernel/debug/tracing/trace
>>> perf-30229 [000] d..2 170161.535791: : f_mode 2001d offset:0 orig:0
>>> perf-30229 [000] d..2 170161.535809: : f_mode 6001f offset:0 orig:0
>>> perf-30229 [000] d..2 170161.535815: : f_mode 6001f offset:1 orig:0
>>> perf-30229 [000] d..2 170161.535819: : f_mode 2001d offset:1 orig:0
>>> perf-30229 [000] d..2 170161.535822: : f_mode 2001d offset:2 orig:1
>>> perf-30229 [000] d..2 170161.535825: : f_mode 6001f offset:2 orig:1
>>> perf-30229 [000] d..2 170161.535828: : f_mode 6001f offset:3 orig:1
>>> perf-30229 [000] d..2 170161.535832: : f_mode 2001d offset:3 orig:1
>>> perf-30229 [000] d..2 170161.535835: : f_mode 2001d offset:4 orig:0
>>> perf-30229 [000] d..2 170161.535841: : f_mode 6001f offset:4 orig:0
>>>
>>> [...]
>>>
>>> There are 3 parameters the eBPF program tests/bpf-script-test-prologue.c
>>> accesses: f_mode (member of struct file at offset 140) offset and orig.
>>> They are parameters of the lseek() system call triggered in this
>>> test case in function llseek_loop().
>>>
>>> What is really strange is the value of f_mode. It is an 8 byte
>>> value, whereas in the probe event it is defined as a 4 byte value.
>>> The lower 4 bytes are all zero and do not belong to member f_mode.
>>> The correct value should be 2001d for read-only and 6001f for
>>> read-write open mode.
>>>
>>> Here is the output of the 'perf test -vv bpf' trace:
>>> Try to find probe point from debuginfo.
>>> Matched function: null_lseek [2d9310d]
>>> Probe point found: null_lseek+0
>>> Searching 'file' variable in context.
>>> Converting variable file into trace event.
>>> converting f_mode in file
>>> f_mode type is unsigned int.
>>> Opening /sys/kernel/debug/tracing//README write=0
>>> Searching 'offset' variable in context.
>>> Converting variable offset into trace event.
>>> offset type is long long int.
>>> Searching 'orig' variable in context.
>>> Converting variable orig into trace event.
>>> orig type is int.
>>> Found 1 probe_trace_events.
>>> Opening /sys/kernel/debug/tracing//kprobe_events write=1
>>> Writing event: p:perf_bpf_probe/func _text+8794224 f_mode=+140(%r2):x32
>>> offset=%r3:s64 orig=%r4:s32
> 
> Thank you for your information. This is an endianess problem.
> 
> Here f_mode is x32, so perf probe and debuginfo in vmlinux is correct.
> However, BPF prologue generator doesn't obey type, but unconditionally
> fetch 8 bytes (on 64-bit machine) and pass it to parameter of
> bpf_func__null_lseek. This is reasonable, because all args should be
> unsigned long. However, to recover its original value, we need a casting.
> 
> Please help me verify if the following fix works on your platform:
> 
> diff --git a/tools/perf/tests/bpf-script-test-prologue.c 
> b/tools/perf/tests/bpf-script-test-prologue.c
> index b4ebc75..43f1e16 100644
> --- a/tools/perf/tests/bpf-script-test-prologue.c
> +++ b/tools/perf/tests/bpf-script-test-prologue.c
> @@ -26,9 +26,11 @@ static void (*bpf_trace_printk)(const char *fmt, int 
> fmt_size, ...) =
> (void *) 6;
> 
>  SEC("func=null_lseek file->f_mode offset orig")
> -int bpf_func__null_lseek(void *ctx, int err, unsigned long f_mode,
> +int bpf_func__null_lseek(void *ctx, int err, unsigned long _f_mode,
>  unsigned long offset, unsigned long orig)
>  {
> +   fmode_t f_mode = (fmode_t)_f_mode;
> +
> if (err)
> return 0;
> if (f_mode & FMODE_WRITE)
> 
> Thank you.
> 

Thanks for this patch, unfortunately it does not work. The result is the same
as before. Here is the trace output from /sys/kernel/debug/tracing/trace:   
 
   perf-18119 [001] d..2 66832.765154: : f_mode 0 offset:0 orig:0
   perf-18119 [001] d..2 66832.765189: : f_mode 0 offset:0 orig:0
   perf-18119 [001] d..2 66832.765203: : f_mode 0 offset:1 orig:0
   perf-18119 [001] d..2 66832.765216: : f_mode 0 offset:1 orig:0
   perf-18119 [001] d..2 66832.765229: : f_mode 0 offset:2 orig:1
   perf-18119 [001] d..2 66832.765242: : f_mode 0 offset:2 orig:1

However wh

Re: New assembler warnings with binutils 2.29

[Catalin Marinas]

On Thu, Aug 10, 2017 at 01:13:22PM -0700, Laura Abbott wrote:
> Fedora rawhide recently upgraded to binutils 2.29 and this seems
> to produce new warnings:
> 
> ./arch/arm64/include/asm/assembler.h: Assembler messages:
> ./arch/arm64/include/asm/assembler.h:125: Warning: ignoring attempt to 
> redefine built-in register 'lr'
> 
> This is
> 
> /*
>  * Register aliases.
>  */
> lr  .reqx30 // link register

Strange, does gas now think 'lr' is a general purpose register (aliased
to x30)? It never was and IIRC the toolchain people many years ago
refused to add it, hence the alias above in the kernel. I wonder if they
added 'fp' as well...

We could remove the alias and replace all 'lr' instances with 'x30'
throughout the kernel (no too many) or we add some #ifdef around the
above based on the binutils version.

-- 
Catalin

Re: [PATCH v2 2/6] edac: synopsys: Add platform specific structures for ddrc controller

[Borislav Petkov]

On Fri, Aug 11, 2017 at 11:16:15AM +0200, Michal Simek wrote:
> https://lkml.org/lkml/2017/8/7/105
> ACK by Rob yesterday.

Ok, pls bounce it to me as I don't have it.

Also, pls refrain from using lkml.org. Simply do:

http://lkml.kernel.org/r/

> I am using patman - u-boot tools for sending patch. It read MAINTAINERS
> file and copy right people.
> It has option to explicitly CC people. I need to resend this as v3
> anyway that's why I will add you there.

Yes, if you send cross-maintainer changes, please make sure to CC them on all
patches because otherwise stuff like that happens and people start wondering
where is the rest and so on.

Thx.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

[Vitaly Kuznetsov]

Peter Zijlstra  writes:

> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote:
>
>> > > Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote 
>> > > TLB flush
>> 
>> > > Hold on.. if we don't IPI for TLB invalidation. What serializes our
>> > > software page table walkers like fast_gup() ?
>> > 
>> > Hypervisor may implement this functionality via an IPI.
>> > 
>> > K. Y
>> 
>> HvFlushVirtualAddressList() states:
>> This call guarantees that by the time control returns back to the
>> caller, the observable effects of all flushes on the specified virtual
>> processors have occurred.
>> 
>> HvFlushVirtualAddressListEx() refers to HvFlushVirtualAddressList() as 
>> adding sparse target VP lists.
>> 
>> Is this enough of a guarantee, or do you see other races?
>
> That's nowhere near enough. We need the remote CPU to have completed any
> guest IF section that was in progress at the time of the call.
>
> So if a host IPI can interrupt a guest while the guest has IF cleared,
> and we then process the host IPI -- clear the TLBs -- before resuming the
> guest, which still has IF cleared, we've got a problem.
>
> Because at that point, our software page-table walker, that relies on IF
> being clear to guarantee the page-tables exist, because it holds off the
> TLB invalidate and thereby the freeing of the pages, gets its pages
> ripped out from under it.

Oh, I see your concern. Hyper-V, however, is not the first x86
hypervisor trying to avoid IPIs on remote TLB flush, Xen does this
too. Briefly looking at xen_flush_tlb_others() I don't see anything
special, do we know how serialization is achieved there?

-- 
  Vitaly

Re: [PATCH v6 4/7] mm: refactoring TLB gathering API

[Peter Zijlstra]

On Tue, Aug 01, 2017 at 05:08:15PM -0700, Nadav Amit wrote:
> From: Minchan Kim 
> 
> This patch is a preparatory patch for solving race problems caused by
> TLB batch.  For that, we will increase/decrease TLB flush pending count
> of mm_struct whenever tlb_[gather|finish]_mmu is called.
> 
> Before making it simple, this patch separates architecture specific
> part and rename it to arch_tlb_[gather|finish]_mmu and generic part
> just calls it.

I absolutely hate this. We should unify this stuff, not diverge it
further.

Re: New assembler warnings with binutils 2.29

[Ard Biesheuvel]

On 11 August 2017 at 10:22, Catalin Marinas  wrote:
> On Thu, Aug 10, 2017 at 01:13:22PM -0700, Laura Abbott wrote:
>> Fedora rawhide recently upgraded to binutils 2.29 and this seems
>> to produce new warnings:
>>
>> ./arch/arm64/include/asm/assembler.h: Assembler messages:
>> ./arch/arm64/include/asm/assembler.h:125: Warning: ignoring attempt to 
>> redefine built-in register 'lr'
>>
>> This is
>>
>> /*
>>  * Register aliases.
>>  */
>> lr  .reqx30 // link register
>
> Strange, does gas now think 'lr' is a general purpose register (aliased
> to x30)? It never was and IIRC the toolchain people many years ago
> refused to add it, hence the alias above in the kernel. I wonder if they
> added 'fp' as well...
>
> We could remove the alias and replace all 'lr' instances with 'x30'
> throughout the kernel (no too many) or we add some #ifdef around the
> above based on the binutils version.
>

This is annoying. Replacing x30 with lr achieves the opposite of the
intent of the binutils change. And using #ifdefs is inaccurate,
because you can't really test the binutils version only the GCC
version, and those are not tightly coupled.

Can you .unreq it?

Re: [v6 04/15] mm: discard memblock data later

[Michal Hocko]

[CC Mel]

On Mon 07-08-17 16:38:38, Pavel Tatashin wrote:
> There is existing use after free bug when deferred struct pages are
> enabled:
> 
> The memblock_add() allocates memory for the memory array if more than
> 128 entries are needed.  See comment in e820__memblock_setup():
> 
>   * The bootstrap memblock region count maximum is 128 entries
>   * (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
>   * than that - so allow memblock resizing.
> 
> This memblock memory is freed here:
> free_low_memory_core_early()
> 
> We access the freed memblock.memory later in boot when deferred pages are
> initialized in this path:
> 
> deferred_init_memmap()
> for_each_mem_pfn_range()
>   __next_mem_pfn_range()
> type = &memblock.memory;

Yes you seem to be right.
>
> One possible explanation for why this use-after-free hasn't been hit
> before is that the limit of INIT_MEMBLOCK_REGIONS has never been exceeded
> at least on systems where deferred struct pages were enabled.

Yeah this sounds like the case.
 
> Another reason why we want this problem fixed in this patch series is,
> in the next patch, we will need to access memblock.reserved from
> deferred_init_memmap().
> 

I guess this goes all the way down to 
Fixes: 7e18adb4f80b ("mm: meminit: initialise remaining struct pages in 
parallel with kswapd")
> Signed-off-by: Pavel Tatashin 
> Reviewed-by: Steven Sistare 
> Reviewed-by: Daniel Jordan 
> Reviewed-by: Bob Picco 

Considering that some HW might behave strangely and this would be rather
hard to debug I would be tempted to mark this for stable. It should also
be merged separately from the rest of the series.

I have just one nit below
Acked-by: Michal Hocko 

[...]
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 2cb25fe4452c..bf14aea6ab70 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -285,31 +285,27 @@ static void __init_memblock 
> memblock_remove_region(struct memblock_type *type, u
>  }
>  
>  #ifdef CONFIG_ARCH_DISCARD_MEMBLOCK

pull this ifdef inside memblock_discard and you do not have an another
one in page_alloc_init_late

[...]
> +/**
> + * Discard memory and reserved arrays if they were allocated
> + */
> +void __init memblock_discard(void)
>  {

here

> - if (memblock.memory.regions == memblock_memory_init_regions)
> - return 0;
> + phys_addr_t addr, size;
>  
> - *addr = __pa(memblock.memory.regions);
> + if (memblock.reserved.regions != memblock_reserved_init_regions) {
> + addr = __pa(memblock.reserved.regions);
> + size = PAGE_ALIGN(sizeof(struct memblock_region) *
> +   memblock.reserved.max);
> + __memblock_free_late(addr, size);
> + }
>  
> - return PAGE_ALIGN(sizeof(struct memblock_region) *
> -   memblock.memory.max);
> + if (memblock.memory.regions == memblock_memory_init_regions) {
> + addr = __pa(memblock.memory.regions);
> + size = PAGE_ALIGN(sizeof(struct memblock_region) *
> +   memblock.memory.max);
> + __memblock_free_late(addr, size);
> + }
>  }
> -
>  #endif
[...]
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index fc32aa81f359..63d16c185736 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1584,6 +1584,10 @@ void __init page_alloc_init_late(void)
>   /* Reinit limits that are based on free pages after the kernel is up */
>   files_maxfiles_init();
>  #endif
> +#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK
> + /* Discard memblock private memory */
> + memblock_discard();
> +#endif
>  
>   for_each_populated_zone(zone)
>   set_zone_contiguous(zone);
> -- 
> 2.14.0

-- 
Michal Hocko
SUSE Labs

Re: pmu::read() called erroneously in v4.13-rc{3,4}

[Mark Rutland]

On Thu, Aug 10, 2017 at 12:03:55PM -0700, Andi Kleen wrote:
> > [  230.909172] [ cut here ]
> > [  230.913796] WARNING: CPU: 1 PID: 3637 at arch/x86/events/core.c:75 
> > x86_perf_event_update+0xbd/0xd0
> > [  230.922739] Modules linked in:
> > [  230.925798] CPU: 1 PID: 3637 Comm: wrong-counter Tainted: GW 
> >   4.13.0-rc4+ #230
> > [  230.934132] Hardware name: LENOVO 7484A3G/LENOVO, BIOS 5CKT54AUS 
> > 09/07/2009
> > [  230.941080] task: 9ad5b0232640 task.stack: b2f001aac000
> > [  230.946989] RIP: 0010:x86_perf_event_update+0xbd/0xd0
> > [  230.952038] RSP: 0018:b2f001aaf978 EFLAGS: 00010282
> > [  230.957257] RAX: 0020 RBX: b2f001aafa48 RCX: 
> > 
> > [  230.964378] RDX: 0001 RSI: 9ad5a9d33400 RDI: 
> > 9ad5a9d32800
> > [  230.971498] RBP: b2f001aaf9a0 R08:  R09: 
> > 0028
> > [  230.978622] R10: 9ad5b0232640 R11: 9ad5a9cd4840 R12: 
> > 0002
> > [  230.985745] R13: 0018 R14: 0001 R15: 
> > 9ad5a9d32800
> > [  230.992866] FS:  () GS:9ad5bec8() 
> > knlGS:
> > [  231.000939] CS:  0010 DS:  ES:  CR0: 80050033
> > [  231.006680] CR2: 7f26cba069d0 CR3: 85a0a000 CR4: 
> > 000406e0
> > [  231.013802] Call Trace:
> > [  231.016254]  x86_pmu_read+0x9/0x10
> > [  231.019656]  perf_output_read+0x19f/0x410
> > [  231.023665]  ? __alloc_pages_nodemask+0xe8/0x1f0
> > [  231.028274]  perf_event_read_event+0xd2/0x110
> > [  231.032628]  ? x86_pmu_del+0x3e/0x130
> > [  231.036290]  ? __intel_pmu_enable_all.isra.12+0x27/0x90
> > [  231.041512]  ? intel_pmu_enable_all+0xb/0x10
> > [  231.045779]  ? x86_pmu_enable+0x25e/0x2f0
> > [  231.049787]  ? group_sched_out+0x8c/0xd0
> > [  231.053708]  ? perf_pmu_enable+0x22/0x30
> > [  231.057629]  ? update_group_times+0x13/0x40
> > [  231.061812]  ? list_del_event+0x66/0xc0
> > [  231.065647]  perf_event_exit_task+0x2fa/0x380
> 
> I suspect the problem is that exit schedules before it calls
> perf_event_exit_task. 

I'm not sure I follow; could you elaborate?

> We could just move it up to the beginning of exit. Untested
> patch here. Does that help?

I see the same behaviour with the patch below applied.

Thanks,
Mark.

> diff --git a/kernel/exit.c b/kernel/exit.c
> index 516acdb0e0ec..9a6f5f299588 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -779,6 +779,14 @@ void __noreturn do_exit(long code)
>   int group_dead;
>   TASKS_RCU(int tasks_rcu_i);
>  
> + /*
> +  * Flush inherited counters to the parent - before the parent
> +  * gets woken up by child-exit notifications.
> +  *
> +  * because of cgroup mode, must be called before cgroup_exit()
> +  */
> + perf_event_exit_task(tsk);
> +
>   profile_task_exit(tsk);
>   kcov_task_exit(tsk);
>  
> @@ -878,14 +886,6 @@ void __noreturn do_exit(long code)
>   exit_task_work(tsk);
>   exit_thread(tsk);
>  
> - /*
> -  * Flush inherited counters to the parent - before the parent
> -  * gets woken up by child-exit notifications.
> -  *
> -  * because of cgroup mode, must be called before cgroup_exit()
> -  */
> - perf_event_exit_task(tsk);
> -
>   sched_autogroup_exit_task(tsk);
>   cgroup_exit(tsk);
>  
> 

Re: New assembler warnings with binutils 2.29

[Arnd Bergmann]

On Fri, Aug 11, 2017 at 11:26 AM, Ard Biesheuvel
 wrote:
> On 11 August 2017 at 10:22, Catalin Marinas  wrote:
>> On Thu, Aug 10, 2017 at 01:13:22PM -0700, Laura Abbott wrote:
>>> Fedora rawhide recently upgraded to binutils 2.29 and this seems
>>> to produce new warnings:
>>>
>>> ./arch/arm64/include/asm/assembler.h: Assembler messages:
>>> ./arch/arm64/include/asm/assembler.h:125: Warning: ignoring attempt to 
>>> redefine built-in register 'lr'
>>>
>>> This is
>>>
>>> /*
>>>  * Register aliases.
>>>  */
>>> lr  .reqx30 // link register
>>
>> Strange, does gas now think 'lr' is a general purpose register (aliased
>> to x30)? It never was and IIRC the toolchain people many years ago
>> refused to add it, hence the alias above in the kernel. I wonder if they
>> added 'fp' as well...
>>
>> We could remove the alias and replace all 'lr' instances with 'x30'
>> throughout the kernel (no too many) or we add some #ifdef around the
>> above based on the binutils version.
>>
>
> This is annoying. Replacing x30 with lr achieves the opposite of the
> intent of the binutils change. And using #ifdefs is inaccurate,
> because you can't really test the binutils version only the GCC
> version, and those are not tightly coupled.
>
> Can you .unreq it?

adding the author of the change to cc

https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=62e20ed45e3da5f3ba695e4ee109317668180fe6

There probably was some reasoning behind the change and an
intended method for using it.

Arnd

Re: [RESEND PATCH 2/4] dt-bindings: add "reduced-width" property for Armada XP SDRAM controller

[Jan Lübbe]

On Thu, 2017-08-10 at 21:17 +, Chris Packham wrote:
> On 11/08/17 08:38, Rob Herring wrote:
> > On Mon, Aug 07, 2017 at 01:46:39PM +1200, Chris Packham wrote:
[...]  
> > > +Optional properties:
> > > + - marvell,reduced-width: some SoCs that use this SDRAM controller have
> > > +   a reduced pin count. On such systems "full" width is 32-bits and
> > > +   "half" width is 16-bits. Set this property to indicate that the SoC
> > > +   used is such a system.
> > 
> > Maybe you should just state what the width is.
> 
> Specifying a number like 64/32/16 is done in for some other properties I 
> dismissed that because what this is about how we interpret a 
> pin-strapping option. I guess "max-width = <64>;" and "max-width = 
> <32>"; would achieve the same.
> 
> > Or your compatible string should just be specific enough to know the
> > width.
> 
> I decided against a new compatible sting that because the IP block 
> really is the Armada-XP one and the existing compatible string is used 
> in other places (using multiple compatible strings would solve that).
> 
> I'm not too fussed which of the 3 options are used. Is there any 
> particular preference?

I'd prefer a specific compatible string, as it would avoid adding even
more properties if further difference turn up.

Rob, I seem to remember that some drivers match the top-level
compatible against a list of SoC variants to detect SoC-dependent
features in a generic IP block. Is that something you'd prefer instead?

Regards,
Jan

[PATCH] ASoC: Medfield: Delete an error message for a failed memory allocation in snd_mfld_mc_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 11 Aug 2017 11:25:41 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring 
---
 sound/soc/intel/boards/mfld_machine.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/sound/soc/intel/boards/mfld_machine.c 
b/sound/soc/intel/boards/mfld_machine.c
index 4e08885f37aa..6f44acfb4aae 100644
--- a/sound/soc/intel/boards/mfld_machine.c
+++ b/sound/soc/intel/boards/mfld_machine.c
@@ -376,10 +376,8 @@ static int snd_mfld_mc_probe(struct platform_device *pdev)
/* audio interrupt base of SRAM location where
 * interrupts are stored by System FW */
mc_drv_ctx = devm_kzalloc(&pdev->dev, sizeof(*mc_drv_ctx), GFP_ATOMIC);
-   if (!mc_drv_ctx) {
-   pr_err("allocation failed\n");
+   if (!mc_drv_ctx)
return -ENOMEM;
-   }
 
irq_mem = platform_get_resource_byname(
pdev, IORESOURCE_MEM, "IRQ_BASE");
-- 
2.14.0

Re: linux-next: manual merge of the akpm-current tree with the tip tree

[Peter Zijlstra]

On Fri, Aug 11, 2017 at 05:53:26PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got conflicts in:
> 
>   include/linux/mm_types.h
>   mm/huge_memory.c
> 
> between commit:
> 
>   8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")
> 
> from the tip tree and commits:
> 
>   16af97dc5a89 ("mm: migrate: prevent racy access to tlb_flush_pending")
>   a9b802500ebb ("Revert "mm: numa: defer TLB flush for THP migration as long 
> as possible"")
> 
> from the akpm-current tree.
> 
> The latter 2 are now in Linus' tree as well (but were not when I started
> the day).
> 
> The only way forward I could see was to revert
> 
>   8b1b436dd1cc ("mm, locking: Rework {set,clear,mm}_tlb_flush_pending()")
> 
> and the three following commits
> 
>   ff7a5fb0f1d5 ("overlayfs, locking: Remove smp_mb__before_spinlock() usage")
>   d89e588ca408 ("locking: Introduce smp_mb__after_spinlock()")
>   a9668cd6ee28 ("locking: Remove smp_mb__before_spinlock()")
> 
> before merging the akpm-current tree again.

Here's two patches that apply on top of tip.

Subject: mm: migrate: prevent racy access to tlb_flush_pending
From: Nadav Amit 
Date: Tue, 1 Aug 2017 17:08:12 -0700

Setting and clearing mm->tlb_flush_pending can be performed by multiple
threads, since mmap_sem may only be acquired for read in
task_numa_work(). If this happens, tlb_flush_pending might be cleared
while one of the threads still changes PTEs and batches TLB flushes.

This can lead to the same race between migration and
change_protection_range() that led to the introduction of
tlb_flush_pending. The result of this race was data corruption, which
means that this patch also addresses a theoretically possible data
corruption.

An actual data corruption was not observed, yet the race was
was confirmed by adding assertion to check tlb_flush_pending is not set
by two threads, adding artificial latency in change_protection_range()
and using sysctl to reduce kernel.numa_balancing_scan_delay_ms.

Fixes: 20841405940e ("mm: fix TLB flush race between migration, and
change_protection_range")


Cc: 
Cc: CC: 
Cc: Andy Lutomirski 
Signed-off-by: Nadav Amit 
Acked-by: Mel Gorman 
Acked-by: Rik van Riel 
Acked-by: Minchan Kim 
Signed-off-by: Peter Zijlstra (Intel) 
Link: http://lkml.kernel.org/r/20170802000818.4760-2-na...@vmware.com
---
 include/linux/mm_types.h |   29 +
 kernel/fork.c|2 +-
 mm/debug.c   |2 +-
 mm/mprotect.c|4 ++--
 4 files changed, 25 insertions(+), 12 deletions(-)

--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -493,7 +493,7 @@ struct mm_struct {
 	 * can move process memory needs to flush the TLB when moving a
 	 * PROT_NONE or PROT_NUMA mapped page.
 	 */
-	bool tlb_flush_pending;
+	atomic_t tlb_flush_pending;
 #endif
 #ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
 	/* See flush_tlb_batched_pending() */
@@ -535,11 +535,17 @@ static inline bool mm_tlb_flush_pending(
 	 * Must be called with PTL held; such that our PTL acquire will have
 	 * observed the store from set_tlb_flush_pending().
 	 */
-	return mm->tlb_flush_pending;
+	return atomic_read(&mm->tlb_flush_pending);
 }
-static inline void set_tlb_flush_pending(struct mm_struct *mm)
+
+static inline void init_tlb_flush_pending(struct mm_struct *mm)
 {
-	mm->tlb_flush_pending = true;
+	atomic_set(&mm->tlb_flush_pending, 0);
+}
+
+static inline void inc_tlb_flush_pending(struct mm_struct *mm)
+{
+	atomic_inc(&mm->tlb_flush_pending);
 	/*
 	 * The only time this value is relevant is when there are indeed pages
 	 * to flush. And we'll only flush pages after changing them, which
@@ -565,21 +571,28 @@ static inline void set_tlb_flush_pending
 	 * store is constrained by the TLB invalidate.
 	 */
 }
+
 /* Clearing is done after a TLB flush, which also provides a barrier. */
-static inline void clear_tlb_flush_pending(struct mm_struct *mm)
+static inline void dec_tlb_flush_pending(struct mm_struct *mm)
 {
 	/* see set_tlb_flush_pending */
-	mm->tlb_flush_pending = false;
+	atomic_dec(&mm->tlb_flush_pending);
 }
 #else
 static inline bool mm_tlb_flush_pending(struct mm_struct *mm)
 {
 	return false;
 }
-static inline void set_tlb_flush_pending(struct mm_struct *mm)
+
+static inline void init_tlb_flush_pending(struct mm_struct *mm)
 {
 }
-static inline void clear_tlb_flush_pending(struct mm_struct *mm)
+
+static inline void inc_tlb_flush_pending(struct mm_struct *mm)
+{
+}
+
+static inline void dec_tlb_flush_pending(struct mm_struct *mm)
 {
 }
 #endif
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -809,7 +809,7 @@ static struct mm_struct *mm_init(struct
 	mm_init_aio(mm);
 	mm_init_owner(mm, p);
 	mmu_notifier_mm_init(mm);
-	clear_tlb_flush_pending(mm);
+	init_tlb_flush_pending(mm);
 #if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
 	mm->pmd_huge_pte = NULL;
 #endif
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -159,7 +159,7 @@ void dump_mm(const s

Re: [PATCH v2 02/18] dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol

[Sudeep Holla]

On 10/08/17 20:28, Rob Herring wrote:
> On Fri, Aug 04, 2017 at 03:31:28PM +0100, Sudeep Holla wrote:
>> This patch adds devicetree binding for System Control and Management
>> Interface (SCMI) Message Protocol used between the Application Cores(AP)
>> and the System Control Processor(SCP). The MHU peripheral provides a
>> mechanism for inter-processor communication between SCP's M3 processor
>> and AP.
>>
>> SCP offers control and management of the core/cluster power states,
>> various power domain DVFS including the core/cluster, certain system
>> clocks configuration, thermal sensors and many others.
>>
>> SCMI protocol is developed as better replacement to the existing SCPI
>> which is not flexible and easily extensible.
>>
>> Cc: Rob Herring 
>> Cc: Mark Rutland 
>> Signed-off-by: Sudeep Holla 
>> ---
>>  Documentation/devicetree/bindings/arm/arm,scmi.txt | 174 
>> +
>>  1 file changed, 174 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt 
>> b/Documentation/devicetree/bindings/arm/arm,scmi.txt
>> new file mode 100644
>> index ..33c16be58e72
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt
>> @@ -0,0 +1,174 @@
>> +System Control and Management Interface (SCMI) Message Protocol
>> +--
>> +
>> +The SCMI is intended to allow agents such as OSPM to manage various 
>> functions
>> +that are provided by the hardware platform it is running on, including power
>> +and performance functions.
>> +
>> +This binding is intended to define the interface the firmware implementing
>> +the SCMI as described in ARM document number ARM DUI 0922B ("ARM System 
>> Control
>> +and Management Interface Platform Design Document")[0] provide for OSPM in
>> +the device tree.
>> +
>> +Required properties:
> 
> Please define this is a subnode of /firmware node.
> 

Thanks for pointing that out, I wasn't aware of that.

Ideally, should we move PSCI and SCPI also under that ?

Also should we contain all firmware bindings under
Documentation/devicetree/bindings/arm/firmware/ ?

[..]

>> +PM domain consumers
>> +===
> 
> How consumers work is already defined elsewhere.
> 

Agreed, will drop it.

[..]

>> +
>> +scmi_protocol: scmi@2e00 {
> 
> The unit address is not valid.
> 

Ah, copy paste, will drop. Need to fix in scpi bindings too.

>> +compatible = "arm,scmi";
>> +method = "mailbox-doorbell";
> 
> Is this not implied by the mboxes property? 
> 

Indeed, remnants from v1. I removed in the definition but left in the
example.

-- 
Regards,
Sudeep

Re: [v6 05/15] mm: don't accessed uninitialized struct pages

[Michal Hocko]

On Mon 07-08-17 16:38:39, Pavel Tatashin wrote:
> In deferred_init_memmap() where all deferred struct pages are initialized
> we have a check like this:
> 
> if (page->flags) {
> VM_BUG_ON(page_zone(page) != zone);
> goto free_range;
> }
> 
> This way we are checking if the current deferred page has already been
> initialized. It works, because memory for struct pages has been zeroed, and
> the only way flags are not zero if it went through __init_single_page()
> before.  But, once we change the current behavior and won't zero the memory
> in memblock allocator, we cannot trust anything inside "struct page"es
> until they are initialized. This patch fixes this.
> 
> This patch defines a new accessor memblock_get_reserved_pfn_range()
> which returns successive ranges of reserved PFNs.  deferred_init_memmap()
> calls it to determine if a PFN and its struct page has already been
> initialized.

Why don't we simply check the pfn against pgdat->first_deferred_pfn?

> Signed-off-by: Pavel Tatashin 
> Reviewed-by: Steven Sistare 
> Reviewed-by: Daniel Jordan 
> Reviewed-by: Bob Picco 
> ---
>  include/linux/memblock.h |  3 +++
>  mm/memblock.c| 54 
> ++--
>  mm/page_alloc.c  | 11 +-
>  3 files changed, 61 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index bae11c7e7bf3..b6a2a610f5e1 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -320,6 +320,9 @@ int memblock_is_map_memory(phys_addr_t addr);
>  int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
>  bool memblock_is_reserved(phys_addr_t addr);
>  bool memblock_is_region_reserved(phys_addr_t base, phys_addr_t size);
> +void memblock_get_reserved_pfn_range(unsigned long pfn,
> +  unsigned long *pfn_start,
> +  unsigned long *pfn_end);
>  
>  extern void __memblock_dump_all(void);
>  
> diff --git a/mm/memblock.c b/mm/memblock.c
> index bf14aea6ab70..08f449acfdd1 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1580,7 +1580,13 @@ void __init memblock_mem_limit_remove_map(phys_addr_t 
> limit)
>   memblock_cap_memory_range(0, max_addr);
>  }
>  
> -static int __init_memblock memblock_search(struct memblock_type *type, 
> phys_addr_t addr)
> +/**
> + * Return index in regions array if addr is within the region. Otherwise
> + * return -1. If -1 is returned and *next_idx is not %NULL, sets it to the
> + * next region index or -1 if there is none.
> + */
> +static int __init_memblock memblock_search(struct memblock_type *type,
> +phys_addr_t addr, int *next_idx)
>  {
>   unsigned int left = 0, right = type->cnt;
>  
> @@ -1595,22 +1601,26 @@ static int __init_memblock memblock_search(struct 
> memblock_type *type, phys_addr
>   else
>   return mid;
>   } while (left < right);
> +
> + if (next_idx)
> + *next_idx = (right == type->cnt) ? -1 : right;
> +
>   return -1;
>  }
>  
>  bool __init memblock_is_reserved(phys_addr_t addr)
>  {
> - return memblock_search(&memblock.reserved, addr) != -1;
> + return memblock_search(&memblock.reserved, addr, NULL) != -1;
>  }
>  
>  bool __init_memblock memblock_is_memory(phys_addr_t addr)
>  {
> - return memblock_search(&memblock.memory, addr) != -1;
> + return memblock_search(&memblock.memory, addr, NULL) != -1;
>  }
>  
>  int __init_memblock memblock_is_map_memory(phys_addr_t addr)
>  {
> - int i = memblock_search(&memblock.memory, addr);
> + int i = memblock_search(&memblock.memory, addr, NULL);
>  
>   if (i == -1)
>   return false;
> @@ -1622,7 +1632,7 @@ int __init_memblock memblock_search_pfn_nid(unsigned 
> long pfn,
>unsigned long *start_pfn, unsigned long *end_pfn)
>  {
>   struct memblock_type *type = &memblock.memory;
> - int mid = memblock_search(type, PFN_PHYS(pfn));
> + int mid = memblock_search(type, PFN_PHYS(pfn), NULL);
>  
>   if (mid == -1)
>   return -1;
> @@ -1646,7 +1656,7 @@ int __init_memblock memblock_search_pfn_nid(unsigned 
> long pfn,
>   */
>  int __init_memblock memblock_is_region_memory(phys_addr_t base, phys_addr_t 
> size)
>  {
> - int idx = memblock_search(&memblock.memory, base);
> + int idx = memblock_search(&memblock.memory, base, NULL);
>   phys_addr_t end = base + memblock_cap_size(base, &size);
>  
>   if (idx == -1)
> @@ -1655,6 +1665,38 @@ int __init_memblock 
> memblock_is_region_memory(phys_addr_t base, phys_addr_t size
>memblock.memory.regions[idx].size) >= end;
>  }
>  
> +/**
> + * memblock_get_reserved_pfn_range - search for the next reserved region
> + *
> + * @pfn: start searching from this pfn.
> + *
> + * RETURNS:
> + * [start_pfn, end_pfn), where start_pfn >= pfn. If none is found
> + *

Re: RCU stall when using function_graph

[Daniel Lezcano]

On 10/08/2017 23:39, Paul E. McKenney wrote:
> On Thu, Aug 10, 2017 at 11:45:09AM +0200, Daniel Lezcano wrote:

[ ... ]

>> Nothing coming in mind but may be worth to mention the slowness of the
>> CPU is the aggravating factor. In particular I was able to reproduce the
>> issue by setting to the min CPU frequency. With the ondemand governor,
>> we can have the frequency high (hence enough CPU power) at the moment we
>> set the function_graph because another CPU is loaded (and both CPUs are
>> sharing the same clock line). The system became stuck at the moment the
>> other CPU went idle with the lowest frequency. That introduced
>> randomness in the issue and made hard to figure out why the RCU stall
>> was happening.
> 
> Adding this, then?

Yes, sure.

Thanks Paul.

  -- Daniel

> 
> 
> commit f7d9ce95064f76be583c775fac32076fa59f1617
> Author: Paul E. McKenney 
> Date:   Thu Aug 10 14:33:17 2017 -0700
> 
> documentation: Slow systems can stall RCU grace periods
> 
> If a fast system has a worst-case grace-period duration of (say) ten
> seconds, then running the same workload on a system ten times as slow
> will get you an RCU CPU stall warning given default stall-warning
> timeout settings.  This commit therefore adds this possibility to
> stallwarn.txt.
> 
> Reported-by: Daniel Lezcano 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
> index 21b8913acbdf..238acbd94917 100644
> --- a/Documentation/RCU/stallwarn.txt
> +++ b/Documentation/RCU/stallwarn.txt
> @@ -70,6 +70,12 @@ o  A periodic interrupt whose handler takes longer than 
> the time
>   considerably longer than normal, which can in turn result in
>   RCU CPU stall warnings.
>  
> +oTesting a workload on a fast system, tuning the stall-warning
> + timeout down to just barely avoid RCU CPU stall warnings, and then
> + running the same workload with the same stall-warning timeout on a
> + slow system.  Note that thermal throttling and on-demand governors
> + can cause a single system to be sometimes fast and sometimes slow!
> +
>  oA hardware or software issue shuts off the scheduler-clock
>   interrupt on a CPU that is not in dyntick-idle mode.  This
>   problem really has happened, and seems to be most likely to
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v2 2/6] edac: synopsys: Add platform specific structures for ddrc controller

[Michal Simek]

On 11.8.2017 11:22, Borislav Petkov wrote:
> On Fri, Aug 11, 2017 at 11:16:15AM +0200, Michal Simek wrote:
>> https://lkml.org/lkml/2017/8/7/105
>> ACK by Rob yesterday.
> 
> Ok, pls bounce it to me as I don't have it.

ok.

> 
> Also, pls refrain from using lkml.org. Simply do:
> 
> http://lkml.kernel.org/r/

Interesting. I have never seen this before.

http://lkml.kernel.org/r/91fd6532076e4c905b5a228d852bba4941c54a28.1502091561.git.michal.si...@xilinx.com

> 
>> I am using patman - u-boot tools for sending patch. It read MAINTAINERS
>> file and copy right people.
>> It has option to explicitly CC people. I need to resend this as v3
>> anyway that's why I will add you there.
> 
> Yes, if you send cross-maintainer changes, please make sure to CC them on all
> patches because otherwise stuff like that happens and people start wondering
> where is the rest and so on.

ok. Anyway do you see something else what I should fix in v3?

Thanks,
Michal

Re: [PATCH v2 3/5] arm64: dts: rockchip: add tsadc node for rk3328 SoC

[rocky.hao]

在 2017/8/11 14:38, Caesar Wang 写道:

在 2017年08月04日 16:06, Rocky Hao 写道:

add tsadc needed main information for rk3328 SoC.
5Hz is the max clock rate supported by tsadc module.

Signed-off-by: Rocky Hao 
---
Change in v2:
- remove gerrit Change-Id

  arch/arm64/boot/dts/rockchip/rk3328.dtsi | 20 
  1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi

index db4b2708084d..186fb93fdffd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -308,6 +308,26 @@
  interrupts = ;
  };
+tsadc: tsadc@ff25 {
+compatible = "rockchip,rk3328-tsadc";
+reg = <0x0 0xff25 0x0 0x100>;
+interrupts = ;
+rockchip,grf = <&grf>;
+clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>;
+clock-names = "tsadc", "apb_pclk";
+assigned-clocks = <&cru SCLK_TSADC>;
+assigned-clock-rates = <5>;
+resets = <&cru SRST_TSADC>;
+reset-names = "tsadc-apb";
+pinctrl-names = "init", "default", "sleep";
+pinctrl-0 = <&otp_gpio>;
+pinctrl-1 = <&otp_out>;
+pinctrl-2 = <&otp_gpio>;
+#thermal-sensor-cells = <1>;


Only one sensor, so maybe the value should be 0.
Caesar, #thermal-sensor-cells means parameter counts used to match the 
proper sensor registered. Both 0 and 1 work well.


Case 0, i.e. #thermal-sensor-cells = <0>, it uses the default channel 
number 0 to match tsadc channal.
Case 1, i.e. #thermal-sensor-cells = <1>, it uses the setting 
"thermal-sensors = <&tsadc 0>;" to match tsadc channal.


Case 1 provides more readable info than case 0. By my understanding, 
using the default value such as case 0, is not a good coding style.





+rockchip,hw-tshut-temp = <10>;
+status = "disabled";
+};
+
  saradc: adc@ff28 {
  compatible = "rockchip,rk3328-saradc", 
"rockchip,rk3399-saradc";

  reg = <0x0 0xff28 0x0 0x100>;

Re: [PATCH v8 06/14] lockdep: Detect and handle hist_lock ring buffer overwrite

[Byungchul Park]

On Fri, Aug 11, 2017 at 05:52:02PM +0900, Byungchul Park wrote:
> On Fri, Aug 11, 2017 at 04:03:29PM +0800, Boqun Feng wrote:
> > Thanks for taking a look at it ;-)
> 
> I rather appriciate it.
> 
> > > > @@ -5005,7 +5003,7 @@ static int commit_xhlock(struct cross_lock 
> > > > *xlock, struct hist_lock *xhlock)
> > > >  static void commit_xhlocks(struct cross_lock *xlock)
> > > >  {
> > > > unsigned int cur = current->xhlock_idx;
> > > > -   unsigned int prev_hist_id = xhlock(cur).hist_id;
> > > > +   unsigned int prev_hist_id = cur + 1;
> > > 
> > > I should have named it another. Could you suggest a better one?
> > > 
> > 
> > I think "prev" is fine, because I thought the "previous" means the
> > xhlock item we visit _previously_.
> > 
> > > > unsigned int i;
> > > >  
> > > > if (!graph_lock())
> > > > @@ -5030,7 +5028,7 @@ static void commit_xhlocks(struct cross_lock 
> > > > *xlock)
> > > >  * hist_id than the following one, which is 
> > > > impossible
> > > >  * otherwise.
> > > 
> > > Or we need to modify the comment so that the word 'prev' does not make
> > > readers confused. It was my mistake.
> > > 
> > 
> > I think the comment needs some help, but before you do it, could you
> > have another look at what Peter proposed previously? Note you have a
> > same_context_xhlock() check in the commit_xhlocks(), so the your
> > previous overwrite case actually could be detected, I think.
> 
> What is the previous overwrite case?
> 
> ppi
> iii
> 
> Do you mean this one? I missed the check of same_context_xhlock(). Yes,
> peterz's suggestion also seems to work.
> 
> > However, one thing may not be detected is this case:
> > 
> > pp
> > wrapped >   www
> 
> To be honest, I think your suggestion is more natual, with which this
> case would be also covered.
> 
> > 
> > where p: process and w: worker.
> > 
> > , because p and w are in the same task_irq_context(). I discussed this
> > with Peter yesterday, and he has a good idea: unconditionally do a reset
> > on the ring buffer whenever we do a crossrelease_hist_end(XHLOCK_PROC).

Ah, ok. You meant 'whenever _process_ context exit'.

I need more time to be sure, but anyway for now it seems to work with
giving up some chances for remaining xhlocks.

But, I am not sure if it's still true even in future and the code can be
maintained easily. I think your approach is natural and neat enough for
that purpose. What problem exists with yours?

> > Basically it means we empty the lock history whenever we finished a
> > worker function in a worker thread or we are about to return to
> > userspace after we finish the syscall. This could further save some
> > memory and so I think this may be better than my approach.
> 
> Do you mean reset _whenever_ hard irq exit, soft irq exit or work exit?
> Why should we give up chances to check dependencies of remaining xhlocks
> whenever each exit? Am I understanding correctly?
> 
> I am just curious. Does your approach have some problems?
> 
> Thanks,
> Byungchul

Re: [PATCH -v2 1/4] mm: Rework {set,clear,mm}_tlb_flush_pending()

[Peter Zijlstra]

On Wed, Aug 02, 2017 at 01:38:38PM +0200, Peter Zijlstra wrote:
>   /*
> +  * The only time this value is relevant is when there are indeed pages
> +  * to flush. And we'll only flush pages after changing them, which
> +  * requires the PTL.
> +  *
> +  * So the ordering here is:
> +  *
> +  *  mm->tlb_flush_pending = true;
> +  *  spin_lock(&ptl);
> +  *  ...
> +  *  set_pte_at();
> +  *  spin_unlock(&ptl);
> +  *
> +  *  spin_lock(&ptl)
> +  *  mm_tlb_flush_pending();
> +  *  

Crud, so while I was rebasing Nadav's patches I realized that this does
not in fact work for PPC and split PTL. Because the PPC lwsync relies on
the address dependency to actual produce the ordering.

Also, since Nadav switched to atomic_inc/atomic_dec, I'll send a patch
to add smp_mb__after_atomic(), and

> +  *  spin_unlock(&ptl);
> +  *
> +  *  flush_tlb_range();
> +  *  mm->tlb_flush_pending = false;
> +  *
> +  * So the =true store is constrained by the PTL unlock, and the =false
> +  * store is constrained by the TLB invalidate.
>*/
>  }
>  /* Clearing is done after a TLB flush, which also provides a barrier. */
>  static inline void clear_tlb_flush_pending(struct mm_struct *mm)
>  {
> + /* see set_tlb_flush_pending */

smp_mb__before_atomic() here. That also avoids the whole reliance on the
tlb_flush nonsense.

It will overstuff on barriers on some platforms though :/

>   mm->tlb_flush_pending = false;
>  }

[RFC] sched/fair: Use wake_q length as a hint for wake_wide

[Brendan Jackman]

This patch adds a parameter to select_task_rq, sibling_count_hint
allowing the caller, where it has this information, to inform the
sched_class the number of tasks that are being woken up as part of
the same event.

The wake_q mechanism is one case where this information is available.

select_task_rq_fair can then use the information to detect that it
needs to widen the search space for task placement in order to avoid
overloading the last-level cache domain's CPUs.

   * * *

The reason I am investigating this change is the following use case
on ARM big.LITTLE (asymmetrical CPU capacity): 1 task per CPU, which
all repeatedly do X amount of work then
pthread_barrier_wait (i.e. sleep until the last task finishes its X
and hits the barrier). On big.LITTLE, the tasks which get a "big" CPU
finish faster, and then those CPUs pull over the tasks that are still
running:

 v CPU v   ->time->

-
   0  (big) 1  /333
-
   1  (big) 2   /444|
-
   2  (LITTLE)  33/
-
   3  (LITTLE)  44/
-

Now when task 4 hits the barrier (at |) and wakes the others up,
there are 4 tasks with prev_cpu= and 0 tasks with
prev_cpu=. want_affine therefore means that we'll only look
in CPUs 0 and 1 (sd_llc), so tasks will be unnecessarily coscheduled
on the bigs until the next load balance, something like this:

 v CPU v   ->time->


   0  (big) 1  /333  31313\3

   1  (big) 2   /444|424\444

   2  (LITTLE)  33/  \22

   3  (LITTLE)  44/\

 ^^^
   underutilization

So, I'm trying to get want_affine = 0 for these tasks.

I don't _think_ any incarnation of the wakee_flips mechanism can help
us here because which task is waker and which tasks are wakees
generally changes with each iteration.

However pthread_barrier_wait (or more accurately FUTEX_WAKE) has the
nice property that we know exactly how many tasks are being woken, so
we can cheat.

It might be a disadvantage that we "widen" _every_ task that's woken in
an event, while select_idle_sibling would work fine for the first
sd_llc_size - 1 tasks.

IIUC, if wake_affine() behaves correctly this trick wouldn't be
necessary on SMP systems, so it might be best guarded by the presence
of SD_ASYM_CPUCAPACITY?

   * * *

Final note..

In order to observe "perfect" behaviour for this use case, I also had
to disable the TTWU_QUEUE sched feature. Suppose during the wakeup
above we are working through the work queue and have placed tasks 3
and 2, and are about to place task 1:

 v CPU v   ->time->

--
   0  (big) 1  /333  3
--
   1  (big) 2   /444|4
--
   2  (LITTLE)  33/  2
--
   3  (LITTLE)  44/  <- Task 1 should go here
--

If TTWU_QUEUE is enabled, we will not yet have enqueued task
2 (having instead sent a reschedule IPI) or attached its load to CPU
2. So we are likely to also place task 1 on cpu 2. Disabling
TTWU_QUEUE means that we enqueue task 2 before placing task 1,
solving this issue. TTWU_QUEUE is there to minimise rq lock
contention, and I guess that this contention is less of an issue on
big.LITTLE systems since they have relatively few CPUs, which
suggests the trade-off makes sense here.

Signed-off-by: Brendan Jackman 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Josef Bacik 
Cc: Joel Fernandes 
Cc: Mike Galbraith 
Cc: Matt Fleming 
---
 include/linux/sched/wake_q.h |  2 ++
 kernel/sched/core.c  | 34 +++---
 kernel/sched/deadline.c  |  3 ++-
 kernel/sched/fair.c  | 17 +++--
 kernel/sched/idle_task.c |  3 ++-
 kernel/sched/rt.c|  3 ++-
 kernel/sched/sched.h |  3 ++-
 kernel/sched/stop_task.c |  3 ++-
 8 files changed, 46 insertions(+), 22 deletions(-)

diff --git a/include/linux/sched/wake_q.h b/include/linux/sched/wake_q.h
index d03d8a9047dc..607a888eb35b 100644
--- a/include/linux/sched/wake_q.h
+++ b/include/linux/sched/wake_q.h
@@ -33,6 +33,7 @@
 struct wake_q_head {
struct wake_q_node *first;
struct wake_q_node **lastp;
+   int count;
 };
 
 #define WAKE_Q_TAIL ((struct wake_q_node *) 0x01)
@@ -44,6 +45,7 @@ static inline void wake_q_init(struct wake_q_head *head)
 {
head->first = WAKE_Q_TAIL;
head->lastp = &head->first;
+