Re: [PATCH 00/12] selftests: Miscellaneous fixes

2019-01-17 Thread Geert Uytterhoeven
Hi Yamada-san,

On Fri, Jan 18, 2019 at 5:15 AM Masahiro Yamada
 wrote:
> On Mon, Jan 14, 2019 at 10:52 PM Geert Uytterhoeven
>  wrote:
> > This patch series contains several build fixes and cleanups for issues I
> > encountered when trying to cross-build an rtctest binary in a separate
> > output directory (like I use for all my kernel builds).
>
> Geert,
> Thanks for working on this!
>
> My fundamental question is,
> why did tools/ opt out Kbuild?

Good question.  I think it originally started as a separate small project.

> I think lots of mess comes in
> in order to support
>   cd tools/gpio; make
>
> instead of
>
>   make tools/gpio/
>
> Lots of files are duplicated in tools/build/
> in order to invent a different build system for tools/

I agree switching to kbuild would be the best solution.
Unfortunately my kbuild foo is not strong enough...

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH] sched/wait: introduce wait_event_freezable_hrtimeout

2019-01-17 Thread Hugo Lefeuvre
Hi Greg,

> > introduce wait_event_freezable_hrtimeout, an interruptible and freezable
> > version of wait_event_hrtimeout.
> > 
> > simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using this
> > newly added helper and remove useless includes.
> > 
> > Signed-off-by: Hugo Lefeuvre 
> > ---
> >  drivers/staging/android/vsoc.c | 69 +-
> >  include/linux/wait.h   | 25 ++--
> 
> code in drivers/staging/ should be self-contained, and not, if at all
> possible, ever force additional changes on "core" kernel code.
> 
> Are you sure that the vsoc code can't use one of the current wait
> macros?

As far as I know there is no macro implementing freezable wait with high
resolution timeout.

> Why is it so special and unique that no one else in the kernel
> has ever needed this before it came along?

many wait_event_X() (_exclusive, _interruptible, _timeout) functions have a
freezable counterpart. wait_event_hrtimeout() doesn't, probably because it
is relatively new (and seemingly quite unused).

If there is a wait_event_hrtimeout() function, it makes sense to me to have
wait_event_freezable_hrtimeout().

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature


Re: [PATCH 3/4] crypto: hisilicon: Add HiSilicon ZIP accelerator support

2019-01-17 Thread Zhou Wang
On 2019/1/18 12:55, Herbert Xu wrote:
> On Wed, Jan 16, 2019 at 10:12:47PM +0800, Zhou Wang wrote:
>>
>> A stupid question: how do we test scomp alg?
>>
>> It seems we can not use general comp API, e.g. crypto_alloc_comp
>> to do this.
>>
>> Could you give me any clue about this?
> 
> scomp algorithms are allocated through crypto_alloc_acomp.

A little strange, but let me try firstly.

However, another question is that seems other subsystems in kernel,
e.g. zswap still use crypto_alloc_comp. So we'd better register this
ZIP engine using both cryto_alloc_comp and scomp/acomp interface to
make it compatible with other subsystems?

Best,
Zhou

> 
> Thanks,
> 



[PATCH 3/4] irq: imx-irqsteer: change to use reg_num instead of irq_group

2019-01-17 Thread Aisheng Dong
One group can manage 64 interrupts by using two registers (e.g. STATUS/SET).
However, the integrated irqsteer may support only 32 interrupts which
needs only one register in a group. But the current driver assume there's
a mininum of two registers in a group which result in a wrong register map
for 32 interrupts per channel irqsteer. Let's use the reg_num caculated by
interrupts per channel instead of irq_group to cover this case.

Cc: Marc Zyngier 
Cc: Rob Herring 
Cc: Lucas Stach 
Cc: Shawn Guo 
Signed-off-by: Dong Aisheng 
---
 drivers/irqchip/irq-imx-irqsteer.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/irqchip/irq-imx-irqsteer.c 
b/drivers/irqchip/irq-imx-irqsteer.c
index 5b3f1d7..1bebf0a 100644
--- a/drivers/irqchip/irq-imx-irqsteer.c
+++ b/drivers/irqchip/irq-imx-irqsteer.c
@@ -13,7 +13,7 @@
 #include 
 #include 
 
-#define CTRL_STRIDE_OFF(_t, _r)(_t * 8 * _r)
+#define CTRL_STRIDE_OFF(_t, _r)(_t * 4 * _r)
 #define CHANCTRL   0x0
 #define CHANMASK(n, t) (CTRL_STRIDE_OFF(t, 0) + 0x4 * (n) + 0x4)
 #define CHANSET(n, t)  (CTRL_STRIDE_OFF(t, 1) + 0x4 * (n) + 0x4)
@@ -26,7 +26,7 @@ struct irqsteer_data {
struct clk  *ipg_clk;
int irq;
raw_spinlock_t  lock;
-   int irq_groups;
+   int reg_num;
int channel;
struct irq_domain   *domain;
u32 *saved_reg;
@@ -35,7 +35,7 @@ struct irqsteer_data {
 static int imx_irqsteer_get_reg_index(struct irqsteer_data *data,
  unsigned long irqnum)
 {
-   return (data->irq_groups * 2 - irqnum / 32 - 1);
+   return (data->reg_num - irqnum / 32 - 1);
 }
 
 static void imx_irqsteer_irq_unmask(struct irq_data *d)
@@ -46,9 +46,9 @@ static void imx_irqsteer_irq_unmask(struct irq_data *d)
u32 val;
 
raw_spin_lock_irqsave(&data->lock, flags);
-   val = readl_relaxed(data->regs + CHANMASK(idx, data->irq_groups));
+   val = readl_relaxed(data->regs + CHANMASK(idx, data->reg_num));
val |= BIT(d->hwirq % 32);
-   writel_relaxed(val, data->regs + CHANMASK(idx, data->irq_groups));
+   writel_relaxed(val, data->regs + CHANMASK(idx, data->reg_num));
raw_spin_unlock_irqrestore(&data->lock, flags);
 }
 
@@ -60,9 +60,9 @@ static void imx_irqsteer_irq_mask(struct irq_data *d)
u32 val;
 
raw_spin_lock_irqsave(&data->lock, flags);
-   val = readl_relaxed(data->regs + CHANMASK(idx, data->irq_groups));
+   val = readl_relaxed(data->regs + CHANMASK(idx, data->reg_num));
val &= ~BIT(d->hwirq % 32);
-   writel_relaxed(val, data->regs + CHANMASK(idx, data->irq_groups));
+   writel_relaxed(val, data->regs + CHANMASK(idx, data->reg_num));
raw_spin_unlock_irqrestore(&data->lock, flags);
 }
 
@@ -94,13 +94,13 @@ static void imx_irqsteer_irq_handler(struct irq_desc *desc)
 
chained_irq_enter(irq_desc_get_chip(desc), desc);
 
-   for (i = 0; i < data->irq_groups * 64; i += 32) {
+   for (i = 0; i < data->reg_num * 32; i += 32) {
int idx = imx_irqsteer_get_reg_index(data, i);
unsigned long irqmap;
int pos, virq;
 
irqmap = readl_relaxed(data->regs +
-  CHANSTATUS(idx, data->irq_groups));
+  CHANSTATUS(idx, data->reg_num));
 
for_each_set_bit(pos, &irqmap, 32) {
virq = irq_find_mapping(data->domain, pos + i);
@@ -146,12 +146,15 @@ static int imx_irqsteer_probe(struct platform_device 
*pdev)
 
raw_spin_lock_init(&data->lock);
 
-   of_property_read_u32(np, "fsl,irq-groups", &data->irq_groups);
+   of_property_read_u32(np, "fsl,chan-irq-number", &data->reg_num);
of_property_read_u32(np, "fsl,channel", &data->channel);
 
+   /* one register bit map represents 32 input interrupts */
+   data->reg_num /= 32;
+
if (IS_ENABLED(CONFIG_PM_SLEEP)) {
data->saved_reg = devm_kzalloc(&pdev->dev,
-   sizeof(u32) * data->irq_groups * 2,
+   sizeof(u32) * data->reg_num,
GFP_KERNEL);
if (!data->saved_reg)
return -ENOMEM;
@@ -166,7 +169,7 @@ static int imx_irqsteer_probe(struct platform_device *pdev)
/* steer all IRQs into configured channel */
writel_relaxed(BIT(data->channel), data->regs + CHANCTRL);
 
-   data->domain = irq_domain_add_linear(np, data->irq_groups * 64,
+   data->domain = irq_domain_add_linear(np, data->reg_num * 32,
 &imx_irqsteer_domain_ops, data);
if (!data->domain) {
dev_err(&pdev->dev, "failed to 

[PATCH 1/4] dt-binding: irq: imx-irqsteer: use irq number per channel instead of group number

2019-01-17 Thread Aisheng Dong
Not all 64 interrupts may be used in one group. e.g. most irqsteer in
imx8qxp and imx8qm subsystems supports only 32 interrupts.

As the IP integration parameters are Channel number and interrupts number,
let's use fsl,irqs-per-chan to represents how many interrupts supported
by this irqsteer channel.

Cc: Marc Zyngier 
Cc: Rob Herring 
Cc: Lucas Stach 
Cc: Shawn Guo 
Cc: devicet...@vger.kernel.org
Signed-off-by: Dong Aisheng 
---
 .../devicetree/bindings/interrupt-controller/fsl,irqsteer.txt   | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt 
b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
index 45790ce..eaabcda 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
@@ -16,8 +16,8 @@ Required properties:
 - #interrupt-cells: Specifies the number of cells needed to encode an
   interrupt source. The value must be 1.
 - fsl,channel: The output channel that all input IRQs should be steered into.
-- fsl,irq-groups: Number of IRQ groups managed by this controller instance.
-  Each group manages 64 input interrupts.
+- fsl,irqs-per-chan: Number of input interrupts per channel. Should be 
multiple of 32
+  input interrupts and up to 512 interrupts.
 
 Example:
 
@@ -28,7 +28,7 @@ Example:
clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
clock-names = "ipg";
fsl,channel = <0>;
-   fsl,irq-groups = <1>;
+   fsl,irqs-per-chan= <64>;
interrupt-controller;
#interrupt-cells = <1>;
};
-- 
2.7.4



[PATCH 2/4] dt-bindings: irq: imx-irqsteer: add multi output interrupts support

2019-01-17 Thread Aisheng Dong
One irqsteer channel can support up to 8 output interrupts.

Cc: Marc Zyngier 
Cc: Rob Herring 
Cc: Lucas Stach 
Cc: Shawn Guo 
Cc: devicet...@vger.kernel.org
Signed-off-by: Dong Aisheng 
---
 .../devicetree/bindings/interrupt-controller/fsl,irqsteer.txt| 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt 
b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
index eaabcda..beeed4a 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
@@ -6,8 +6,9 @@ Required properties:
- "fsl,imx8m-irqsteer"
- "fsl,imx-irqsteer"
 - reg: Physical base address and size of registers.
-- interrupts: Should contain the parent interrupt line used to multiplex the
-  input interrupts.
+- interrupts: Should contain the up to 8 parent interrupt lines used to
+  multiplex the input interrupts. They should be sepcified seqencially
+  from output 0 to 7. NOTE at least one output interrupt has to be specified.
 - clocks: Should contain one clock for entry in clock-names
   see Documentation/devicetree/bindings/clock/clock-bindings.txt
 - clock-names:
-- 
2.7.4



Re: [PATCH 1/2] checkstack.pl: Add blackfin support

2019-01-17 Thread Geert Uytterhoeven
Hi Bernhard,

Thanks for your patch!

On Thu, Jan 17, 2019 at 11:01 PM Bernhard Reutner-Fischer
 wrote:
> We've been carrying this since some time now.. Original submission:
> http://lists.busybox.net/pipermail/busybox/2007-August/028420.html
>
> Signed-off-by: Bernhard Reutner-Fischer 

A similar patch was merged in commit 1e9535a591cf003e ("Add stack
checking for Blackfin").

In the mean time, blackfin support was removed from Linux in commit
4ba66a9760722ccb ("arch: remove blackfin port"), and from checkstack in
commit e53a05a49e10c7cf ("scripts/checkstack.pl: remove blackfin support").

Nevertheless, I can imagine it's nice to have it, as I have used
checkstack for non-Linux projects, too ;-)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


[PATCH 0/4] irq: imx-irqsteer: add 32 interrupts chan and multi outputs support

2019-01-17 Thread Aisheng Dong
Not all 64 interrupts may be used in one group. e.g. most irqsteer in
imx8qxp and imx8qm subsystems supports only 32 interrupts.
And one irqsteer channel can support up to 8 output interrupts.

This patch series aims to support 32 interrupts chan and multi output
interrupts.

Tested on:
iMX8QXP MEK with MIPI CSI capture and DC Display
iMX8MQ EVK with MIPI DSI Display

Dong Aisheng (4):
  dt-binding: irq: imx-irqsteer: use irq number per channel instead of
group number
  dt-bindings: irq: imx-irqsteer: add multi output interrupts support
  irq: imx-irqsteer: change to use reg_num instead of irq_group
  irq: imx: irqsteer: add multi output interrupts support

 .../bindings/interrupt-controller/fsl,irqsteer.txt | 11 ++--
 drivers/irqchip/irq-imx-irqsteer.c | 74 ++
 2 files changed, 53 insertions(+), 32 deletions(-)

-- 
2.7.4



[PATCH 4/4] irq: imx: irqsteer: add multi output interrupts support

2019-01-17 Thread Aisheng Dong
One irqsteer channel can support up to 8 output interrupts.

Cc: Marc Zyngier 
Cc: Lucas Stach 
Cc: Shawn Guo 
Signed-off-by: Dong Aisheng 
---
 drivers/irqchip/irq-imx-irqsteer.c | 39 +++---
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/irqchip/irq-imx-irqsteer.c 
b/drivers/irqchip/irq-imx-irqsteer.c
index 1bebf0a..54802fa 100644
--- a/drivers/irqchip/irq-imx-irqsteer.c
+++ b/drivers/irqchip/irq-imx-irqsteer.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -21,10 +22,13 @@
 #define CHAN_MINTDIS(t)(CTRL_STRIDE_OFF(t, 3) + 0x4)
 #define CHAN_MASTRSTAT(t)  (CTRL_STRIDE_OFF(t, 3) + 0x8)
 
+#define CHAN_MAX_OUTPUT_INT0x8
+
 struct irqsteer_data {
void __iomem*regs;
struct clk  *ipg_clk;
-   int irq;
+   int irq[CHAN_MAX_OUTPUT_INT];
+   int irq_count;
raw_spinlock_t  lock;
int reg_num;
int channel;
@@ -117,7 +121,7 @@ static int imx_irqsteer_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct irqsteer_data *data;
struct resource *res;
-   int ret;
+   int i, ret;
 
data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -130,12 +134,6 @@ static int imx_irqsteer_probe(struct platform_device *pdev)
return PTR_ERR(data->regs);
}
 
-   data->irq = platform_get_irq(pdev, 0);
-   if (data->irq <= 0) {
-   dev_err(&pdev->dev, "failed to get irq\n");
-   return -ENODEV;
-   }
-
data->ipg_clk = devm_clk_get(&pdev->dev, "ipg");
if (IS_ERR(data->ipg_clk)) {
ret = PTR_ERR(data->ipg_clk);
@@ -177,8 +175,23 @@ static int imx_irqsteer_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
-   irq_set_chained_handler_and_data(data->irq, imx_irqsteer_irq_handler,
-data);
+   data->irq_count = of_irq_count(np);
+   if (!data->irq_count || data->irq_count > CHAN_MAX_OUTPUT_INT) {
+   clk_disable_unprepare(data->ipg_clk);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < data->irq_count; i++) {
+   data->irq[i] = irq_of_parse_and_map(np, i);
+   if (!data->irq[i]) {
+   clk_disable_unprepare(data->ipg_clk);
+   return -EINVAL;
+   }
+
+   irq_set_chained_handler_and_data(data->irq[i],
+imx_irqsteer_irq_handler,
+data);
+   }
 
platform_set_drvdata(pdev, data);
 
@@ -188,8 +201,12 @@ static int imx_irqsteer_probe(struct platform_device *pdev)
 static int imx_irqsteer_remove(struct platform_device *pdev)
 {
struct irqsteer_data *irqsteer_data = platform_get_drvdata(pdev);
+   int i;
+
+   for (i = 0; i < irqsteer_data->irq_count; i++)
+   irq_set_chained_handler_and_data(irqsteer_data->irq[i],
+NULL, NULL);
 
-   irq_set_chained_handler_and_data(irqsteer_data->irq, NULL, NULL);
irq_domain_remove(irqsteer_data->domain);
 
clk_disable_unprepare(irqsteer_data->ipg_clk);
-- 
2.7.4



Re: [PATCH 3/4] arm64: dts: meson: axg: add clk measure support

2019-01-17 Thread Jerome Brunet
On Thu, 2019-01-17 at 20:57 +0100, Martin Blumenstingl wrote:
> Hi Jerome,
> 
> On Thu, Jan 17, 2019 at 5:48 PM Jerome Brunet  wrote:
> > Add the clock measure device to the axg SoC family
> > 
> > Signed-off-by: Jerome Brunet 
> > ---
> >  arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > index 0e0abb1a03e2..94ea36a2417a 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > @@ -1611,6 +1611,11 @@
> > status = "disabled";
> > };
> > 
> > +   clk_msr: clock-sensor@18000 {
> in the dt-bindings specify "clock-measure@..."

That's the exemple, not a specification, AFAIK.
I'm not sure I see the problem ?

> this also applies to patch 4/4 from this series


Anyway, The node was not placed correctly in g12, I might as well rename it. I
don't really care

> 
> 
> [0] 
> https://elixir.bootlin.com/linux/v5.0-rc1/source/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt




Re: [PATCH 4/4] dax: "Hotplug" persistent memory for use like normal RAM

2019-01-17 Thread Yanmin Zhang

On 2019/1/17 下午11:17, Dave Hansen wrote:

On 1/17/19 12:19 AM, Yanmin Zhang wrote:



I didn't try pmem and I am wondering it's slower than DRAM.
Should a flag, such like _GFP_PMEM, be added to distinguish it from
DRAM?


Absolutely not. :)

Agree.



We already have performance-differentiated memory, and lots of ways to
enumerate and select it in the kernel (all of our NUMA infrastructure).

Kernel does manage memory like what you say.
My question is: with your patch, PMEM becomes normal RAM, then there is
a chance for kernel to allocate PMEM as DMA buffer.
Some super speed devices like 10Giga NIC, USB (SSIC connecting modem), 
might not work well if DMA buffer is in PMEM as it's slower than DRAM.


Should your patchset consider it?





PMEM is also just the first of many "kinds" of memory that folks want to
build in systems and use a "RAM".  We literally don't have space to put
a flag in for each type.




Re: [PATCH v6 2/2] dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller bindings

2019-01-17 Thread Marek Vasut
On 1/18/19 8:41 AM, masonccy...@mxic.com.tw wrote:
> Hi Marek,

Hi,

>> "Marek Vasut" 
>> 2019/01/18 下午 03:10
>>
>> > +Renesas R-Car Gen3 RPC-IF controller Device Tree Bindings
>> > +--
>> > +
>> > +Required properties:
>> > +- compatible: should be "renesas,rcar-gen3-rpc"
>> > +- #address-cells: should be 1
>> > +- #size-cells: should be 0
>> > +- reg: should contain three register areas:
>> > +   first for the base address of rpc-if registers,
>> > +   second for the direct mapping read mode and
>> > +   third for the write buffer area.
>> > +- reg-names: should contain "regs", "dirmap" and "wbuf"
>> > +- clock-names: should contain "rpc"
>> > +- clocks: should contain 1 entries for the module's clock
>> > +
>> > +Example:
>> > +
>> > +   rpc: rpc@ee20 {
>> > +      compatible = "renesas,rcar-gen3-rpc";
>> > +      reg = <0 0xee20 0 0x7fff>, <0 0x0800 0 0x400>,
>>
>> 0x7fff should be 0x8000 , right ?
> 
> RPC write buffer starts at 0xee208000 w/ 256 bytes size.

The size of the RPC-IF block is 0x8000 though, is it not ?

>> > +            <0 0xee208000 0 0x100>;
>>
>> Isn't the write buffer part of the RPC-IF register set ?
> 
> yep, but by Sergei and Geert's comments, we use a separate reg entry
> for this write buffer.
>  copy the replied email from Geert -
>> Maybe Geert or Marek could comment on it, thanks.
> 
> Given the writer buffer is separate from the other registers (it's in
> a different
> 4 KiB page, and thus may be at a different offset on future SoCs), and not
> present on RZ/A1, I think it's a good idea to use a separate reg entry
> for it.
> ---

+CC Chris, the RZ/A1 has no write buffer for the RPC ?

-- 
Best regards,
Marek Vasut


RE: [PATCH] dma: imx-sdma: pass ->dev to dma_alloc_coherent() API

2019-01-17 Thread Robin Gong
Reviewed-by: Robin Gong 
> -Original Message-
> From: Daniel Baluta
> Sent: 2019年1月11日 22:30
> To: vk...@kernel.org; dmaeng...@vger.kernel.org
> Cc: dl-linux-imx ; ker...@pengutronix.de;
> dan.j.willi...@intel.com; linux-kernel@vger.kernel.org; S.j. Wang
> ; Andy Duan ; Robin Gong
> ; Daniel Baluta 
> Subject: [PATCH] dma: imx-sdma: pass ->dev to dma_alloc_coherent() API
> 
> From: Andy Duan 
> 
> Pass ->dev to dma_alloc_coherent() API. We need this becase
> dma_alloc_coherent() makes use of dev parameter and receiving NULL will
> result in a crash.
> 
> Signed-off-by: Andy Duan 
> Signed-off-by: Daniel Baluta 
> ---
>  drivers/dma/imx-sdma.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index
> a2b0a0e71168..26133b78ced8 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -677,7 +677,7 @@ static int sdma_load_script(struct sdma_engine
> *sdma, void *buf, int size,
>   int ret;
>   unsigned long flags;
> 
> - buf_virt = dma_alloc_coherent(NULL, size, &buf_phys, GFP_KERNEL);
> + buf_virt = dma_alloc_coherent(sdma->dev, size, &buf_phys,
> GFP_KERNEL);
>   if (!buf_virt) {
>   return -ENOMEM;
>   }
> @@ -696,7 +696,7 @@ static int sdma_load_script(struct sdma_engine
> *sdma, void *buf, int size,
> 
>   spin_unlock_irqrestore(&sdma->channel_0_lock, flags);
> 
> - dma_free_coherent(NULL, size, buf_virt, buf_phys);
> + dma_free_coherent(sdma->dev, size, buf_virt, buf_phys);
> 
>   return ret;
>  }
> @@ -1182,7 +1182,7 @@ static int sdma_request_channel0(struct
> sdma_engine *sdma)  {
>   int ret = -EBUSY;
> 
> - sdma->bd0 = dma_zalloc_coherent(NULL, PAGE_SIZE, &sdma->bd0_phys,
> + sdma->bd0 = dma_zalloc_coherent(sdma->dev, PAGE_SIZE,
> &sdma->bd0_phys,
>   GFP_NOWAIT);
>   if (!sdma->bd0) {
>   ret = -ENOMEM;
> @@ -1205,8 +1205,8 @@ static int sdma_alloc_bd(struct sdma_desc *desc)
>   u32 bd_size = desc->num_bd * sizeof(struct sdma_buffer_descriptor);
>   int ret = 0;
> 
> - desc->bd = dma_zalloc_coherent(NULL, bd_size, &desc->bd_phys,
> - GFP_NOWAIT);
> + desc->bd = dma_zalloc_coherent(desc->sdmac->sdma->dev, bd_size,
> +&desc->bd_phys, GFP_NOWAIT);
>   if (!desc->bd) {
>   ret = -ENOMEM;
>   goto out;
> @@ -1219,7 +1219,8 @@ static void sdma_free_bd(struct sdma_desc *desc)
> {
>   u32 bd_size = desc->num_bd * sizeof(struct sdma_buffer_descriptor);
> 
> - dma_free_coherent(NULL, bd_size, desc->bd, desc->bd_phys);
> + dma_free_coherent(desc->sdmac->sdma->dev, bd_size, desc->bd,
> +   desc->bd_phys);
>  }
> 
>  static void sdma_desc_free(struct virt_dma_desc *vd) @@ -1842,7 +1843,7
> @@ static int sdma_init(struct sdma_engine *sdma)
>   /* Be sure SDMA has not started yet */
>   writel_relaxed(0, sdma->regs + SDMA_H_C0PTR);
> 
> - sdma->channel_control = dma_alloc_coherent(NULL,
> + sdma->channel_control = dma_alloc_coherent(sdma->dev,
>   MAX_DMA_CHANNELS * sizeof (struct sdma_channel_control) 
> +
>   sizeof(struct sdma_context_data),
>   &ccb_phys, GFP_KERNEL);
> --
> 2.17.1



[PATCH 1/1] irqchip: gpcv2: make config option visible

2019-01-17 Thread Aisheng Dong
Make GPCv2 config option visible, then user can select it in defconfig
for ARMv8 platforms.

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Shawn Guo 
Cc: Lucas Stach 
Cc: Andrey Smirnov 
Signed-off-by: Dong Aisheng 
---
 drivers/irqchip/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3d1e607..ed04d47 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -289,7 +289,8 @@ config RENESAS_H8S_INTC
select IRQ_DOMAIN
 
 config IMX_GPCV2
-   bool
+   bool "i.MX GPCv2 IRQ chip"
+   depends on ARCH_MXC || (COMPILE_TEST && OF)
select IRQ_DOMAIN
help
  Enables the wakeup IRQs for IMX platforms with GPCv2 block
-- 
2.7.4



Re: doc: stable-api-nonsense missing link

2019-01-17 Thread Greg KH
On Fri, Jan 18, 2019 at 08:20:31AM +0100, Greg KH wrote:
> On Thu, Jan 17, 2019 at 03:19:53PM -0700, Jonathan Corbet wrote:
> > On Thu, 17 Jan 2019 23:14:08 +0100
> > Federico Vaga  wrote:
> > 
> > > in this document
> > > 
> > > Documentation/process/stable-api-nonsense.rst
> > > 
> > > there is this note:
> > > 
> > > 
> > > 
> > > Is it possible to get it fixed with the proper link? I searched for it 
> > > without 
> > > success. If that comment is impossible to find I will send a patch to 
> > > remove 
> > > that note, but first I wanted to ask you if you know where to get it.
> > 
> > That sounds like a question for Greg (copied).  Given that this document
> > predates the Git era, though, I suspect that whatever reference that was
> > meant to be is long since lost.
> 
> It was referring to an email thread about this topic that happened at
> the time I wrote the document.  Let me try to dig through my archives,
> but given that it was written well over a decade ago, I don't know if I
> will be able to find it easily...

I can't find it at the moment, so taking out the text in <...> is fine
with me.

thanks,

greg k-h


Re: [PATCH v4 5/5] drm/bridge: lvds-encoder: add powerdown-gpios support

2019-01-17 Thread Andrzej Hajda
On 11.01.2019 16:19, Peter Rosin wrote:
> Optionally power down the LVDS-encoder when it is not in use.
>
> Signed-off-by: Peter Rosin 


Reviewed-by: Andrzej Hajda 


 --
Regards
Andrzej



Re: [PATCH v4 4/5] drm/bridge: lvds-encoder: add dev helper variable in .probe()

2019-01-17 Thread Andrzej Hajda
On 11.01.2019 16:19, Peter Rosin wrote:
> Make the code easier to read and modify.
>
> Signed-off-by: Peter Rosin 
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej



Re: doc: stable-api-nonsense missing link

2019-01-17 Thread Greg KH
On Thu, Jan 17, 2019 at 03:19:53PM -0700, Jonathan Corbet wrote:
> On Thu, 17 Jan 2019 23:14:08 +0100
> Federico Vaga  wrote:
> 
> > in this document
> > 
> > Documentation/process/stable-api-nonsense.rst
> > 
> > there is this note:
> > 
> > 
> > 
> > Is it possible to get it fixed with the proper link? I searched for it 
> > without 
> > success. If that comment is impossible to find I will send a patch to 
> > remove 
> > that note, but first I wanted to ask you if you know where to get it.
> 
> That sounds like a question for Greg (copied).  Given that this document
> predates the Git era, though, I suspect that whatever reference that was
> meant to be is long since lost.

It was referring to an email thread about this topic that happened at
the time I wrote the document.  Let me try to dig through my archives,
but given that it was written well over a decade ago, I don't know if I
will be able to find it easily...

thanks,

greg k-h


Re: [PATCH v2 1/8] RISC-V: Do not wait indefinitely in __cpu_up

2019-01-17 Thread Christoph Hellwig
On Thu, Jan 17, 2019 at 06:35:39PM -0800, Atish Patra wrote:
> On 1/15/19 5:51 AM, Christoph Hellwig wrote:
> > >   void *__cpu_up_stack_pointer[NR_CPUS];
> > >   void *__cpu_up_task_pointer[NR_CPUS];
> > > +static DECLARE_COMPLETION(cpu_running);
> > >   void __init smp_prepare_boot_cpu(void)
> > >   {
> > > @@ -81,6 +82,7 @@ void __init setup_smp(void)
> > >   int __cpu_up(unsigned int cpu, struct task_struct *tidle)
> > >   {
> > > + int ret = 0;
> > >   int hartid = cpuid_to_hartid_map(cpu);
> > >   tidle->thread_info.cpu = cpu;
> > > @@ -96,10 +98,15 @@ int __cpu_up(unsigned int cpu, struct task_struct 
> > > *tidle)
> > > task_stack_page(tidle) + THREAD_SIZE);
> > >   WRITE_ONCE(__cpu_up_task_pointer[hartid], tidle);
> > > - while (!cpu_online(cpu))
> > > - cpu_relax();
> > > + wait_for_completion_timeout(&cpu_running,
> > > + msecs_to_jiffies(1000));
> > 
> > Having a global completion here worries me.  I bet we have some higher
> > level serialization, but can we comment or even better lockdep assert on
> > that?
> > 
> 
> Yes. It is serialized from smp.c in smp_init(). It brings one cpu online
> at a time for preset_cpu mask.
> 
> Do we still need a lockdep assert ?

I guess the real lock is through cpu_hotplug_lock.  And yes, a comment
or even better lockdep assert would be good.


Re: [PATCH] sched/wait: introduce wait_event_freezable_hrtimeout

2019-01-17 Thread Greg Kroah-Hartman
On Thu, Jan 17, 2019 at 11:41:35PM +0100, Hugo Lefeuvre wrote:
> introduce wait_event_freezable_hrtimeout, an interruptible and freezable
> version of wait_event_hrtimeout.
> 
> simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using this
> newly added helper and remove useless includes.
> 
> Signed-off-by: Hugo Lefeuvre 
> ---
>  drivers/staging/android/vsoc.c | 69 +-
>  include/linux/wait.h   | 25 ++--

code in drivers/staging/ should be self-contained, and not, if at all
possible, ever force additional changes on "core" kernel code.

Are you sure that the vsoc code can't use one of the current wait
macros?  Why is it so special and unique that no one else in the kernel
has ever needed this before it came along?

thanks,

greg k-h


Re: [PATCH v6 2/2] dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller bindings

2019-01-17 Thread Marek Vasut
On 1/18/19 6:54 AM, Mason Yang wrote:
> Document the bindings used by the Renesas R-Car Gen3 RPC-IF controller.
> 
> Signed-off-by: Mason Yang 
> ---
>  .../devicetree/bindings/spi/spi-renesas-rpc.txt| 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt 
> b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> new file mode 100644
> index 000..9b5001e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> @@ -0,0 +1,37 @@
> +Renesas R-Car Gen3 RPC-IF controller Device Tree Bindings
> +--
> +
> +Required properties:
> +- compatible: should be "renesas,rcar-gen3-rpc"
> +- #address-cells: should be 1
> +- #size-cells: should be 0
> +- reg: should contain three register areas:
> + first for the base address of rpc-if registers,
> + second for the direct mapping read mode and
> + third for the write buffer area.
> +- reg-names: should contain "regs", "dirmap" and "wbuf"
> +- clock-names: should contain "rpc"
> +- clocks: should contain 1 entries for the module's clock
> +
> +Example:
> +
> + rpc: rpc@ee20 {
> + compatible = "renesas,rcar-gen3-rpc";
> + reg = <0 0xee20 0 0x7fff>, <0 0x0800 0 0x400>,

0x7fff should be 0x8000 , right ?

> +   <0 0xee208000 0 0x100>;

Isn't the write buffer part of the RPC-IF register set ?

> + reg-names = "regs", "dirmap", ";
> + clocks = <&cpg CPG_MOD 917>;
> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> + resets = <&cpg 917>;
> + clock-names = "rpc";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <4000>;
> + spi-tx-bus-width = <1>;
> + spi-rx-bus-width = <1>;
> + };
> + };
> 


-- 
Best regards,
Marek Vasut


[PATCH v3 1/3] swiotlb: fix comment on swiotlb_bounce()

2019-01-17 Thread Dongli Zhang
Fix the comment as swiotlb_bounce() is used to copy from original dma
location to swiotlb buffer during swiotlb_tbl_map_single(), while to
copy from swiotlb buffer to original dma location during
swiotlb_tbl_unmap_single().

Signed-off-by: Dongli Zhang 
---
 kernel/dma/swiotlb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1fb6fd6..1d8b377 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -385,7 +385,7 @@ void __init swiotlb_exit(void)
 }
 
 /*
- * Bounce: copy the swiotlb buffer back to the original dma location
+ * Bounce: copy the swiotlb buffer from or back to the original dma location
  */
 static void swiotlb_bounce(phys_addr_t orig_addr, phys_addr_t tlb_addr,
   size_t size, enum dma_data_direction dir)
-- 
2.7.4



[PATCH v3 2/3] swiotlb: add debugfs to track swiotlb buffer usage

2019-01-17 Thread Dongli Zhang
The device driver will not be able to do dma operations once swiotlb buffer
is full, either because the driver is using so many IO TLB blocks inflight,
or because there is memory leak issue in device driver. To export the
swiotlb buffer usage via debugfs would help the user estimate the size of
swiotlb buffer to pre-allocate or analyze device driver memory leak issue.

Signed-off-by: Dongli Zhang 
---
Changed since v1:
  * init debugfs with late_initcall (suggested by Robin Murphy)
  * create debugfs entries with debugfs_create_ulong(suggested by Robin Murphy)

Changed since v2:
  * some #ifdef folding (suggested by Konrad Rzeszutek Wilk)

 kernel/dma/swiotlb.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1d8b377..bedc9f9 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -34,6 +34,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_DEBUG_FS
+#include 
+#endif
 
 #include 
 #include 
@@ -73,6 +76,11 @@ phys_addr_t io_tlb_start, io_tlb_end;
 static unsigned long io_tlb_nslabs;
 
 /*
+ * The number of used IO TLB block
+ */
+static unsigned long io_tlb_used;
+
+/*
  * This is a free list describing the number of free entries available from
  * each index
  */
@@ -524,6 +532,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes)\n", 
size);
return DMA_MAPPING_ERROR;
 found:
+   io_tlb_used += nslots;
spin_unlock_irqrestore(&io_tlb_lock, flags);
 
/*
@@ -584,6 +593,8 @@ void swiotlb_tbl_unmap_single(struct device *hwdev, 
phys_addr_t tlb_addr,
 */
for (i = index - 1; (OFFSET(i, IO_TLB_SEGSIZE) != 
IO_TLB_SEGSIZE -1) && io_tlb_list[i]; i--)
io_tlb_list[i] = ++count;
+
+   io_tlb_used -= nslots;
}
spin_unlock_irqrestore(&io_tlb_lock, flags);
 }
@@ -662,3 +673,36 @@ swiotlb_dma_supported(struct device *hwdev, u64 mask)
 {
return __phys_to_dma(hwdev, io_tlb_end - 1) <= mask;
 }
+
+#ifdef CONFIG_DEBUG_FS
+
+static int __init swiotlb_create_debugfs(void)
+{
+   static struct dentry *d_swiotlb_usage;
+   struct dentry *ent;
+
+   d_swiotlb_usage = debugfs_create_dir("swiotlb", NULL);
+
+   if (!d_swiotlb_usage)
+   return -ENOMEM;
+
+   ent = debugfs_create_ulong("io_tlb_nslabs", 0400,
+  d_swiotlb_usage, &io_tlb_nslabs);
+   if (!ent)
+   goto fail;
+
+   ent = debugfs_create_ulong("io_tlb_used", 0400,
+  d_swiotlb_usage, &io_tlb_used);
+   if (!ent)
+   goto fail;
+
+   return 0;
+
+fail:
+   debugfs_remove_recursive(d_swiotlb_usage);
+   return -ENOMEM;
+}
+
+late_initcall(swiotlb_create_debugfs);
+
+#endif
-- 
2.7.4



[PATCH v3 3/3] swiotlb: checking whether swiotlb buffer is full with io_tlb_used

2019-01-17 Thread Dongli Zhang
This patch uses io_tlb_used to help check whether swiotlb buffer is full.
io_tlb_used is no longer used for only debugfs. It is also used to help
optimize swiotlb_tbl_map_single().

Suggested-by: Joe Jin 
Signed-off-by: Dongli Zhang 
---
Changed since v2:
  * move #ifdef folding to previous patch (suggested by Konrad Rzeszutek Wilk)

 kernel/dma/swiotlb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index bedc9f9..a01b83e 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -483,6 +483,10 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
 * request and allocate a buffer from that IO TLB pool.
 */
spin_lock_irqsave(&io_tlb_lock, flags);
+
+   if (unlikely(nslots > io_tlb_nslabs - io_tlb_used))
+   goto not_found;
+
index = ALIGN(io_tlb_index, stride);
if (index >= io_tlb_nslabs)
index = 0;
-- 
2.7.4



Re: [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor

2019-01-17 Thread Sibi Sankar

On 2018-05-29 09:50, Bjorn Andersson wrote:

On Thu 24 May 12:21 PDT 2018, Ramon Fried wrote:


Sometimes that rmtfs userspace module is not brought
up fast enough and the modem crashes.
disabling automated boot in the driver and triggering
the boot from user-space sovles the problem.

Signed-off-by: Ramon Fried 


Thanks for your patch Ramon. While this nudges the behavior to make
things work slightly better I think we need to describe the explicit
dependency between the mss firmware and the existence of rmtfs.

As our remoteprocs are essentially always-on I would prefer that they
start "automatically" and not through use of the sysfs interface.

But we're at the point where this is a real problem on 410, 820 and 
845,

so we have to come up with some way to tie these pieces together. If
your patch suits that solution I will happily take it.

Regards,
Bjorn


After experimenting with in kernel solutions for
three revisions and observing problems on graceful
shutdown usecase, switching to controlling the
remoteproc mss through rmtfs seems to solve all
the known issues.

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

we should probably get this merged in, now that
we are planning to start/stop mss through
rmtfs.


Acked-by: Sibi Sankar 




---
 drivers/remoteproc/qcom_q6v5_pil.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c

index cbbafdcaaecb..719ee96445b3 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -1133,6 +1133,8 @@ static int q6v5_probe(struct platform_device 
*pdev)

return -ENOMEM;
}

+   rproc->auto_boot = false;
+
qproc = (struct q6v5 *)rproc->priv;
qproc->dev = &pdev->dev;
qproc->rproc = rproc;
--
2.17.0



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


Re: [PATCH v4 1/4] can: m_can: Create a m_can platform framework

2019-01-17 Thread Wolfgang Grandegger
Hello Dan,

Am 17.01.19 um 21:08 schrieb Dan Murphy:
> Wolfgang
> 
> On 1/17/19 2:05 PM, Dan Murphy wrote:
>> Create a m_can platform framework that peripherial
>> devices can register to and use common code and register sets.
>> The peripherial devices may provide read/write and configuration
>> support of the IP.
>>
>> Signed-off-by: Dan Murphy 
>> ---
>>  drivers/net/can/m_can/m_can.c  |   6 +
>>  drivers/net/can/m_can/m_can_platform.c | 209 +
>>  drivers/net/can/m_can/m_can_platform.h | 163 +++
>>  3 files changed, 378 insertions(+)
>>  create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>  create mode 100644 drivers/net/can/m_can/m_can_platform.h
>>

... snip ...

> This patch set is working for the TCAN and at least boots on io-mapped 
> devices.
> We have a couple of customers who are looking at using this implementation 
> and we would like to
> start moving this patch set along in the review.
> 
> I did not put a change log in here as there have been no comments for the 
> last 3 patch sets I sent.
> 
> This v4 squashes a few bugs I found during testing across all the files.

OK, after a very busy week I will try to find time for the review...
finally.

Thanks,

Wolfgang.


Re: [patch 3/9] crypto: morus - Cleanup license mess

2019-01-17 Thread Greg Kroah-Hartman
On Thu, Jan 17, 2019 at 10:26:07PM -0200, Fabio Estevam wrote:
> On Thu, Jan 17, 2019 at 9:17 PM Thomas Gleixner  wrote:
> 
> > --- a/include/crypto/morus1280_glue.h
> > +++ b/include/crypto/morus1280_glue.h
> > @@ -1,15 +1,10 @@
> > -/* SPDX-License-Identifier: GPL-2.0 */
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> 
> Shouldn't this be: /* SPDX-License-Identifier: GPL-2.0+ */ ?
> 
> At least this is the form documented in 
> Documentation/process/license-rules.rst:
> 
> " License identifiers for licenses like [L]GPL with the 'or later' option
>are constructed by using a "+" for indicating the 'or later' option.::
> 
>   // SPDX-License-Identifier: GPL-2.0+"

Either works, please see LICENSES/preferred/GPL-2.0

Personally, I think we should stick with the "+" version as that is the
much more prevalent use in the kernel at the moment, but it's Thomas's
call, not mine.

thanks,

greg k-h


[PATCH] KVM: x86: Sync the pending Posted-Interrupts

2019-01-17 Thread Luwei Kang
Some Posted-Interrupts from passthrough devices may be lost or
overwritten when the vCPU is in runnable state.

The SN (Suppress Notification) of PID (Posted Interrupt Descriptor) will
be set when the vCPU is preempted (vCPU in KVM_MP_STATE_RUNNABLE state
but not running on physical CPU). If a posted interrupt coming at this
time, the irq remmaping facility will set the bit of PIR (Posted
Interrupt Requests) but ON (Outstanding Notification).
So this interrupt can't be sync to APIC virtualization register and
will not be handled by Guest because ON is zero.

Signed-off-by: Luwei Kang 
---
 arch/x86/kvm/vmx/vmx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index f6915f1..820a03b 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6048,7 +6048,7 @@ static int vmx_sync_pir_to_irr(struct kvm_vcpu *vcpu)
bool max_irr_updated;
 
WARN_ON(!vcpu->arch.apicv_active);
-   if (pi_test_on(&vmx->pi_desc)) {
+   if (!bitmap_empty((unsigned long *)vmx->pi_desc.pir, NR_VECTORS)) {
pi_clear_on(&vmx->pi_desc);
/*
 * IOMMU can write to PIR.ON, so the barrier matters even on UP.
-- 
1.8.3.1



Re: [PATCH] csky/kernel/entry: Remove duplicate heade

2019-01-17 Thread Guo Ren
Thx Brajeswar,

Tested-by: Guo Ren 
Acked-by: Guo Ren 

On Thu, Jan 17, 2019 at 08:00:04PM +0530, Brajeswar Ghosh wrote:
> Remove duplicate headers which are included more than once
> 
> Signed-off-by: Brajeswar Ghosh 
> ---
>  arch/csky/kernel/entry.S | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/csky/kernel/entry.S b/arch/csky/kernel/entry.S
> index 79f92b8606c8..f2081ddcc398 100644
> --- a/arch/csky/kernel/entry.S
> +++ b/arch/csky/kernel/entry.S
> @@ -9,7 +9,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> -- 
> 2.17.1
> 


[PATCH v11] mm/page_alloc.c: memory_hotplug: free pages as higher order

2019-01-17 Thread Arun KS
When freeing pages are done with higher order, time spent on coalescing
pages by buddy allocator can be reduced.  With section size of 256MB, hot
add latency of a single section shows improvement from 50-60 ms to less
than 1 ms, hence improving the hot add latency by 60 times.  Modify
external providers of online callback to align with the change.

Signed-off-by: Arun KS 
Acked-by: Michal Hocko 
Reviewed-by: Oscar Salvador 
Reviewed-by: Alexander Duyck 
---
Changes sinc v10:
- Fix check page belong to HAS in hv_ballon.c.
- Removed unnecessary brackets.

Changes since v9:
- Fix condition check in hv_ballon driver.

Changes since v8:
- Remove return type change for online_page_callback.
- Use consistent names for external online_page providers.
- Fix onlined_pages accounting.

Changes since v7:
- Rebased to 5.0-rc1.
- Fixed onlined_pages accounting.
- Added comment for return value of online_page_callback.
- Renamed xen_bring_pgs_online to xen_online_pages.

Changes since v6:
- Rebased to 4.20
- Changelog updated.
- No improvement seen on arm64, hence removed removal of prefetch.

Changes since v5:
- Rebased to 4.20-rc1.
- Changelog updated.

Changes since v4:
- As suggested by Michal Hocko,
- Simplify logic in online_pages_block() by using get_order().
- Seperate out removal of prefetch from __free_pages_core().

Changes since v3:
- Renamed _free_pages_boot_core -> __free_pages_core.
- Removed prefetch from __free_pages_core.
- Removed xen_online_page().

Changes since v2:
- Reuse code from __free_pages_boot_core().

Changes since v1:
- Removed prefetch().

Changes since RFC:
- Rebase.
- As suggested by Michal Hocko remove pages_per_block.
- Modifed external providers of online_page_callback.

v10: https://lore.kernel.org/patchwork/patch/1032266/
v9: https://lore.kernel.org/patchwork/patch/1030806/
v8: https://lore.kernel.org/patchwork/patch/1030332/
v7: https://lore.kernel.org/patchwork/patch/1028908/
v6: https://lore.kernel.org/patchwork/patch/1007253/
v5: https://lore.kernel.org/patchwork/patch/995739/
v4: https://lore.kernel.org/patchwork/patch/995111/
v3: https://lore.kernel.org/patchwork/patch/992348/
v2: https://lore.kernel.org/patchwork/patch/991363/
v1: https://lore.kernel.org/patchwork/patch/989445/
RFC: https://lore.kernel.org/patchwork/patch/984754/
---

 drivers/hv/hv_balloon.c|  7 ---
 drivers/xen/balloon.c  | 15 ++-
 include/linux/memory_hotplug.h |  2 +-
 mm/internal.h  |  1 +
 mm/memory_hotplug.c| 37 +
 mm/page_alloc.c|  8 
 6 files changed, 45 insertions(+), 25 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 5301fef..c2cb6df 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -771,7 +771,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned 
long size,
}
 }
 
-static void hv_online_page(struct page *pg)
+static void hv_online_page(struct page *pg, unsigned int order)
 {
struct hv_hotadd_state *has;
unsigned long flags;
@@ -780,10 +780,11 @@ static void hv_online_page(struct page *pg)
spin_lock_irqsave(&dm_device.ha_lock, flags);
list_for_each_entry(has, &dm_device.ha_region_list, list) {
/* The page belongs to a different HAS. */
-   if ((pfn < has->start_pfn) || (pfn >= has->end_pfn))
+   if ((pfn < has->start_pfn) ||
+   (pfn + (1UL << order) > has->end_pfn))
continue;
 
-   hv_page_online_one(has, pg);
+   hv_bring_pgs_online(has, pfn, 1UL << order);
break;
}
spin_unlock_irqrestore(&dm_device.ha_lock, flags);
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index ceb5048..d107447 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -369,14 +369,19 @@ static enum bp_state reserve_additional_memory(void)
return BP_ECANCELED;
 }
 
-static void xen_online_page(struct page *page)
+static void xen_online_page(struct page *page, unsigned int order)
 {
-   __online_page_set_limits(page);
+   unsigned long i, size = (1 << order);
+   unsigned long start_pfn = page_to_pfn(page);
+   struct page *p;
 
+   pr_debug("Online %lu pages starting at pfn 0x%lx\n", size, start_pfn);
mutex_lock(&balloon_mutex);
-
-   __balloon_append(page);
-
+   for (i = 0; i < size; i++) {
+   p = pfn_to_page(start_pfn + i);
+   __online_page_set_limits(p);
+   __balloon_append(p);
+   }
mutex_unlock(&balloon_mutex);
 }
 
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 07da5c6..e368730 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -87,7 +87,7 @@ extern int test_pages_in_a_zone(unsigned long start_pfn, 
unsigned long end_pfn,
unsigned long *valid_start, unsigned long 

Re: [PATCH] irqchip/irq-csky-mpintc: Add triger type and priority setting

2019-01-17 Thread Guo Ren
Thx Marc,

On Thu, Jan 17, 2019 at 05:17:45PM +, Marc Zyngier wrote:
> Hi Guo,
> 
> On 15/01/2019 16:36, guo...@kernel.org wrote:
> > From: Guo Ren 
> > 
> > Support 4 triger types:
> >  - IRQ_TYPE_LEVEL_HIGH
> >  - IRQ_TYPE_LEVEL_LOW
> >  - IRQ_TYPE_EDGE_RISING
> >  - IRQ_TYPE_EDGE_FALLING
> > 
> > Support 0-255 priority setting for each irq.
> > 
> > Signed-off-by: Guo Ren 
> > ---
> >  .../bindings/interrupt-controller/csky,mpintc.txt  | 24 ++-
> >  drivers/irqchip/irq-csky-mpintc.c  | 78 
> > +-
> >  2 files changed, 99 insertions(+), 3 deletions(-)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt 
> > b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
> > index ab921f1..364b789 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
> > @@ -11,6 +11,14 @@ Interrupt number definition:
> >   16-31  : private  irq, and we use 16 as the co-processor timer.
> >   31-1024: common irq for soc ip.
> >  
> > +Interrupt triger mode:
> > +  IRQ_TYPE_LEVEL_HIGH (default)
> > +  IRQ_TYPE_LEVEL_LOW
> > +  IRQ_TYPE_EDGE_RISING
> > +  IRQ_TYPE_EDGE_FALLING
> > +
> > +Interrupt priority range: 0-255
> > +
> >  =
> >  intc node bindings definition
> >  =
> > @@ -26,7 +34,7 @@ intc node bindings definition
> > - #interrupt-cells
> > Usage: required
> > Value type: 
> > -   Definition: must be <1>
> > +   Definition: could be <1> or <2>
> > - interrupt-controller:
> > Usage: required
> >  
> > @@ -35,6 +43,18 @@ Examples:
> >  
> > intc: interrupt-controller {
> > compatible = "csky,mpintc";
> > -   #interrupt-cells = <1>;
> > +   #interrupt-cells = <2>;
> > interrupt-controller;
> > };
> > +
> > +   0: device-example {
> > +   ...
> > +   interrupts = <33 IRQ_TYPE_EDGE_RISING>;
> > +   interrupt-parent = <&intc>;
> > +   };
> > +
> > +   1: device-example {
> > +   ...
> > +   interrupts = <34 ((priority << 4) | IRQ_TYPE_EDGE_RISING)>;
> > +   interrupt-parent = <&intc>;
> > +   };
> > diff --git a/drivers/irqchip/irq-csky-mpintc.c 
> > b/drivers/irqchip/irq-csky-mpintc.c
> > index c67c961..9edc6d3 100644
> > --- a/drivers/irqchip/irq-csky-mpintc.c
> > +++ b/drivers/irqchip/irq-csky-mpintc.c
> > @@ -29,9 +29,12 @@ static void __iomem *INTCL_base;
> >  
> >  #define INTCG_ICTLR0x0
> >  #define INTCG_CICFGR   0x100
> > +#define INTCG_CIPRTR   0x200
> >  #define INTCG_CIDSTR   0x1000
> >  
> >  #define INTCL_PICTLR   0x0
> > +#define INTCL_CFGR 0x14
> > +#define INTCL_PRTR 0x20
> >  #define INTCL_SIGR 0x60
> >  #define INTCL_HPPIR0x68
> >  #define INTCL_RDYIR0x6c
> > @@ -73,6 +76,78 @@ static void csky_mpintc_eoi(struct irq_data *d)
> > writel_relaxed(d->hwirq, reg_base + INTCL_CACR);
> >  }
> >  
> > +static int csky_mpintc_set_type(struct irq_data *d, unsigned int type)
> > +{
> > +   unsigned int priority, triger;
> 
> nit: s/triger/trigger/ everywhere.
Ok

> 
> > +   unsigned int offset, bit_offset;
> > +   void __iomem *reg_base;
> > +
> > +   /*
> > +* type Bit field: | 32 - 12  |  11 - 4  |   3 - 0|
> > +*   reserved   priority   triger type
> > +*/
> > +   triger   = type & IRQ_TYPE_SENSE_MASK;
> > +   priority = (type >> 4) & 0xff;
> 
> Definitely not. The Linux API to set the trigger does not carry any
> priority information, nor should it. Priorities should be set
> statically, and no driver should ever be able to change it.
Currently priority in dts is:

interrupts = <34 ((priority << 4) | IRQ_TYPE_EDGE_RISING)>;

change it to:

interrupts = <34 IRQ_TYPE_EDGE_RISING priority>;

Implement csky own csky_irq_domain_xlate_cells() ...

int csky_irq_domain_xlate_cells(struct irq_domain *d, struct device_node *ctrlr,
const u32 *intspec, unsigned int intsize,
irq_hw_number_t *out_hwirq, unsigned int *out_type)
{
if (WARN_ON(intsize < 1))
return -EINVAL;
*out_hwirq = intspec[0];
if (intsize > 1)
*out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
else
*out_type = IRQ_TYPE_NONE;

if (intsize > 2)
setup_priority(d->hwirq, intspec[2]);

return 0;
}
Hmm?

> 
> > +
> > +   switch (triger) {
> > +   case IRQ_TYPE_LEVEL_HIGH:
> > +   triger = 0;
> > +   break;
> > +   case IRQ_TYPE_LEVEL_LOW:
> > +   triger = 1;
> > +   break;
> > +   case IRQ_TYPE_EDGE_RISING:
> > +   triger = 2;
> > +   break;
> > +   case IRQ_TYPE_EDGE_FALLING:
> > +   triger = 3;
> 
> Can you define some macros that represent th

Re: [PATCH] mtd: rawnand: denali: get ->setup_data_interface() working again

2019-01-17 Thread Masahiro Yamada
On Fri, Jan 18, 2019 at 3:19 PM Boris Brezillon  wrote:
>
> On Fri, 18 Jan 2019 14:30:38 +0900
> Masahiro Yamada  wrote:
>
> > Commit 7a08dbaedd36 ("mtd: rawnand: Move ->setup_data_interface() to
> > nand_controller_ops") missed to invert the if-conditonal for denali.
> > Since then, the Denali NAND driver cannnot invoke setup_data_interface.
> >
> > Fixes: 7a08dbaedd36 ("mtd: rawnand: Move ->setup_data_interface() to 
> > nand_controller_ops")
> > Cc: linux-stable  # v4.20
>
> Commit 7a08dbaedd36 was merged in 5.0, I'll drop Cc stable when
> applying.


Ah, right. Thanks.




-- 
Best Regards
Masahiro Yamada


Re: [PATCH] mtd: rawnand: denali: get ->setup_data_interface() working again

2019-01-17 Thread Boris Brezillon
On Fri, 18 Jan 2019 14:30:38 +0900
Masahiro Yamada  wrote:

> Commit 7a08dbaedd36 ("mtd: rawnand: Move ->setup_data_interface() to
> nand_controller_ops") missed to invert the if-conditonal for denali.
> Since then, the Denali NAND driver cannnot invoke setup_data_interface.
> 
> Fixes: 7a08dbaedd36 ("mtd: rawnand: Move ->setup_data_interface() to 
> nand_controller_ops")
> Cc: linux-stable  # v4.20

Commit 7a08dbaedd36 was merged in 5.0, I'll drop Cc stable when
applying.

> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/mtd/nand/raw/denali.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
> index eebac35..6e8edc9 100644
> --- a/drivers/mtd/nand/raw/denali.c
> +++ b/drivers/mtd/nand/raw/denali.c
> @@ -1322,7 +1322,7 @@ int denali_init(struct denali_nand_info *denali)
>   }
>  
>   /* clk rate info is needed for setup_data_interface */
> - if (denali->clk_rate && denali->clk_x_rate)
> + if (!denali->clk_rate || !denali->clk_x_rate)
>   chip->options |= NAND_KEEP_TIMINGS;
>  
>   chip->legacy.dummy_controller.ops = &denali_controller_ops;



Re: [PATCH v3 4/4] usb: musb: Add support for MediaTek musb controller

2019-01-17 Thread Min Guo
On Thu, 2019-01-17 at 06:33 -0800, Tony Lindgren wrote:
> Hi,
> 
> * min@mediatek.com  [190117 07:16]:
> > There are some quirk of MediaTek musb controller, such as:
> >  -W1C interrupt status registers
> >  -Private data toggle registers
> >  -No dedicated DMA interrupt line
> 
> Can you please separate the musb generic changes listed above
> into separate individual patches in preparation for adding
> support for new hardware?
> 
> Otherwise we'll have hard time finding out with git bisect what
> exactly breaks things if we run into trouble.

Thanks for your suggestion.
I prepared to divide these changes into separate patches. Later, Mr.Bin
suggested not to do this.

The detailed information can be referred to:
https://patchwork.kernel.org/patch/10743561/
https://patchwork.kernel.org/patch/10763737/
https://patchwork.kernel.org/patch/107463741/

> Regards,
> 
> Tony




Re: [PATCH net-next] net/mlx4: remove unneeded semicolon

2019-01-17 Thread David Miller
From: YueHaibing 
Date: Thu, 17 Jan 2019 21:03:56 +0800

> Remove unneeded semicolon.
> 
> Signed-off-by: YueHaibing 

Applied.


Re: [PATCH net-next] net: ethernet: ti: cpsw-phy-sel: remove unneeded semicolon

2019-01-17 Thread David Miller
From: YueHaibing 
Date: Thu, 17 Jan 2019 20:59:19 +0800

> Remove unneeded semicolon.
> 
> Signed-off-by: YueHaibing 

Applied.


Re: [PATCH net-next] tipc: remove unneeded semicolon in trace.c

2019-01-17 Thread David Miller
From: YueHaibing 
Date: Thu, 17 Jan 2019 20:57:08 +0800

> Remove unneeded semicolon
> 
> Signed-off-by: YueHaibing 

Applied.


Re: [PATCH net] net: phy: add missing phy driver features

2019-01-17 Thread David Miller
From: Camelia Groza 
Date: Thu, 17 Jan 2019 14:33:33 +0200

> The phy drivers for CS4340 and TN2020 are missing their
> features attributes. Add them.
> 
> Fixes: 719655a14971 ("net: phy: Replace phy driver features u32 with 
> link_mode bitmap")
> Reported-by: Scott Wood 
> Signed-off-by: Camelia Groza 

Applied and queued up for -stable.


Re: [PATCH] dpaa_eth: NETIF_F_LLTX requires to do our own update of trans_start

2019-01-17 Thread David Miller
From: Madalin Bucur 
Date: Thu, 17 Jan 2019 11:42:27 +0200

> As txq_trans_update() only updates trans_start when the lock is held,
> trans_start does not get updated if NETIF_F_LLTX is declared.
> 
> Signed-off-by: Madalin Bucur 

Applied.


[PATCH V3 2/5] crypto: ccm - use template array registering API to simplify the code

2019-01-17 Thread Xiongfeng Wang
From: Xiongfeng Wang 

Use crypto template array registering API to simplify the code.

Signed-off-by: Xiongfeng Wang 
Reviewed-by: Eric Biggers 
---
 crypto/ccm.c | 78 ++--
 1 file changed, 23 insertions(+), 55 deletions(-)

diff --git a/crypto/ccm.c b/crypto/ccm.c
index b242fd0..50df8f0 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -589,12 +589,6 @@ static int crypto_ccm_create(struct crypto_template *tmpl, 
struct rtattr **tb)
mac_name);
 }
 
-static struct crypto_template crypto_ccm_tmpl = {
-   .name = "ccm",
-   .create = crypto_ccm_create,
-   .module = THIS_MODULE,
-};
-
 static int crypto_ccm_base_create(struct crypto_template *tmpl,
  struct rtattr **tb)
 {
@@ -618,12 +612,6 @@ static int crypto_ccm_base_create(struct crypto_template 
*tmpl,
cipher_name);
 }
 
-static struct crypto_template crypto_ccm_base_tmpl = {
-   .name = "ccm_base",
-   .create = crypto_ccm_base_create,
-   .module = THIS_MODULE,
-};
-
 static int crypto_rfc4309_setkey(struct crypto_aead *parent, const u8 *key,
 unsigned int keylen)
 {
@@ -854,12 +842,6 @@ static int crypto_rfc4309_create(struct crypto_template 
*tmpl,
goto out;
 }
 
-static struct crypto_template crypto_rfc4309_tmpl = {
-   .name = "rfc4309",
-   .create = crypto_rfc4309_create,
-   .module = THIS_MODULE,
-};
-
 static int crypto_cbcmac_digest_setkey(struct crypto_shash *parent,
 const u8 *inkey, unsigned int keylen)
 {
@@ -999,51 +981,37 @@ static int cbcmac_create(struct crypto_template *tmpl, 
struct rtattr **tb)
return err;
 }
 
-static struct crypto_template crypto_cbcmac_tmpl = {
-   .name = "cbcmac",
-   .create = cbcmac_create,
-   .free = shash_free_instance,
-   .module = THIS_MODULE,
+static struct crypto_template crypto_ccm_tmpls[] = {
+   {
+   .name = "cbcmac",
+   .create = cbcmac_create,
+   .free = shash_free_instance,
+   .module = THIS_MODULE,
+   }, {
+   .name = "ccm_base",
+   .create = crypto_ccm_base_create,
+   .module = THIS_MODULE,
+   }, {
+   .name = "ccm",
+   .create = crypto_ccm_create,
+   .module = THIS_MODULE,
+   }, {
+   .name = "rfc4309",
+   .create = crypto_rfc4309_create,
+   .module = THIS_MODULE,
+   },
 };
 
 static int __init crypto_ccm_module_init(void)
 {
-   int err;
-
-   err = crypto_register_template(&crypto_cbcmac_tmpl);
-   if (err)
-   goto out;
-
-   err = crypto_register_template(&crypto_ccm_base_tmpl);
-   if (err)
-   goto out_undo_cbcmac;
-
-   err = crypto_register_template(&crypto_ccm_tmpl);
-   if (err)
-   goto out_undo_base;
-
-   err = crypto_register_template(&crypto_rfc4309_tmpl);
-   if (err)
-   goto out_undo_ccm;
-
-out:
-   return err;
-
-out_undo_ccm:
-   crypto_unregister_template(&crypto_ccm_tmpl);
-out_undo_base:
-   crypto_unregister_template(&crypto_ccm_base_tmpl);
-out_undo_cbcmac:
-   crypto_register_template(&crypto_cbcmac_tmpl);
-   goto out;
+   return crypto_register_templates(crypto_ccm_tmpls,
+ARRAY_SIZE(crypto_ccm_tmpls));
 }
 
 static void __exit crypto_ccm_module_exit(void)
 {
-   crypto_unregister_template(&crypto_rfc4309_tmpl);
-   crypto_unregister_template(&crypto_ccm_tmpl);
-   crypto_unregister_template(&crypto_ccm_base_tmpl);
-   crypto_unregister_template(&crypto_cbcmac_tmpl);
+   crypto_unregister_templates(crypto_ccm_tmpls,
+   ARRAY_SIZE(crypto_ccm_tmpls));
 }
 
 module_init(crypto_ccm_module_init);
-- 
1.7.12.4



[PATCH V3 1/5] crypto: api - add a helper to (un)register a array of templates

2019-01-17 Thread Xiongfeng Wang
From: Xiongfeng Wang 

This patch add a helper to (un)register a array of templates. The
following patches will use this helper to simplify the code.

Signed-off-by: Xiongfeng Wang 
Reviewed-by: Eric Biggers 
---
 crypto/algapi.c | 27 +++
 include/crypto/algapi.h |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/crypto/algapi.c b/crypto/algapi.c
index 713baab..4c9c86b 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -494,6 +494,24 @@ int crypto_register_template(struct crypto_template *tmpl)
 }
 EXPORT_SYMBOL_GPL(crypto_register_template);
 
+int crypto_register_templates(struct crypto_template *tmpls, int count)
+{
+   int i, err;
+
+   for (i = 0; i < count; i++) {
+   err = crypto_register_template(&tmpls[i]);
+   if (err)
+   goto out;
+   }
+   return 0;
+
+out:
+   for (--i; i >= 0; --i)
+   crypto_unregister_template(&tmpls[i]);
+   return err;
+}
+EXPORT_SYMBOL_GPL(crypto_register_templates);
+
 void crypto_unregister_template(struct crypto_template *tmpl)
 {
struct crypto_instance *inst;
@@ -523,6 +541,15 @@ void crypto_unregister_template(struct crypto_template 
*tmpl)
 }
 EXPORT_SYMBOL_GPL(crypto_unregister_template);
 
+void crypto_unregister_templates(struct crypto_template *tmpls, int count)
+{
+   int i;
+
+   for (i = count - 1; i >= 0; --i)
+   crypto_unregister_template(&tmpls[i]);
+}
+EXPORT_SYMBOL_GPL(crypto_unregister_templates);
+
 static struct crypto_template *__crypto_lookup_template(const char *name)
 {
struct crypto_template *q, *tmpl = NULL;
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index 093869f..4be38cd 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -143,7 +143,9 @@ struct ablkcipher_walk {
 void crypto_mod_put(struct crypto_alg *alg);
 
 int crypto_register_template(struct crypto_template *tmpl);
+int crypto_register_templates(struct crypto_template *tmpls, int count);
 void crypto_unregister_template(struct crypto_template *tmpl);
+void crypto_unregister_templates(struct crypto_template *tmpls, int count);
 struct crypto_template *crypto_lookup_template(const char *name);
 
 int crypto_register_instance(struct crypto_template *tmpl,
-- 
1.7.12.4



[PATCH V3 3/5] crypto: gcm - use template array registering API to simplify the code

2019-01-17 Thread Xiongfeng Wang
From: Xiongfeng Wang 

Use crypto template array registering API to simplify the code.

Signed-off-by: Xiongfeng Wang 
Reviewed-by: Eric Biggers 
---
 crypto/gcm.c | 73 +++-
 1 file changed, 23 insertions(+), 50 deletions(-)

diff --git a/crypto/gcm.c b/crypto/gcm.c
index e438492..31eb694 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -727,12 +727,6 @@ static int crypto_gcm_create(struct crypto_template *tmpl, 
struct rtattr **tb)
ctr_name, "ghash");
 }
 
-static struct crypto_template crypto_gcm_tmpl = {
-   .name = "gcm",
-   .create = crypto_gcm_create,
-   .module = THIS_MODULE,
-};
-
 static int crypto_gcm_base_create(struct crypto_template *tmpl,
  struct rtattr **tb)
 {
@@ -756,12 +750,6 @@ static int crypto_gcm_base_create(struct crypto_template 
*tmpl,
ctr_name, ghash_name);
 }
 
-static struct crypto_template crypto_gcm_base_tmpl = {
-   .name = "gcm_base",
-   .create = crypto_gcm_base_create,
-   .module = THIS_MODULE,
-};
-
 static int crypto_rfc4106_setkey(struct crypto_aead *parent, const u8 *key,
 unsigned int keylen)
 {
@@ -989,12 +977,6 @@ static int crypto_rfc4106_create(struct crypto_template 
*tmpl,
goto out;
 }
 
-static struct crypto_template crypto_rfc4106_tmpl = {
-   .name = "rfc4106",
-   .create = crypto_rfc4106_create,
-   .module = THIS_MODULE,
-};
-
 static int crypto_rfc4543_setkey(struct crypto_aead *parent, const u8 *key,
 unsigned int keylen)
 {
@@ -1231,10 +1213,24 @@ static int crypto_rfc4543_create(struct crypto_template 
*tmpl,
goto out;
 }
 
-static struct crypto_template crypto_rfc4543_tmpl = {
-   .name = "rfc4543",
-   .create = crypto_rfc4543_create,
-   .module = THIS_MODULE,
+static struct crypto_template crypto_gcm_tmpls[] = {
+   {
+   .name = "gcm_base",
+   .create = crypto_gcm_base_create,
+   .module = THIS_MODULE,
+   }, {
+   .name = "gcm",
+   .create = crypto_gcm_create,
+   .module = THIS_MODULE,
+   }, {
+   .name = "rfc4106",
+   .create = crypto_rfc4106_create,
+   .module = THIS_MODULE,
+   }, {
+   .name = "rfc4543",
+   .create = crypto_rfc4543_create,
+   .module = THIS_MODULE,
+   },
 };
 
 static int __init crypto_gcm_module_init(void)
@@ -1247,42 +1243,19 @@ static int __init crypto_gcm_module_init(void)
 
sg_init_one(&gcm_zeroes->sg, gcm_zeroes->buf, sizeof(gcm_zeroes->buf));
 
-   err = crypto_register_template(&crypto_gcm_base_tmpl);
-   if (err)
-   goto out;
-
-   err = crypto_register_template(&crypto_gcm_tmpl);
+   err = crypto_register_templates(crypto_gcm_tmpls,
+   ARRAY_SIZE(crypto_gcm_tmpls));
if (err)
-   goto out_undo_base;
+   kfree(gcm_zeroes);
 
-   err = crypto_register_template(&crypto_rfc4106_tmpl);
-   if (err)
-   goto out_undo_gcm;
-
-   err = crypto_register_template(&crypto_rfc4543_tmpl);
-   if (err)
-   goto out_undo_rfc4106;
-
-   return 0;
-
-out_undo_rfc4106:
-   crypto_unregister_template(&crypto_rfc4106_tmpl);
-out_undo_gcm:
-   crypto_unregister_template(&crypto_gcm_tmpl);
-out_undo_base:
-   crypto_unregister_template(&crypto_gcm_base_tmpl);
-out:
-   kfree(gcm_zeroes);
return err;
 }
 
 static void __exit crypto_gcm_module_exit(void)
 {
kfree(gcm_zeroes);
-   crypto_unregister_template(&crypto_rfc4543_tmpl);
-   crypto_unregister_template(&crypto_rfc4106_tmpl);
-   crypto_unregister_template(&crypto_gcm_tmpl);
-   crypto_unregister_template(&crypto_gcm_base_tmpl);
+   crypto_unregister_templates(crypto_gcm_tmpls,
+   ARRAY_SIZE(crypto_gcm_tmpls));
 }
 
 module_init(crypto_gcm_module_init);
-- 
1.7.12.4



[PATCH V3 4/5] crypto: ctr - use template array registering API to simplify the code

2019-01-17 Thread Xiongfeng Wang
From: Xiongfeng Wang 

Use crypto template array registering API to simplify the code.

Signed-off-by: Xiongfeng Wang 
Reviewed-by: Eric Biggers 
---
 crypto/ctr.c | 42 ++
 1 file changed, 14 insertions(+), 28 deletions(-)

diff --git a/crypto/ctr.c b/crypto/ctr.c
index 4c743a9..ec8f8b6 100644
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@ -171,12 +171,6 @@ static int crypto_ctr_create(struct crypto_template *tmpl, 
struct rtattr **tb)
return err;
 }
 
-static struct crypto_template crypto_ctr_tmpl = {
-   .name = "ctr",
-   .create = crypto_ctr_create,
-   .module = THIS_MODULE,
-};
-
 static int crypto_rfc3686_setkey(struct crypto_skcipher *parent,
 const u8 *key, unsigned int keylen)
 {
@@ -366,36 +360,28 @@ static int crypto_rfc3686_create(struct crypto_template 
*tmpl,
goto out;
 }
 
-static struct crypto_template crypto_rfc3686_tmpl = {
-   .name = "rfc3686",
-   .create = crypto_rfc3686_create,
-   .module = THIS_MODULE,
+static struct crypto_template crypto_ctr_tmpls[] = {
+   {
+   .name = "ctr",
+   .create = crypto_ctr_create,
+   .module = THIS_MODULE,
+   }, {
+   .name = "rfc3686",
+   .create = crypto_rfc3686_create,
+   .module = THIS_MODULE,
+   },
 };
 
 static int __init crypto_ctr_module_init(void)
 {
-   int err;
-
-   err = crypto_register_template(&crypto_ctr_tmpl);
-   if (err)
-   goto out;
-
-   err = crypto_register_template(&crypto_rfc3686_tmpl);
-   if (err)
-   goto out_drop_ctr;
-
-out:
-   return err;
-
-out_drop_ctr:
-   crypto_unregister_template(&crypto_ctr_tmpl);
-   goto out;
+   return crypto_register_templates(crypto_ctr_tmpls,
+ARRAY_SIZE(crypto_ctr_tmpls));
 }
 
 static void __exit crypto_ctr_module_exit(void)
 {
-   crypto_unregister_template(&crypto_rfc3686_tmpl);
-   crypto_unregister_template(&crypto_ctr_tmpl);
+   crypto_unregister_templates(crypto_ctr_tmpls,
+   ARRAY_SIZE(crypto_ctr_tmpls));
 }
 
 module_init(crypto_ctr_module_init);
-- 
1.7.12.4



[PATCH V3 5/5] crypto: chacha20poly1305 - use template array registering API to simplify the code

2019-01-17 Thread Xiongfeng Wang
From: Xiongfeng Wang 

Use crypto template array registering API to simplify the code.

Signed-off-by: Xiongfeng Wang 
Reviewed-by: Eric Biggers 
---
 crypto/chacha20poly1305.c | 37 ++---
 1 file changed, 14 insertions(+), 23 deletions(-)

diff --git a/crypto/chacha20poly1305.c b/crypto/chacha20poly1305.c
index fef1144..ed2e12e 100644
--- a/crypto/chacha20poly1305.c
+++ b/crypto/chacha20poly1305.c
@@ -701,37 +701,28 @@ static int rfc7539esp_create(struct crypto_template 
*tmpl, struct rtattr **tb)
return chachapoly_create(tmpl, tb, "rfc7539esp", 8);
 }
 
-static struct crypto_template rfc7539_tmpl = {
-   .name = "rfc7539",
-   .create = rfc7539_create,
-   .module = THIS_MODULE,
-};
-
-static struct crypto_template rfc7539esp_tmpl = {
-   .name = "rfc7539esp",
-   .create = rfc7539esp_create,
-   .module = THIS_MODULE,
+static struct crypto_template rfc7539_tmpls[] = {
+   {
+   .name = "rfc7539",
+   .create = rfc7539_create,
+   .module = THIS_MODULE,
+   }, {
+   .name = "rfc7539esp",
+   .create = rfc7539esp_create,
+   .module = THIS_MODULE,
+   },
 };
 
 static int __init chacha20poly1305_module_init(void)
 {
-   int err;
-
-   err = crypto_register_template(&rfc7539_tmpl);
-   if (err)
-   return err;
-
-   err = crypto_register_template(&rfc7539esp_tmpl);
-   if (err)
-   crypto_unregister_template(&rfc7539_tmpl);
-
-   return err;
+   return crypto_register_templates(rfc7539_tmpls,
+ARRAY_SIZE(rfc7539_tmpls));
 }
 
 static void __exit chacha20poly1305_module_exit(void)
 {
-   crypto_unregister_template(&rfc7539esp_tmpl);
-   crypto_unregister_template(&rfc7539_tmpl);
+   crypto_unregister_templates(rfc7539_tmpls,
+   ARRAY_SIZE(rfc7539_tmpls));
 }
 
 module_init(chacha20poly1305_module_init);
-- 
1.7.12.4



[PATCH V3 0/5] Crypto Cleanup

2019-01-17 Thread Xiongfeng Wang
The patchset introduce a helper to (un)register a array of crypto templates.
The following patches use this helper to simplify the code. This is also
a preparation for a coming patchset, which will register several crypto
templates.

Changelog:
v2 -> v3:
remove the extra blank line in the fourth patch
change author to Xiongfeng Wang 
v1 -> v2: 
rebased to cryptodev, fix some format issue

Xiongfeng Wang (5):
  crypto: api - add a helper to (un)register a array of templates
  crypto: ccm - use template array registering API to simplify the code
  crypto: gcm - use template array registering API to simplify the code
  crypto: ctr - use template array registering API to simplify the code
  crypto: chacha20poly1305 - use template array registering API to
simplify the code

 crypto/algapi.c   | 27 
 crypto/ccm.c  | 78 ++-
 crypto/chacha20poly1305.c | 37 +-
 crypto/ctr.c  | 42 +
 crypto/gcm.c  | 73 ++--
 include/crypto/algapi.h   |  2 ++
 6 files changed, 103 insertions(+), 156 deletions(-)

-- 
1.7.12.4



Re: [PATCH net-next] qed: remove duplicated include from qed_if.h

2019-01-17 Thread David Miller
From: YueHaibing 
Date: Thu, 17 Jan 2019 15:22:20 +0800

> Remove duplicated include.
> 
> Signed-off-by: YueHaibing 

Applied.


[PATCH v6 2/2] dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller bindings

2019-01-17 Thread Mason Yang
Document the bindings used by the Renesas R-Car Gen3 RPC-IF controller.

Signed-off-by: Mason Yang 
---
 .../devicetree/bindings/spi/spi-renesas-rpc.txt| 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt

diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt 
b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
new file mode 100644
index 000..9b5001e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
@@ -0,0 +1,37 @@
+Renesas R-Car Gen3 RPC-IF controller Device Tree Bindings
+--
+
+Required properties:
+- compatible: should be "renesas,rcar-gen3-rpc"
+- #address-cells: should be 1
+- #size-cells: should be 0
+- reg: should contain three register areas:
+   first for the base address of rpc-if registers,
+   second for the direct mapping read mode and
+   third for the write buffer area.
+- reg-names: should contain "regs", "dirmap" and "wbuf"
+- clock-names: should contain "rpc"
+- clocks: should contain 1 entries for the module's clock
+
+Example:
+
+   rpc: rpc@ee20 {
+   compatible = "renesas,rcar-gen3-rpc";
+   reg = <0 0xee20 0 0x7fff>, <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+   reg-names = "regs", "dirmap", ";
+   clocks = <&cpg CPG_MOD 917>;
+   power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+   resets = <&cpg 917>;
+   clock-names = "rpc";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <4000>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <1>;
+   };
+   };
-- 
1.9.1



[PATCH v6 0/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI driver

2019-01-17 Thread Mason Yang
Hi Mark,

v6 patch is accroding to Geert, Marek and Sergei's comments:
1) spi_controller for new code. 
2) "renesas,rcar-gen3-rpc" instead of "renesas,r8a77995-rpc".
3) patch external address read mode w/o u64 readq().
4) patch dts for write buffer & drop "renesas,rpc-mode".
5) coding style and so on.

v5 patch is accroding to Sergei's comments:
1) Read 6 bytes ID from Sergei's patch.
2) regmap_update_bits()
3) C++ style comment

v4 patch is according to Sergei's comments including:
1) Drop soc_device_match()
2) Drop unused RPC registers
3) Use ilog2() instead of fls()
4) Patch read 6 bytes ID w/ one command.
5) Coding style and so on.

v3 patch is according to Marek and Geert's comments including:
1) soc_device_mach() to set up RPC_PHYCNT_STRTIM.
2) get_unaligned()
3) rpc-mode for rpi-spi-flash or rpc-hyperflash.
4) coding style and so on.

v2 patch including:
1) remove RPC clock enable/dis-able control,
2) patch run time PM,
3) add RPC module software reset,
4) add regmap,
5) other coding style and so on.

thanks for your review.

best regards,
Mason

Mason Yang (2):
  spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver
  dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller
bindings

 .../devicetree/bindings/spi/spi-renesas-rpc.txt|  37 +
 drivers/spi/Kconfig|   6 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/spi-renesas-rpc.c  | 800 +
 4 files changed, 844 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
 create mode 100644 drivers/spi/spi-renesas-rpc.c

-- 
1.9.1



[PATCH v6 1/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver

2019-01-17 Thread Mason Yang
Add a driver for Renesas R-Car Gen3 RPC-IF SPI controller.

Signed-off-by: Mason Yang 
Signed-off-by: Sergei Shtylyov 
---
 drivers/spi/Kconfig   |   6 +
 drivers/spi/Makefile  |   1 +
 drivers/spi/spi-renesas-rpc.c | 800 ++
 3 files changed, 807 insertions(+)
 create mode 100644 drivers/spi/spi-renesas-rpc.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9f89cb1..6ad1782 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -544,6 +544,12 @@ config SPI_RSPI
help
  SPI driver for Renesas RSPI and QSPI blocks.
 
+config SPI_RENESAS_RPC
+   tristate "Renesas R-Car Gen3 RPC-IF controller"
+   depends on ARCH_RENESAS || COMPILE_TEST
+   help
+ SPI driver for Renesas R-Car Gen3 RPC-IF.
+
 config SPI_QCOM_QSPI
tristate "QTI QSPI controller"
depends on ARCH_QCOM
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index f296270..9150732 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_SPI_QUP) += spi-qup.o
 obj-$(CONFIG_SPI_ROCKCHIP) += spi-rockchip.o
 obj-$(CONFIG_SPI_RB4XX)+= spi-rb4xx.o
 obj-$(CONFIG_SPI_RSPI) += spi-rspi.o
+obj-$(CONFIG_SPI_RENESAS_RPC)  += spi-renesas-rpc.o
 obj-$(CONFIG_SPI_S3C24XX)  += spi-s3c24xx-hw.o
 spi-s3c24xx-hw-y   := spi-s3c24xx.o
 spi-s3c24xx-hw-$(CONFIG_SPI_S3C24XX_FIQ) += spi-s3c24xx-fiq.o
diff --git a/drivers/spi/spi-renesas-rpc.c b/drivers/spi/spi-renesas-rpc.c
new file mode 100644
index 000..692c760
--- /dev/null
+++ b/drivers/spi/spi-renesas-rpc.c
@@ -0,0 +1,800 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2018 ~ 2019 Renesas Solutions Corp.
+// Copyright (C) 2018 Macronix International Co., Ltd.
+//
+// R-Car Gen3 RPC-IF SPI/QSPI/Octa driver
+//
+// Authors:
+// Mason Yang 
+//
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define RPC_CMNCR  0x  // R/W
+#define RPC_CMNCR_MD   BIT(31)
+#define RPC_CMNCR_SFDE BIT(24) // undocumented bit but must be set
+#define RPC_CMNCR_MOIIO3(val)  (((val) & 0x3) << 22)
+#define RPC_CMNCR_MOIIO2(val)  (((val) & 0x3) << 20)
+#define RPC_CMNCR_MOIIO1(val)  (((val) & 0x3) << 18)
+#define RPC_CMNCR_MOIIO0(val)  (((val) & 0x3) << 16)
+#define RPC_CMNCR_MOIIO_HIZ(RPC_CMNCR_MOIIO0(3) | RPC_CMNCR_MOIIO1(3) | \
+RPC_CMNCR_MOIIO2(3) | RPC_CMNCR_MOIIO3(3))
+#define RPC_CMNCR_IO3FV(val)   (((val) & 0x3) << 14) // undocumented
+#define RPC_CMNCR_IO2FV(val)   (((val) & 0x3) << 12) // undocumented
+#define RPC_CMNCR_IO0FV(val)   (((val) & 0x3) << 8)
+#define RPC_CMNCR_IOFV_HIZ (RPC_CMNCR_IO0FV(3) | RPC_CMNCR_IO2FV(3) | \
+RPC_CMNCR_IO3FV(3))
+#define RPC_CMNCR_BSZ(val) (((val) & 0x3) << 0)
+
+#define RPC_SSLDR  0x0004  // R/W
+#define RPC_SSLDR_SPNDL(d) (((d) & 0x7) << 16)
+#define RPC_SSLDR_SLNDL(d) (((d) & 0x7) << 8)
+#define RPC_SSLDR_SCKDL(d) (((d) & 0x7) << 0)
+
+#define RPC_DRCR   0x000C  // R/W
+#define RPC_DRCR_SSLN  BIT(24)
+#define RPC_DRCR_RBURST(v) v) - 1) & 0x1F) << 16)
+#define RPC_DRCR_RCF   BIT(9)
+#define RPC_DRCR_RBE   BIT(8)
+#define RPC_DRCR_SSLE  BIT(0)
+
+#define RPC_DRCMR  0x0010  // R/W
+#define RPC_DRCMR_CMD(c)   (((c) & 0xFF) << 16)
+#define RPC_DRCMR_OCMD(c)  (((c) & 0xFF) << 0)
+
+#define RPC_DREAR  0x0014  // R/W
+#define RPC_DREAR_EAC(c)   (((c) & 0x7) << 0)
+
+#define RPC_DROPR  0x0018  // R/W
+
+#define RPC_DRENR  0x001C  // R/W
+#define RPC_DRENR_CDB(o)   (u32)o) & 0x3) << 30))
+#define RPC_DRENR_OCDB(o)  (((o) & 0x3) << 28)
+#define RPC_DRENR_ADB(o)   (((o) & 0x3) << 24)
+#define RPC_DRENR_OPDB(o)  (((o) & 0x3) << 20)
+#define RPC_DRENR_SPIDB(o) (((o) & 0x3) << 16)
+#define RPC_DRENR_DME  BIT(15)
+#define RPC_DRENR_CDE  BIT(14)
+#define RPC_DRENR_OCDE BIT(12)
+#define RPC_DRENR_ADE(v)   (((v) & 0xF) << 8)
+#define RPC_DRENR_OPDE(v)  (((v) & 0xF) << 4)
+
+#define RPC_SMCR   0x0020  // R/W
+#define RPC_SMCR_SSLKP BIT(8)
+#define RPC_SMCR_SPIRE BIT(2)
+#define RPC_SMCR_SPIWE BIT(1)
+#define RPC_SMCR_SPIE  BIT(0)
+
+#define RPC_SMCMR  0x0024  // R/W
+#define RPC_SMCMR_CMD(c)   (((c) & 0xFF) << 16)
+#define RPC_SMCMR_OCMD(c)  (((c) & 0xFF) << 0)
+
+#define RPC_SMADR  0x0028  // R/W
+#define RPC_SMOPR  0x002C  // R/W
+#define RPC_SMOPR_OPD3(o)  (((o) & 0xFF) << 24)
+#define RPC_SMOPR_OPD2(o)  (((o) & 0xFF) << 16)
+#define RPC_SMOPR_OPD1(o)  (((o) & 0xFF) << 8)
+#define RPC_SMOPR_OPD0(o)  (((o) & 0xFF) << 0)
+
+#define RPC_SM

Re: [PATCH] sb1000: fix a couple of indentation issues

2019-01-17 Thread David Miller
From: Colin King 
Date: Thu, 17 Jan 2019 00:13:01 +

> From: Colin Ian King 
> 
> There is an if statement and a return statement that are incorrectly
> indented. Fix these.
> 
> Signed-off-by: Colin Ian King 

Applied to net-next.


Re: [PATCH] wireless: remove unneeded semicolon

2019-01-17 Thread Steve deRosier
On Thu, Jan 17, 2019 at 7:33 PM YueHaibing  wrote:
>
> remove unneeded semicolon
>
> Signed-off-by: YueHaibing 
> ---
>  drivers/net/wireless/ath/ath10k/wmi.h | 2 +-
>  drivers/net/wireless/ath/ath6kl/init.c| 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +-
>  drivers/net/wireless/ray_cs.c | 2 +-
>  drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c  | 6 +++---
>  5 files changed, 7 insertions(+), 7 deletions(-)
>
...
> diff --git a/drivers/net/wireless/ath/ath6kl/init.c 
> b/drivers/net/wireless/ath/ath6kl/init.c
> index 54132af..aa1c71a 100644
> --- a/drivers/net/wireless/ath/ath6kl/init.c
> +++ b/drivers/net/wireless/ath/ath6kl/init.c
> @@ -1140,7 +1140,7 @@ static int ath6kl_fetch_fw_apin(struct ath6kl *ar, 
> const char *name)
>
> len -= ie_len;
> data += ie_len;
> -   };
> +   }
>
> ret = 0;
>  out:

For ath6kl

Acked-by: Steve deRosier 


Re: [PATCH net V4] vhost: log dirty page correctly

2019-01-17 Thread David Miller
From: Jason Wang 
Date: Wed, 16 Jan 2019 16:54:42 +0800

> Vhost dirty page logging API is designed to sync through GPA. But we
> try to log GIOVA when device IOTLB is enabled. This is wrong and may
> lead to missing data after migration.
> 
> To solve this issue, when logging with device IOTLB enabled, we will:
> 
> 1) reuse the device IOTLB translation result of GIOVA->HVA mapping to
>get HVA, for writable descriptor, get HVA through iovec. For used
>ring update, translate its GIOVA to HVA
> 2) traverse the GPA->HVA mapping to get the possible GPA and log
>through GPA. Pay attention this reverse mapping is not guaranteed
>to be unique, so we should log each possible GPA in this case.
> 
> This fix the failure of scp to guest during migration. In -next, we
> will probably support passing GIOVA->GPA instead of GIOVA->HVA.
> 
> Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API")
> Reported-by: Jintack Lim 
> Cc: Jintack Lim 
> Signed-off-by: Jason Wang 

Applied and queued up for -stable.


[PATCH RFC 1/1] arm64: Use PSCI calls for CPU stop when hotplug is supported

2019-01-17 Thread Pramod Kumar
If CPU hotplug is supported, ipi_cpu_stop should use PSCI cpudie
call to stop the CPU. This call ensures L1/L2 cache flush,
CPUs cache-cohenrecy setting w.r.to interconnect.

Apart from this, this gives control to f/w to reduce power consumption
by take appropriate decesion on power rails for plugging-out core.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/kernel/smp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 1598d6f..360e52b 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -822,8 +822,13 @@ static void ipi_cpu_stop(unsigned int cpu)
local_daif_mask();
sdei_mask_local_cpu();
 
+#ifdef CONFIG_HOTPLUG_CPU
+   if (cpu_ops[cpu]->cpu_die)
+   cpu_ops[cpu]->cpu_die(cpu);
+#else
while (1)
cpu_relax();
+#endif
 }
 
 #ifdef CONFIG_KEXEC_CORE
-- 
1.9.1



[PATCH v2] thermal: qoriq: add multiple sensors support

2019-01-17 Thread andy . tang
From: Yuantian Tang 

The QorIQ Layerscape SoC has several thermal sensors but the current
driver only supports one.

Massage the code to be sensor oriented and allow the support for
multiple sensors.

Signed-off-by: Yuantian Tang 
Reviewed-by: Daniel Lezcano 
---
v2:
- rebase to evalenti's tree

 drivers/thermal/qoriq_thermal.c |  104 +-
 1 files changed, 47 insertions(+), 57 deletions(-)

diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index 18c711b..3b5f5b3 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -59,14 +59,21 @@ struct qoriq_tmu_regs {
u32 ttr3cr; /* Temperature Range 3 Control Register */
 };
 
+struct qoriq_tmu_data;
+
 /*
  * Thermal zone data
  */
+struct qoriq_sensor {
+   struct thermal_zone_device  *tzd;
+   struct qoriq_tmu_data   *qdata;
+   int id;
+};
+
 struct qoriq_tmu_data {
-   struct thermal_zone_device *tz;
struct qoriq_tmu_regs __iomem *regs;
-   int sensor_id;
bool little_endian;
+   struct qoriq_sensor *sensor[SITES_MAX];
 };
 
 static void tmu_write(struct qoriq_tmu_data *p, u32 val, void __iomem *addr)
@@ -87,48 +94,50 @@ static u32 tmu_read(struct qoriq_tmu_data *p, void __iomem 
*addr)
 
 static int tmu_get_temp(void *p, int *temp)
 {
+   struct qoriq_sensor *qsensor = p;
+   struct qoriq_tmu_data *qdata = qsensor->qdata;
u32 val;
-   struct qoriq_tmu_data *data = p;
 
-   val = tmu_read(data, &data->regs->site[data->sensor_id].tritsr);
+   val = tmu_read(qdata, &qdata->regs->site[qsensor->id].tritsr);
*temp = (val & 0xff) * 1000;
 
return 0;
 }
 
-static int qoriq_tmu_get_sensor_id(void)
-{
-   int ret, id;
-   struct of_phandle_args sensor_specs;
-   struct device_node *np, *sensor_np;
-
-   np = of_find_node_by_name(NULL, "thermal-zones");
-   if (!np)
-   return -ENODEV;
-
-   sensor_np = of_get_next_child(np, NULL);
-   ret = of_parse_phandle_with_args(sensor_np, "thermal-sensors",
-   "#thermal-sensor-cells",
-   0, &sensor_specs);
-   if (ret) {
-   of_node_put(np);
-   of_node_put(sensor_np);
-   return ret;
-   }
+static const struct thermal_zone_of_device_ops tmu_tz_ops = {
+   .get_temp = tmu_get_temp,
+};
 
-   if (sensor_specs.args_count >= 1) {
-   id = sensor_specs.args[0];
-   WARN(sensor_specs.args_count > 1,
-   "%pOFn: too many cells in sensor specifier 
%d\n",
-   sensor_specs.np, sensor_specs.args_count);
-   } else {
-   id = 0;
+static int qoriq_tmu_register_tmu_zone(struct platform_device *pdev)
+{
+   struct qoriq_tmu_data *qdata = platform_get_drvdata(pdev);
+   int id, sites = 0;
+
+   for (id = 0; id < SITES_MAX; id++) {
+   qdata->sensor[id] = devm_kzalloc(&pdev->dev,
+   sizeof(struct qoriq_sensor), GFP_KERNEL);
+   if (!qdata->sensor[id])
+   return -ENOMEM;
+
+   qdata->sensor[id]->id = id;
+   qdata->sensor[id]->qdata = qdata;
+   qdata->sensor[id]->tzd = devm_thermal_zone_of_sensor_register(
+   &pdev->dev, id, qdata->sensor[id], &tmu_tz_ops);
+   if (IS_ERR(qdata->sensor[id]->tzd)) {
+   if (PTR_ERR(qdata->sensor[id]->tzd) == -ENODEV)
+   continue;
+   else
+   return PTR_ERR(qdata->sensor[id]->tzd);
+   }
+
+   sites |= 0x1 << (15 - id);
}
 
-   of_node_put(np);
-   of_node_put(sensor_np);
+   /* Enable monitoring */
+   if (sites != 0)
+   tmu_write(qdata, sites | TMR_ME | TMR_ALPF, &qdata->regs->tmr);
 
-   return id;
+   return 0;
 }
 
 static int qoriq_tmu_calibration(struct platform_device *pdev)
@@ -178,16 +187,11 @@ static void qoriq_tmu_init_device(struct qoriq_tmu_data 
*data)
tmu_write(data, TMR_DISABLE, &data->regs->tmr);
 }
 
-static const struct thermal_zone_of_device_ops tmu_tz_ops = {
-   .get_temp = tmu_get_temp,
-};
-
 static int qoriq_tmu_probe(struct platform_device *pdev)
 {
int ret;
struct qoriq_tmu_data *data;
struct device_node *np = pdev->dev.of_node;
-   u32 site;
 
if (!np) {
dev_err(&pdev->dev, "Device OF-Node is NULL");
@@ -203,13 +207,6 @@ static int qoriq_tmu_probe(struct platform_device *pdev)
 
data->little_endian = of_property_read_bool(np, "little-endian");
 
-   data->sensor_id = qoriq_tmu_get_sensor_id();
-   if (data->sensor_id < 0) {
-   dev_err(&pdev->dev, "Failed to get sensor id\n");
-   ret = -E

[git pull] drm nouveau TU102 hw support

2019-01-17 Thread Dave Airlie
Hi Linus,

This is a separate pull req for -fixes that just contains the patch to
enable TU102 GPUs with nouveau (RTX 2080 Ti).

It seems small enough to go in now rather than wait for merge.

Dave.

drm-fixes-2019-01-18-1:
drm/nouveau: add TU102 support
The following changes since commit df0219b4f9576c72b618db5edf7bb75c14829dbd:

  Merge tag 'drm-misc-fixes-2019-01-17' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2019-01-18
09:14:45 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-18-1

for you to fetch changes up to 9420151d88ca35cd7f857774d90bfdca505a2cc1:

  Merge branch 'linux-4.21' of git://github.com/skeggsb/linux into
drm-fixes (2019-01-18 15:38:18 +1000)


drm/nouveau: add TU102 support


Ben Skeggs (1):
  drm/nouveau/core: recognise TU102

Dave Airlie (1):
  Merge branch 'linux-4.21' of git://github.com/skeggsb/linux into drm-fixes

 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 33 +++
 1 file changed, 33 insertions(+)


[PATCH INTERNAL RFC 1/1] arm64: Use PSCI calls for CPU stop when hotplug is supported

2019-01-17 Thread Pramod Kumar
If CPU hotplug is supported, ipi_cpu_stop should use PSCI cpudie
call to stop the CPU. This call ensures L1/L2 cache flush,
CPUs cache-cohenrecy setting w.r.to interconnect.

Apart from this, this gives control to f/w to reduce power consumption
by take appropriate decesion on power rails for plugging-out core.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm64/kernel/smp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 1598d6f..360e52b 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -822,8 +822,13 @@ static void ipi_cpu_stop(unsigned int cpu)
local_daif_mask();
sdei_mask_local_cpu();
 
+#ifdef CONFIG_HOTPLUG_CPU
+   if (cpu_ops[cpu]->cpu_die)
+   cpu_ops[cpu]->cpu_die(cpu);
+#else
while (1)
cpu_relax();
+#endif
 }
 
 #ifdef CONFIG_KEXEC_CORE
-- 
1.9.1



Re: linux-next: Fixes tag needs some work in the cpufreq-arm tree

2019-01-17 Thread Viresh Kumar
On 18-01-19, 16:33, Stephen Rothwell wrote:
> Hi Viresh,
> 
> In commit
> 
>   3ca12c96ef5e ("MAINTAINERS: use common indentation")
> 
> Fixes tag
> 
>   Fixes: 46e2856b8e188949757c9123fd7f9ce36edd1a52
> 
> Fixes tags should be in this format:
> 
>   Fixes: 46e2856b8e18 ("cpufreq: Add Kryo CPU scaling driver")

Fixed and pushed again.

I missed looking into that. You must be running some sort of sanity
checks on the branch itself, can I know what exactly are you doing so
that I can try the same.

-- 
viresh


Re: [git pull] drm fixes for 5.0-rc3

2019-01-17 Thread pr-tracker-bot
The pull request you sent on Fri, 18 Jan 2019 10:43:13 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-18

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1092a94fcbcde03a8c2cc554f305af48c95d5d58

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] Please pull RDMA subsystem changes

2019-01-17 Thread pr-tracker-bot
The pull request you sent on Fri, 18 Jan 2019 03:56:44 +:

> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d7393226d15add056285c8fc86723d54d7e0c77d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


linux-next: Fixes tag needs some work in the cpufreq-arm tree

2019-01-17 Thread Stephen Rothwell
Hi Viresh,

In commit

  3ca12c96ef5e ("MAINTAINERS: use common indentation")

Fixes tag

  Fixes: 46e2856b8e188949757c9123fd7f9ce36edd1a52

Fixes tags should be in this format:

  Fixes: 46e2856b8e18 ("cpufreq: Add Kryo CPU scaling driver")

-- 
Cheers,
Stephen Rothwell


pgpnxoZQnfq3P.pgp
Description: OpenPGP digital signature


[PATCH] mtd: rawnand: denali: get ->setup_data_interface() working again

2019-01-17 Thread Masahiro Yamada
Commit 7a08dbaedd36 ("mtd: rawnand: Move ->setup_data_interface() to
nand_controller_ops") missed to invert the if-conditonal for denali.
Since then, the Denali NAND driver cannnot invoke setup_data_interface.

Fixes: 7a08dbaedd36 ("mtd: rawnand: Move ->setup_data_interface() to 
nand_controller_ops")
Cc: linux-stable  # v4.20
Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/raw/denali.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index eebac35..6e8edc9 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1322,7 +1322,7 @@ int denali_init(struct denali_nand_info *denali)
}
 
/* clk rate info is needed for setup_data_interface */
-   if (denali->clk_rate && denali->clk_x_rate)
+   if (!denali->clk_rate || !denali->clk_x_rate)
chip->options |= NAND_KEEP_TIMINGS;
 
chip->legacy.dummy_controller.ops = &denali_controller_ops;
-- 
2.7.4



Re: [PATCH v6] arm64: dts: qcom: sdm845: Add Q6V5 MSS node

2019-01-17 Thread Sibi Sankar

On 2019-01-18 04:35, Doug Anderson wrote:

Hi,

On Mon, Jan 14, 2019 at 11:22 AM Sibi Sankar  
wrote:

+   mss_pil: remoteproc@408 {
+   compatible = "qcom,sdm845-mss-pil";
+   reg = <0x0408 0x408>, <0x0418 0x48>;


This will now need to be adjusted to:

reg = <0 0x0408 0 0x408>, <0 0x0418 0 0x48>;


Yup, this was on my todo list after Bjorn
posted out the patch



This fixes things up to deal with the patch ("arm64: dts: qcom:
sdm845: Increase address and size cells for soc"), AKA:
- https://patchwork.kernel.org/patch/10767511/
- 
https://lkml.kernel.org/r/20190117042940.25487-2-bjorn.anders...@linaro.org



-Doug


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


Re: INFO: rcu detected stall in ndisc_alloc_skb

2019-01-17 Thread Tetsuo Handa
Dmitry Vyukov wrote:
> On Sun, Jan 6, 2019 at 2:47 PM Tetsuo Handa
>  wrote:
> >
> > On 2019/01/06 22:24, Dmitry Vyukov wrote:
> > >> A report at 2019/01/05 10:08 from "no output from test machine (2)"
> > >> ( https://syzkaller.appspot.com/text?tag=CrashLog&x=1700726f40 )
> > >> says that there are flood of memory allocation failure messages.
> > >> Since continuous memory allocation failure messages itself is not
> > >> recognized as a crash, we might be misunderstanding that this problem
> > >> is not occurring recently. It will be nice if we can run testcases
> > >> which are executed on bpf-next tree.
> > >
> > > What exactly do you mean by running test cases on bpf-next tree?
> > > syzbot tests bpf-next, so it executes lots of test cases on that tree.
> > > One can also ask for patch testing on bpf-next tree to test a specific
> > > test case.
> >
> > syzbot ran "some tests" before getting this report, but we can't find from
> > this report what the "some tests" are. If we could record all tests executed
> > in syzbot environments before getting this report, we could rerun the tests
> > (with manually examining where the source of memory consumption is) in local
> > environments.
> 
> Filed https://github.com/google/syzkaller/issues/917 for this.

Thanks. Here is what I would suggest.

Let syz-fuzzer write to /dev/kmsg . But don't directly write syz-program lines.
Instead, just write the hash value of syz-program lines, and allow downloading
syz-program lines from external URL. Also, use the first 12 characters of the
hash value as comm name executing that syz-program lines. An example of console
output would look something like below.


  [$(uptime)][$(caller_info)] executing program 
#0123456789abcdef0123456789abcdef
  [$(uptime)][$(caller_info)] 
$(kernel_messages_caused_by_0123456789abcdef0123456789abcdef_are_here)
  [$(uptime)][$(caller_info)] executing program 
#456789abcdef0123456789abcdef0123
  [$(uptime)][$(caller_info)] 
$(kernel_messages_caused_by_456789abcdef0123456789abcdef0123_and_0123456789abcdef0123456789abcdef_are_here)
  [$(uptime)][$(caller_info)] executing program 
#89abcdef0123456789abcdef01234567
  [$(uptime)][$(caller_info)] 
$(kernel_messages_caused_by_89abcdef0123456789abcdef01234567_456789abcdef0123456789abcdef0123_and_0123456789abcdef0123456789abcdef_are_here)
  [$(uptime)][$(caller_info)] BUG: unable to handle kernel paging request at 
$(address)
  [$(uptime)][$(caller_info)] CPU: $(cpu) PID: $(pid) Comm: syz#89abcdef0123 
Not tainted $(version) #$(build)
  [$(uptime)][$(caller_info)] $(backtrace_of_caller_info_is_here)
  [$(uptime)][$(caller_info)] Kernel panic - not syncing: Fatal exception

Then, we can build CrashLog by picking up all "executing program #" lines and
"latest lines up to available space" from console output like below.

  [$(uptime)][$(caller_info)] executing program 
#0123456789abcdef0123456789abcdef
  [$(uptime)][$(caller_info)] executing program 
#456789abcdef0123456789abcdef0123
  [$(uptime)][$(caller_info)] executing program 
#89abcdef0123456789abcdef01234567
  [$(uptime)][$(caller_info)] 
$(kernel_messages_caused_by_89abcdef0123456789abcdef01234567_456789abcdef0123456789abcdef0123_and_0123456789abcdef0123456789abcdef_are_here)
  [$(uptime)][$(caller_info)] BUG: unable to handle kernel paging request at 
$(address)
  [$(uptime)][$(caller_info)] CPU: $(cpu) PID: $(pid) Comm: syz89abcdef0123 Not 
tainted $(version) #$(build)
  [$(uptime)][$(caller_info)] $(backtrace_of_caller_info_is_here)
  [$(uptime)][$(caller_info)] Kernel panic - not syncing: Fatal exception

Then, we can understand that a crash happened when executing 89abcdef0123 and
download 89abcdef0123456789abcdef01234567 for analysis. Also, we can download
0123456789abcdef0123456789abcdef and 456789abcdef0123456789abcdef0123 as needed.

Honestly, since lines which follows "$(date) executing program $(num):" line can
become so long, it is difficult to find where previous/next kernel messages are.
If only one-liner "executing program #" output is used, it is easy to find
previous/next kernel messages.

The program referenced by "executing program #" would be made downloadable via
Web server or git repository. Maybe "executing program https://$server/$hash";
for the former case. But repeating "https://$server/"; part would be redundant.

The question for me is, whether sysbot can detect hash collision with different
syz-program lines before writing the hash value to /dev/kmsg, and retry by 
modifying
syz-program lines in order to get a new hash value until collision is avoided.
If it is difficult, simpler choice like current Unix time and PID could be used
instead...


Re: [git pull] drm fixes for 5.0-rc3

2019-01-17 Thread Linus Torvalds
On Fri, Jan 18, 2019 at 12:43 PM Dave Airlie  wrote:
>
> Going to be at LCA next week in Christchurch, but should be fine for
> normal pulls.

.. hey, me too.

>   git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-18

Pulled,

  Linus


Re: [PATCH v2 2/2] dt-bindings: edac: Aspeed AST2500

2019-01-17 Thread Andrew Jeffery
On Fri, 18 Jan 2019, at 03:08, Stefan Schaeckeler wrote:
> From: Stefan M Schaeckeler 
> 
> Add support for EDAC on the Aspeed AST2500 SoC.
> 
> Signed-off-by: Stefan M Schaeckeler 

Reviewed-by: Andrew Jeffery 

> ---
>  .../bindings/edac/aspeed-sdram-edac.txt   | 25 +++
>  1 file changed, 25 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
> 
> diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-
> edac.txt b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
> new file mode 100644
> index ..6a0f3d90d682
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
> @@ -0,0 +1,25 @@
> +Aspeed AST2500 SoC EDAC node
> +
> +The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without 
> ECC (error
> +correction check).
> +
> +The memory controller supports SECDED (single bit error correction, 
> double bit
> +error detection) and single bit error auto scrubbing by reserving 8 
> bits for
> +every 64 bit word (effectively reducing available memory to 8/9).
> +
> +Note, the bootloader must configure ECC mode in the memory controller.
> +
> +
> +Required properties:
> +- compatible: should be "aspeed,ast2500-sdram-edac"
> +- reg:sdram controller register set should be <0x1e6e 
> 0x174>
> +- interrupts: should be AVIC interrupt #0
> +
> +
> +Example:
> +
> + edac: sdram@1e6e {
> + compatible = "aspeed,ast2500-sdram-edac";
> + reg = <0x1e6e 0x174>;
> + interrupts = <0>;
> + };
> -- 
> 2.19.1
> 


Re: [PATCH v4] cpufreq: s5pv210: Defer probe if getting regulators fail

2019-01-17 Thread Viresh Kumar
On 14-01-19, 08:51, Krzysztof Kozlowski wrote:
> On Sun, 13 Jan 2019 at 20:58, Paweł Chmiel
>  wrote:
> >
> > There is possibility, that when probing driver, regulators are not yet
> > initialized. In this case we should return EPROBE_DEFER and wait till
> > they're initialized, since they're required currently for cpufreq driver
> > to work. Also move regulator initialization code at beginning of probe,
> > so we can defer as fast as posibble.
> >
> > Signed-off-by: Paweł Chmiel 
> > ---
> > Changes from v3:
> >   - Zero dmc_base pointers after unmapping them
> >   - If getting vddarm regulator fails just return, no need to do goto
> > jump which would do the same
> >
> > Changes from v2:
> >   - Handle all error paths in probe
> >
> > Changes from v1:
> >   - Fix compilation error
> >   - Reorganize code so it's smaller
> 
> Reviewed-by: Krzysztof Kozlowski 

Applied, thanks.

-- 
viresh


Re: [GIT PULL] hwmon fixes for hwmon-for-v5.0-rc3

2019-01-17 Thread pr-tracker-bot
The pull request you sent on Thu, 17 Jan 2019 12:56:50 -0800:

> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
> hwmon-for-v5.0-rc3

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0a2fbed84a962c486a71d2c91c86a31332dcbf02

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] LED fix for 5.0-rc3.

2019-01-17 Thread pr-tracker-bot
The pull request you sent on Thu, 17 Jan 2019 22:43:52 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git 
> tags/led-fix-for-5.0-rc3

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2451f3717c538795fc9fade46916683ebf7ea959

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [PATCH v2] misc: aspeed-lpc-ctrl: make parameter optional

2019-01-17 Thread Andrew Jeffery
Hi Vijay,

Thanks for doing the work to fix the driver. Some minor queries/points
below.

On Thu, 17 Jan 2019, at 08:31, Vijay Khemka wrote:
> Makiing memory-region and flash as optional parameter in device
> tree if user needs to use these parameter through ioctl then
> need to define in devicetree.
> 
> Signed-off-by: Vijay Khemka 
> ---
>  drivers/misc/aspeed-lpc-ctrl.c | 58 +-
>  1 file changed, 36 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-
> ctrl.c
> index a024f8042259..332210e06e98 100644
> --- a/drivers/misc/aspeed-lpc-ctrl.c
> +++ b/drivers/misc/aspeed-lpc-ctrl.c
> @@ -68,6 +68,7 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file, 
> unsigned int cmd,
>   unsigned long param)
>  {
>   struct aspeed_lpc_ctrl *lpc_ctrl = file_aspeed_lpc_ctrl(file);
> + struct device *dev = file->private_data;
>   void __user *p = (void __user *)param;
>   struct aspeed_lpc_ctrl_mapping map;
>   u32 addr;
> @@ -90,6 +91,12 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file, 
> unsigned int cmd,
>   if (map.window_id != 0)
>   return -EINVAL;
>  
> + /* If memory-region is not described in device tree */
> + if (!lpc_ctrl->mem_size) {
> + dev_err(dev, "Didn't find reserved memory\n");
> + return -EINVAL;

I feel like EINVAL isn't quite right - it's pretty generic, and the parameter
value changes its validity with the devicetree context. My gut instinct
would be to use EINVAL for parameter values that violate assumptions
of the driver rather than violate configuration of the driver. Maybe ENXIO
("No such device or address") is an improvement: "I can't map that device
because there's no such device or address"?

> + }
> +
>   map.size = lpc_ctrl->mem_size;
>  
>   return copy_to_user(p, &map, sizeof(map)) ? -EFAULT : 0;
> @@ -126,9 +133,18 @@ static long aspeed_lpc_ctrl_ioctl(struct file 
> *file, unsigned int cmd,
>   return -EINVAL;
>  
>   if (map.window_type == ASPEED_LPC_CTRL_WINDOW_FLASH) {
> + if (!lpc_ctrl->pnor_size) {
> + dev_err(dev, "Didn't find host pnor flash\n");
> + return -EINVAL;

See the error code discussion above. Also, this is userspace's error not 
the kernel's, so I think dev_err() is a bit harsh. Probably best to just let
userspace log the error if it thinks the it is concerning.

> + }
>   addr = lpc_ctrl->pnor_base;
>   size = lpc_ctrl->pnor_size;
>   } else if (map.window_type == ASPEED_LPC_CTRL_WINDOW_MEMORY) {
> + /* If memory-region is not described in device tree */
> + if (!lpc_ctrl->mem_size) {
> + dev_err(dev, "Didn't find reserved memory\n");
> + return -EINVAL;

as above.

> + }
>   addr = lpc_ctrl->mem_base;
>   size = lpc_ctrl->mem_size;
>   } else {
> @@ -196,17 +212,17 @@ static int aspeed_lpc_ctrl_probe(struct 
> platform_device *pdev)
>   if (!lpc_ctrl)
>   return -ENOMEM;
>  
> + /* If flash is described in device tree then store */
>   node = of_parse_phandle(dev->of_node, "flash", 0);
>   if (!node) {
> - dev_err(dev, "Didn't find host pnor flash node\n");
> - return -ENODEV;
> - }
> -
> - rc = of_address_to_resource(node, 1, &resm);
> - of_node_put(node);
> - if (rc) {
> - dev_err(dev, "Couldn't address to resource for flash\n");
> - return rc;
> + dev_dbg(dev, "Didn't find host pnor flash node\n");
> + } else {
> + rc = of_address_to_resource(node, 1, &resm);
> + of_node_put(node);
> + if (rc) {
> + dev_err(dev, "Couldn't address to resource for 
> flash\n");
> + return rc;
> + }
>   }
>  
>   lpc_ctrl->pnor_size = resource_size(&resm);
> @@ -214,22 +230,22 @@ static int aspeed_lpc_ctrl_probe(struct 
> platform_device *pdev)
>  
>   dev_set_drvdata(&pdev->dev, lpc_ctrl);
>  
> + /* If memory-region is described in device tree then store */
>   node = of_parse_phandle(dev->of_node, "memory-region", 0);
>   if (!node) {
> - dev_err(dev, "Didn't find reserved memory\n");
> - return -EINVAL;
> - }
> + dev_dbg(dev, "Didn't find reserved memory\n");
> + } else {
> + rc = of_address_to_resource(node, 0, &resm);
> + of_node_put(node);
> + if (rc) {
> + dev_err(dev, "Couldn't address to resource for reserved 
> memory\n");
> + return -ENOMEM;

W

[RFC PATCH] ALSA: core: Add DMA share buffer support

2019-01-17 Thread Baolin Wang
This patch adds dma share buffer support, which allows a dma-buf to be shared
between processes by passing file descriptors between them, allowing multiple
processes to cooperate in filling the DMA buffer used by the audio hardware
without the need to copy data around. This reduces both latency and CPU load,
especially in configurations where only one application is playing audio and
so context switches can be avoided.

In userspace, we can use ioctl:SNDRV_PCM_IOCTL_DMABUF_EXPORT to export one
dma buffer to a PCM, and use ioctl:SNDRV_PCM_IOCTL_DMABUF_ATTACH and
ioctl:SNDRV_PCM_IOCTL_DMABUF_DETACH to attach or detach one device to the
dma buffer. Morevoer we can use dma buffer ioctl:DMA_BUF_IOCTL_SYNC to
guarantee the cache coherency of the DMA buffer.

You can refer to below patches [1] created by Leo Yan to use the dma buffer
in userspace.

[1] https://github.com/tinyalsa/tinyalsa/pull/126

Welcome any comments. Thanks.

Signed-off-by: Baolin Wang 
---
Hi,

Before sending to ALSA mailing list, we had some internal discussion off line,
so I posted them to follow up.

1. One issue proposed by Srinivas Kandagatla, he proposed one use case example:
DSP1 pre-process(compress-to-pcm) the buffers, pass the fd to DSP2/audio-ip
to play pcm data. The dmabuf exporter (DSP1) is a different device than
audio device in this instance, so the DSP1 device cannot call
snd_pcm_dmabuf_export() to export one dma buffer and pass to the DSP2/audio-ip.

Our original design is, the dma buffer should be associated with one PCM
device, since different PCM devices may need different buffer types (see
SNDRV_DMA_TYPE_XXX) to play PCM data, and need consider the PCM device's
coherent capability for DMA memory. My concern is, if we let other
non-audio device to allocate one buffer and export it, how to guarantee
the dma buffer can be used by PCM device and have the same coherent capability
with the PCM device.

So I am not sure for this issue and need more suggestion to get a consensus.

2. Second question raised by Srinivas Kandagatla, he wondered:
"Am still unclear on the whole idea making a audio device dmabuf exporter
in Linux systems, unless you are sharing the dmabuf fd with other devices.

If you are working with just one device we could just live with mmap,
isn't it?"

Mark Brown gave the answer:
"The issue is permissions management. We've got a sound server that owns
all the sound hardware and needs to be able to retain administrative control
over it which means that permissions for the sound devices are locked down to
it. For performance reasons on systems where it's practical (eg, where there's
multiple audio streams the system can use to play data to the hardware) we
want to be able to have that server allow other applications with lower
permissions to stream data to/from the hardware without going through it. The
applications can't mmap() the device directly as that's too painful to do that
securely from a permission management point of view so we want to be able to
have the sound server do the mmap() then hand the mapped buffer off to the
application for it to use via a FD over a pipe. That way the only thing with
direct access to the devices is the sound server but the clients have a data
path that doesn't need to bounce through another process.

Practically speaking the only use case I can think of in an audio context is
for one reader and one writer (AIUI Android is envisioning this as one hardware
and one software), it's difficult to see how you could usefully chain multiple
in place transformations together in the way that you can with video 
applications
but I'm possibly not thinking of something here."
---
 include/sound/pcm.h |2 +
 include/sound/pcm_dmabuf.h  |   29 +++
 include/uapi/sound/asound.h |3 +
 sound/core/Kconfig  |4 +
 sound/core/Makefile |1 +
 sound/core/pcm.c|2 +
 sound/core/pcm_compat.c |3 +
 sound/core/pcm_dmabuf.c |  531 +++
 sound/core/pcm_native.c |   38 
 9 files changed, 613 insertions(+)
 create mode 100644 include/sound/pcm_dmabuf.h
 create mode 100644 sound/core/pcm_dmabuf.c

diff --git a/include/sound/pcm.h b/include/sound/pcm.h
index c47d9b4..d353e55 100644
--- a/include/sound/pcm.h
+++ b/include/sound/pcm.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define snd_pcm_substream_chip(substream) ((substream)->private_data)
 #define snd_pcm_chip(pcm) ((pcm)->private_data)
@@ -455,6 +456,7 @@ struct snd_pcm_substream {
size_t buffer_bytes_max;/* limit ring buffer size */
struct snd_dma_buffer dma_buffer;
size_t dma_max;
+   struct dma_buf_attachment *attachment;
/* -- hardware operations -- */
const struct snd_pcm_ops *ops;
/* -- runtime information -- */
diff --git a/include/sound/pcm_dmabuf.h b/include/sound/pcm_dmabuf.h
new file mode 100644
index 000..4e88c5f6
--- /dev/null
+++ b/include/sound/p

Re: [PATCH 3/4] crypto: hisilicon: Add HiSilicon ZIP accelerator support

2019-01-17 Thread Herbert Xu
On Wed, Jan 16, 2019 at 10:12:47PM +0800, Zhou Wang wrote:
>
> A stupid question: how do we test scomp alg?
> 
> It seems we can not use general comp API, e.g. crypto_alloc_comp
> to do this.
> 
> Could you give me any clue about this?

scomp algorithms are allocated through crypto_alloc_acomp.

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


Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

2019-01-17 Thread Linus Torvalds
On Thu, Jan 17, 2019 at 4:51 PM Linus Torvalds
 wrote:
>
> On Thu, Jan 17, 2019 at 9:37 AM Matthew Wilcox  wrote:
> >
> > Your patch 3/3 just removes the test.  Am I right in thinking that it
> > doesn't need to be *moved* because the existing test after !PageUptodate
> > catches it?
>
> That's the _hope_.
>
> That's the simplest patch I can come up with as a potential solution.
> But it's possible that there's some nasty performance regression
> because somebody really relies on not even triggering read-ahead, and
> we might need to do some totally different thing.

Oh, and somebody should probably check that there isn't some simple
way to just avoid that readahead code entirely.

In particular, right now we skip readahead for at least these cases:

/* no read-ahead */
if (!ra->ra_pages)
return;

if (blk_cgroup_congested())
return;

and I don't think we need to worry about the cgroup congestion case -
if the attack has to also congest its cgroup with IO, I think they
have bigger problems.

And I think 'ra_pages' can be zero only in the presence of IO errors,
but I might be wrong. It would be good if somebody double-checks that.

   Linus


Re: [PATCH v11 4/9] soc: qcom: rpmpd: Add a Power domain driver to model corners

2019-01-17 Thread Rajendra Nayak

[]..



diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index fcbf8a2e4080..df5cd9fa0d5e 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -98,6 +98,15 @@ config QCOM_RPMH
  of hardware components aggregate requests for these resources and
  help apply the aggregated state on the resource.
  
+config QCOM_RPMPD

+   bool "Qualcomm RPM Power domain driver"
+   depends on MFD_QCOM_RPM && QCOM_SMD_RPM


Since this is bool, but the dependent configurations are tristate,
configurations such as arm64:allmodconfig result in

CONFIG_QCOM_RPMPD=y
CONFIG_MFD_QCOM_RPM=m
CONFIG_QCOM_SMD_RPM=m

This in turn results in

arm-linux-gnueabi-ld: drivers/soc/qcom/rpmpd.o: in function 
`rpmpd_send_enable':

rpmpd.c:(.text+0x64): undefined reference to `qcom_rpm_smd_write'

arm-linux-gnueabi-ld: drivers/soc/qcom/rpmpd.o: in function 
`rpmpd_power_on':
rpmpd.c:(.text+0x408): undefined reference to `qcom_rpm_smd_write'

arm-linux-gnueabi-ld: rpmpd.c:(.text+0x460): undefined reference to 
`qcom_rpm_smd_write'


as reported by 0day.


Thanks for reporting this, the QCOM_RPMPD dependency on MFD_QCOM_RPM was removed
by a patch on top from Bjorn [1]. I have posted a fix now [2] to make QCOM_RPMPD
depend on QCOM_SMD_RPM=y

[1] https://lkml.org/lkml/2019/1/17/5
[2] https://lkml.org/lkml/2019/1/17/1043

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


Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

2019-01-17 Thread Linus Torvalds
On Fri, Jan 18, 2019 at 9:45 AM Vlastimil Babka  wrote:
>
> Or maybe we could resort to the 5.0-rc1 page table check (that is now being
> reverted) but only in cases when we are not allowed the page cache residency
> check? Or would that be needlessly complicated?

I think it would  be good fallback semantics, but I'm not sure it's
worth it. Have you tried writing a patch for it? I don't think you'd
want to do the check *when* you find a hole, so you'd have to do it
upfront and then pass the cached data down with the private pointer
(or have a separate "struct mm_walk" structure, perhaps?

So I suspect we're better off with the patch we have. But if somebody
*wants* to try to do that fancier patch, and it doesn't look
horrendous, I think it might be the "quality" solution.

  Linus


Re: [PATCH v2] lib/test_rhashtable: Make test_insert_dup() allocate its hash table dynamically

2019-01-17 Thread kbuild test robot
Hi Bart,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Bart-Van-Assche/lib-test_rhashtable-Make-test_insert_dup-allocate-its-hash-table-dynamically/20190118-081736
config: i386-randconfig-b0-01181042 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   lib/test_rhashtable.c: In function 'test_insert_dup':
>> lib/test_rhashtable.c:561:21: error: request for member 'ht' in something 
>> not a structure or union
  key = rht_obj(rhlt.ht, &rhl_test_objects[i].list_node.rhead);
^
   lib/test_rhashtable.c:565:45: error: request for member 'ht' in something 
not a structure or union
   err = PTR_ERR(rhashtable_insert_slow(rhlt.ht, key,
^

vim +/ht +561 lib/test_rhashtable.c

   540  
   541  static int __init test_insert_dup(struct test_obj_rhl *rhl_test_objects,
   542int cnt, bool slow)
   543  {
   544  struct rhltable *rhlt;
   545  unsigned int i, ret;
   546  const char *key;
   547  int err = 0;
   548  
   549  rhlt = kmalloc(sizeof(*rhlt), GFP_KERNEL);
   550  if (WARN_ON(!rhlt))
   551  return -EINVAL;
   552  
   553  err = rhltable_init(rhlt, &test_rht_params_dup);
   554  if (WARN_ON(err)) {
   555  kfree(rhlt);
   556  return err;
   557  }
   558  
   559  for (i = 0; i < cnt; i++) {
   560  rhl_test_objects[i].value.tid = i;
 > 561  key = rht_obj(rhlt.ht, 
 > &rhl_test_objects[i].list_node.rhead);
   562  key += test_rht_params_dup.key_offset;
   563  
   564  if (slow) {
   565  err = PTR_ERR(rhashtable_insert_slow(rhlt.ht, 
key,
   566   
&rhl_test_objects[i].list_node.rhead));
   567  if (err == -EAGAIN)
   568  err = 0;
   569  } else
   570  err = rhltable_insert(rhlt,
   571
&rhl_test_objects[i].list_node,
   572test_rht_params_dup);
   573  if (WARN(err, "error %d on element %d/%d (%s)\n", err, 
i, cnt, slow? "slow" : "fast"))
   574  goto skip_print;
   575  }
   576  
   577  ret = print_ht(rhlt);
   578  WARN(ret != cnt, "missing rhltable elements (%d != %d, %s)\n", 
ret, cnt, slow? "slow" : "fast");
   579  
   580  skip_print:
   581  rhltable_destroy(rhlt);
   582  kfree(rhlt);
   583  
   584  return 0;
   585  }
   586  

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


.config.gz
Description: application/gzip


Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map

2019-01-17 Thread Kairui Song
On Thu, Jan 17, 2019 at 5:40 PM Rafael J. Wysocki  wrote:
>
> On Thu, Jan 17, 2019 at 9:53 AM Dave Young  wrote:
> >
> > Add linux-acpi list
>
> Well, thanks, but please resend the patches with a CC to linux-acpi.
>

Hi, sure will do.
Any thought on adding an acpi_os_get_root_pointer_late and store rsdp
pointer as mentioned? Will updat the patch and post V2, and cc
linux-acpi as well later.

> > On 01/17/19 at 03:41pm, Kairui Song wrote:
> > > On Wed, Jan 16, 2019 at 5:46 PM Borislav Petkov  wrote:
> > > >
> > > > On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
> > > > > I didn't see a way to reuse things in that patch series, situation is
> > > > > different, in that patch it needs to get RSDP in very early boot stage
> > > > > so it did everything from scratch, in this patch kexec_file_load need
> > > > > to get RSDP too, but everything is well setup so things are a lot
> > > > > easier, just read from current boot_prams, efi and fallback to
> > > > > acpi_find_root_pointer should be good.
> > > >
> > > > No no. Early code should find out that venerable RSDP thing once and
> > > > will save it somewhere for further use. No gazillion parsings of it.
> > > > Just once and share it with the rest of the code that needs it.
> > > >
> > >
> > > How about we refill the boot_params.acpi_rsdp_addr if it is not valid
> > > in early code, so it could be used as a reliable RSDP address source?
> > > That should make things easier.
> > >
> > > But if early code should parse it and store it should be done in
> > > Chao's patch, or I can post another patch to do it if Chao's patch is
> > > merged.
> > >
> > > For now I think good to have something like this in this patch series
> > > to always keep storing acpi_rsdp in late code,
> > > acpi_os_get_root_pointer_late (maybe comeup with a better name later)
> > > could be used anytime to get RSDP and no extra parsing:
> > >
> > > --- a/drivers/acpi/osl.c
> > > +++ b/drivers/acpi/osl.c
> > > @@ -180,8 +180,8 @@ void acpi_os_vprintf(const char *fmt, va_list args)
> > >  #endif
> > >  }
> > >
> > > -#ifdef CONFIG_KEXEC
> > >  static unsigned long acpi_rsdp;
> > > +#ifdef CONFIG_KEXEC
> > >  static int __init setup_acpi_rsdp(char *arg)
> > >  {
> > > return kstrtoul(arg, 16, &acpi_rsdp);
> > > @@ -189,28 +189,38 @@ static int __init setup_acpi_rsdp(char *arg)
> > >  early_param("acpi_rsdp", setup_acpi_rsdp);
> > >  #endif
> > >
> > > +acpi_physical_address acpi_os_get_root_pointer_late(void) {
> > > +   return acpi_rsdp;
> > > +}
> > > +
> > >  acpi_physical_address __init acpi_os_get_root_pointer(void)
> > >  {
> > > acpi_physical_address pa;
> > >
> > > -#ifdef CONFIG_KEXEC
> > > if (acpi_rsdp)
> > > return acpi_rsdp;
> > > -#endif
> > > +
> > > pa = acpi_arch_get_root_pointer();
> > > -   if (pa)
> > > +   if (pa) {
> > > +   acpi_rsdp = pa;
> > > return pa;
> > > +   }
> > >
> > > if (efi_enabled(EFI_CONFIG_TABLES)) {
> > > -   if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> > > +   if (efi.acpi20 != EFI_INVALID_TABLE_ADDR) {
> > > +   acpi_rsdp = efi.acpi20;
> > > return efi.acpi20;
> > > -   if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> > > +   }
> > > +   if (efi.acpi != EFI_INVALID_TABLE_ADDR) {
> > > +   acpi_rsdp = efi.acpi;
> > > return efi.acpi;
> > > +   }
> > > pr_err(PREFIX "System description tables not found\n");
> > > } else if (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
> > > acpi_find_root_pointer(&pa);
> > > }
> > >
> > >  +   acpi_rsdp = pa;
> > > return pa;
> > >  }
> > >
> > > > --
> > > > Regards/Gruss,
> > > > Boris.
> > > >
> > > > Good mailing practices for 400: avoid top-posting and trim the reply.
> > > --
> > > Best Regards,
> > > Kairui Song



-- 
Best Regards,
Kairui Song


[PATCH] soc: qcom: update config dependencies for QCOM_RPMPD

2019-01-17 Thread Rajendra Nayak
Since QCOM_RPMPD is bool and it depends on QCOM_SMD_RPM
which is tristate, configurations such as arm64:allmodconfig
result in

CONFIG_QCOM_RPMPD=y
CONFIG_QCOM_SMD_RPM=m

This in turn results in

drivers/soc/qcom/rpmpd.o: In function `rpmpd_send_corner':
rpmpd.c:(.text+0x10c): undefined reference to `qcom_rpm_smd_write'
drivers/soc/qcom/rpmpd.o: In function `rpmpd_power_on':
rpmpd.c:(.text+0x3b4): undefined reference to `qcom_rpm_smd_write'
drivers/soc/qcom/rpmpd.o: In function `rpmpd_power_off':
rpmpd.c:(.text+0x520): undefined reference to `qcom_rpm_smd_write'
make: *** [vmlinux] Error 1

Fix it by making QCOM_RPMPD depend on QCOM_SMD_RPM=y

Reported-by: Guenter Roeck 
Signed-off-by: Rajendra Nayak 
---
Andy, this one should be applied on top of my v11 to add
rpmpd/rpmhpd drivers [1] and the fix from Bjorn to drop
A family RPM dependency [2]

[1] https://lkml.org/lkml/2019/1/9/1257
[2] https://lkml.org/lkml/2019/1/17/5

 drivers/soc/qcom/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index a5d5167c3f16..1ee298f6bf17 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -109,7 +109,7 @@ config QCOM_RPMHPD
 
 config QCOM_RPMPD
bool "Qualcomm RPM Power domain driver"
-   depends on QCOM_SMD_RPM
+   depends on QCOM_SMD_RPM=y
help
  QCOM RPM Power domain driver to support power-domains with
  performance states. The driver communicates a performance state
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



[PATCH v2 3/3] tracing: probeevent: Fix to make the type of $comm string

2019-01-17 Thread Masami Hiramatsu
Fix to make the type of $comm "string".
If we set the other type to $comm argument, it shows
meaningless value or wrong data. Currently probe events
allow us to set string array type (e.g. ":string[2]"), or
other digit types like x8 on $comm. But since clearly
$comm is just a string data, it should not be fetched
by other types including array.

Fixes: 35abb67de744 ("tracing: expose current->comm to [ku]probe events")
Signed-off-by: Masami Hiramatsu 
Cc: sta...@vger.kernel.org
---
 kernel/trace/trace_probe.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 9962cb5da8ac..44f078cda0ac 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -405,13 +405,14 @@ static int traceprobe_parse_probe_arg_body(char *arg, 
ssize_t *size,
return -E2BIG;
}
}
-   /*
-* The default type of $comm should be "string", and it can't be
-* dereferenced.
-*/
-   if (!t && strcmp(arg, "$comm") == 0)
+
+   /* Since $comm can not be dereferred, we can find $comm by strcmp */
+   if (strcmp(arg, "$comm") == 0) {
+   /* The type of $comm must be "string", and not an array. */
+   if (parg->count || (t && strcmp(t, "string")))
+   return -EINVAL;
parg->type = find_fetch_type("string");
-   else
+   } else
parg->type = find_fetch_type(t);
if (!parg->type) {
pr_info("Unsupported type: %s\n", t);



[PATCH v2 2/3] tracing: probeevent: Do not accumulate on ret variable

2019-01-17 Thread Masami Hiramatsu
Do not accumulate strlen result on "ret" local variable, because
it is accumulated on "total" local variable for array case.

Fixes: 40b53b771806 ("tracing: probeevent: Add array type support")
Signed-off-by: Masami Hiramatsu 
---
 kernel/trace/trace_probe_tmpl.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace_probe_tmpl.h b/kernel/trace/trace_probe_tmpl.h
index 5c56afc17cf8..e69b05a9f57c 100644
--- a/kernel/trace/trace_probe_tmpl.h
+++ b/kernel/trace/trace_probe_tmpl.h
@@ -88,7 +88,7 @@ process_fetch_insn_bottom(struct fetch_insn *code, unsigned 
long val,
/* 3rd stage: store value to buffer */
if (unlikely(!dest)) {
if (code->op == FETCH_OP_ST_STRING) {
-   ret += fetch_store_strlen(val + code->offset);
+   ret = fetch_store_strlen(val + code->offset);
code++;
goto array;
} else



[PATCH v2 1/3] tracing: uprobes: Re-enable $comm support for uprobe events

2019-01-17 Thread Masami Hiramatsu
Since commit 533059281ee5 ("tracing: probeevent: Introduce new
argument fetching code") dropped the $comm support from uprobe
events, this re-enables it.

For $comm support, uses strlcpy() instead of strncpy_from_user()
to copy current task's comm. Because it is in the kernel space,
strncpy_from_user() always fails to copy the comm.
This also uses strlen() instead of strnlen_user() to measure the
length of the comm.

Fixes: 533059281ee5 ("tracing: probeevent: Introduce new argument fetching 
code")
Signed-off-by: Masami Hiramatsu 
Reported-by: Andreas Ziegler 
Acked-by: Andreas Ziegler 
---
 kernel/trace/trace_uprobe.c |   15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 3a1d5ab6b4ba..b07e498ccbc6 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -156,7 +156,10 @@ fetch_store_string(unsigned long addr, void *dest, void 
*base)
if (unlikely(!maxlen))
return -ENOMEM;
 
-   ret = strncpy_from_user(dst, src, maxlen);
+   if (addr == (unsigned long)current->comm)
+   ret = strlcpy(dst, current->comm, maxlen);
+   else
+   ret = strncpy_from_user(dst, src, maxlen);
if (ret >= 0) {
if (ret == maxlen)
dst[ret - 1] = '\0';
@@ -180,7 +183,12 @@ fetch_store_strlen(unsigned long addr)
int len;
void __user *vaddr = (void __force __user *) addr;
 
-   len = strnlen_user(vaddr, MAX_STRING_SIZE);
+   if (addr == (unsigned long)current->comm) {
+   len = strlen(current->comm);
+   if (len)
+   len++;
+   } else
+   len = strnlen_user(vaddr, MAX_STRING_SIZE);
 
return (len > MAX_STRING_SIZE) ? 0 : len;
 }
@@ -220,6 +228,9 @@ process_fetch_insn(struct fetch_insn *code, struct pt_regs 
*regs, void *dest,
case FETCH_OP_IMM:
val = code->immediate;
break;
+   case FETCH_OP_COMM:
+   val = (unsigned long)current->comm;
+   break;
case FETCH_OP_FOFFS:
val = translate_user_vaddr(code->immediate);
break;



Re: ld: drivers/net/wireless/intel/iwlwifi/iwl-devtrace.h:81: undefined reference to `ieee80211_hdrlen'

2019-01-17 Thread Kalle Valo
+ linux-wireless

kbuild test robot  writes:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   47bfa6d9dc8c060bf56554a465c9031e286d2f80
> commit: aca432f06b8a60a92b27fb46e6518a19b28ca93f iwlwifi: make MVM and DVM 
> depend on MAC80211
> date:   4 weeks ago
> config: x86_64-randconfig-g3-201902 (attached as .config)
> compiler: gcc-8 (Debian 8.2.0-14) 8.2.0
> reproduce:
> git checkout aca432f06b8a60a92b27fb46e6518a19b28ca93f
> # save the attached .config to linux build tree
> make ARCH=x86_64 
>
> All errors (new ones prefixed by >>):
>
>ld: drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.o: in function 
> `iwl_init_channel_map':
>drivers/net/wireless/intel/iwlwifi/iwl-eeprom-parse.c:609: undefined 
> reference to `ieee80211_channel_to_frequency'
>ld: drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.o: in function 
> `iwl_init_channel_map':
>drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c:353: undefined 
> reference to `ieee80211_channel_to_frequency'
>ld: drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.o: in function 
> `iwl_parse_nvm_mcc_info':
>drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c:1050: undefined 
> reference to `ieee80211_channel_to_frequency'
>ld: drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c:1099: undefined 
> reference to `reg_query_regdb_wmm'
>ld: drivers/net/wireless/intel/iwlwifi/pcie/tx.o: in function 
> `iwl_trans_pcie_tx':
>drivers/net/wireless/intel/iwlwifi/pcie/tx.c:2317: undefined reference to 
> `ieee80211_hdrlen'
>ld: drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.o: in function 
> `iwl_pcie_gen2_build_tfd':
>drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c:550: undefined reference 
> to `ieee80211_hdrlen'
>ld: drivers/net/wireless/intel/iwlwifi/iwl-devtrace.o: in function 
> `iwl_rx_trace_len':
>drivers/net/wireless/intel/iwlwifi/iwl-devtrace.h:81: undefined reference 
> to `ieee80211_hdrlen'
>>> ld: drivers/net/wireless/intel/iwlwifi/iwl-devtrace.h:81: undefined
>>> reference to `ieee80211_hdrlen'
>>> ld: drivers/net/wireless/intel/iwlwifi/iwl-devtrace.h:81: undefined
>>> reference to `ieee80211_hdrlen'
>ld:
> drivers/net/wireless/intel/iwlwifi/iwl-devtrace.o:drivers/net/wireless/intel/iwlwifi/iwl-devtrace.h:81:
> more undefined references to `ieee80211_hdrlen' follow

This should be fixed by:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=ec5aecc0b227f5509d25853537f989ca303e2be1

-- 
Kalle Valo


[PATCH v2 0/3] tracing: probeevent: Fix probe argument parser and handler

2019-01-17 Thread Masami Hiramatsu
Hi,

Here is the 2nd version of series to fix several bugs in probe event
argument parser and handler routines.

In this version I just added Fixes tags so that it makes clear which
release should be fixed.

Recently I got 2 issues reported by Andreas, see
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1899098.html

One issue is already fixed by Andreas (Thanks!) but $comm handling
issue still exists on uprobe event. [1/3] fixes it.
And I found other issues around that, [2/3] is just a trivial cleanup,
[3/3] fixes $comm type issue which occurs not only uprobe events but
also on kprobe events. Anyway, after this series applied, $comm must
be "string" type and not be an array.

Thank you,

---

Masami Hiramatsu (3):
  tracing: uprobes: Re-enable $comm support for uprobe events
  tracing: probeevent: Do not accumulate on ret variable
  tracing: probeevent: Fix to make the type of $comm string


 kernel/trace/trace_probe.c  |   13 +++--
 kernel/trace/trace_probe_tmpl.h |2 +-
 kernel/trace/trace_uprobe.c |   15 +--
 3 files changed, 21 insertions(+), 9 deletions(-)

--
Masami Hiramatsu (Linaro) 


linux-next: Fixes tag needs some work in the drm-fixes tree

2019-01-17 Thread Stephen Rothwell
Hi all,

In commit

  dddce8b49005 ("drm/amd/display: Only get the connector state for VRR when 
toggled")

Fixes tag

  Fixes: 3cc22f281318 ("drm/amdgpu: Set FreeSync state using drm VRR 
properties")

has these problem(s):

  - Target SHA1 does not exist

-- 
Cheers,
Stephen Rothwell


pgpGH06FDJZlF.pgp
Description: OpenPGP digital signature


Re: [PATCHv2] watchdog: qcom: Add suspend/resume support

2019-01-17 Thread Sai Prakash Ranjan

On 1/18/2019 9:23 AM, Guenter Roeck wrote:

On 1/17/19 6:58 PM, Sai Prakash Ranjan wrote:

On 1/17/2019 11:46 PM, Guenter Roeck wrote:

On Thu, Jan 17, 2019 at 08:49:42PM +0530, Sai Prakash Ranjan wrote:

This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active after suspend would result in unwanted
crashes/resets if resume happens after a long time.

Signed-off-by: Sai Prakash Ranjan 


Reviewed-by: Guenter Roeck 



Thanks Guenter. Should I send a v3 with your reviewed-by?



I add it to my watchdog-next branch and Wim will pick it up from there.
No need to resend.



Ok thanks.

- Sai

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


linux-next: Tree for Jan 18

2019-01-17 Thread Stephen Rothwell
Hi all,

Changes since 20190117:

The arc-current tree gained a conflict against Linus' tree.

The vfs tree still had its build failure for which I applied a patch.

The mali-dp tree still had its failure for which I applied a merge
fix patch.

The imx-drm tree gained a build failure for which I reverted a commit.

Non-merge commits (relative to Linus' tree): 2439
 2664 files changed, 79722 insertions(+), 38102 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 295 trees (counting Linus' and 69 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 (a3a80255d58d Merge tag 'afs-fixes-20190117' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs)
Merging fixes/master (0ce4e20ca4ea x86/syscalls: Mark expected switch 
fall-throughs)
Merging kbuild-current/fixes (e00d88804814 kbuild: mark prepare0 as PHONY to 
fix external module build)
Merging arc-current/for-curr (51769fabee34 ARCv2: lib: memeset: fix doing 
prefetchw outside of buffer)
CONFLICT (content): Merge conflict in arch/arc/mm/fault.c
Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential 
uninitialized return)
Merging arm64-fixes/for-next/fixes (7fa1e2e6afa7 kasan, arm64: remove redundant 
ARCH_SLAB_MINALIGN define)
Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes)
Merging powerpc-fixes/fixes (7bea7ac0ca01 powerpc/syscalls: Fix syscall tracing)
Merging sparc/master (b71acb0e3721 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (cb12d72b27a6 atm: he: fix sign-extension overflow on large 
shift)
Merging bpf/master (c61c27687a5a bpf: Correctly annotate implicit fall through 
in bpf_base_func_proto)
Merging ipsec/master (e2612cd496e7 xfrm: Make set-mark default behavior 
backward compatible)
Merging netfilter/master (80b3671e9377 ip6_gre: update version related info 
when changing link)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (ec5aecc0b227 iwlwifi: make IWLWIFI depend on 
CFG80211)
Merging mac80211/master (1d51b4b1d3f2 Merge tag 'm68k-for-v4.20-tag2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k)
Merging rdma-fixes/for-rc (d6f4a21f309d RDMA/uverbs: Mark ioctl responses with 
UVERBS_ATTR_F_VALID_OUTPUT)
Merging sound-current/for-linus (687ae9e287b3 ASoC: intel: skl: Fix display 
power regression)
Merging sound-asoc-fixes/for-linus (f06f20da6565 Merge branch 'asoc-5.0' into 
asoc-linus)
Merging regmap-fixes/for-linus (b3ffce399349 Merge branch 'regmap-5.0' into 
regmap-linus)
Merging regulator-fixes/for-linus (b4c4aa249eff Merge branch 'regulator-5.0' 
into regulator-linus)
Merging spi-fixes/for-linus (601ea15da77b Merge branch 'spi-5.0' into spi-linus)
Merging pci-current/for-linus (d2fd6e81912a PCI: Fix __initdata issue with 
"pci=disable_acs_redir" parameter)
Merging driver-core.current/driver-core-linus (1c7fc5cbc339 Linux 5.0-rc2)
Merging tty.current/tty-linus (1c7fc5cbc339 Linux 5.0-rc2)
Merging usb.current/usb-linus (1c7fc5cbc339 

[PATCH 3/3] PCI: iproc: Add PCIe 32bit outbound memory configuration

2019-01-17 Thread Srinath Mannam
IPROC PCIe RC supports outbound memory mapping with SOC address inside
4GB address boundary, which is 32 bit AXI address.
This patch add the support.

Signed-off-by: Srinath Mannam 
Signed-off-by: Abhishek Shah 
Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
Reviewed-by: Vikram Prakash 
---
 drivers/pci/controller/pcie-iproc.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/pcie-iproc.c 
b/drivers/pci/controller/pcie-iproc.c
index ee89d56..4d0e63b 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -982,8 +982,25 @@ static int iproc_pcie_setup_ob(struct iproc_pcie *pcie, 
u64 axi_addr,
resource_size_t window_size =
ob_map->window_sizes[size_idx] * SZ_1M;
 
-   if (size < window_size)
-   continue;
+   /*
+* Keep iterating until we reach the last window and
+* with the minimal window size at index zero. In this
+* case, we take a compromise by mapping it using the
+* minimum window size that can be supported
+*/
+   if (size < window_size) {
+   if (size_idx > 0 || window_idx > 0)
+   continue;
+
+   /*
+* For the corner case of reaching the minimal
+* window size that can be supported on the
+* last window
+*/
+   axi_addr = ALIGN_DOWN(axi_addr, window_size);
+   pci_addr = ALIGN_DOWN(pci_addr, window_size);
+   size = window_size;
+   }
 
if (!IS_ALIGNED(axi_addr, window_size) ||
!IS_ALIGNED(pci_addr, window_size)) {
-- 
2.7.4



[PATCH 1/3] PCI: iproc: Add feature to set order mode

2019-01-17 Thread Srinath Mannam
Order mode in RX header of incoming pcie packets can be override to
strict or loose order based on requirement.
Sysfs entry is provided to set dynamic and default order modes of upstream
traffic.

To improve performance in few endpoints we required to modify the
ordering attributes. Using this feature we can override order modes of RX
packets at IPROC RC.

Ex:
In PCIe based NVMe SSD endpoints data read/writes from disk is using
Queue pairs (submit/completion). After completion of block read/write,
EP writes completion command to completion queue to notify RC.
So that all data transfers before completion command write are not
required to strict order except completion command. It means previous all
packets before completion command write to RC should be written to memory
and acknowledged.

Signed-off-by: Srinath Mannam 
Reviewed-by: Ray Jui 
---
 drivers/pci/controller/pcie-iproc.c | 128 
 drivers/pci/controller/pcie-iproc.h |  16 +
 2 files changed, 144 insertions(+)

diff --git a/drivers/pci/controller/pcie-iproc.c 
b/drivers/pci/controller/pcie-iproc.c
index c20fd6b..13ce80f 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -57,6 +57,9 @@
 #define PCIE_DL_ACTIVE_SHIFT   2
 #define PCIE_DL_ACTIVE BIT(PCIE_DL_ACTIVE_SHIFT)
 
+#define MPS_MRRS_CFG_MPS_SHIFT 0
+#define MPS_MRRS_CFG_MRRS_SHIFT16
+
 #define APB_ERR_EN_SHIFT   0
 #define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
 
@@ -91,6 +94,14 @@
 
 #define IPROC_PCIE_REG_INVALID 0x
 
+#define RO_FIELD(window)   BIT((window) << 1)
+#define RO_VALUE(window)   BIT(((window) << 1) + 1)
+/* All Windows are allowed */
+#define RO_ALL_WINDOW  0x
+/* Wait on All Windows */
+#define RO_FIELD_ALL_WINDOW0x
+#define DYNAMIC_ORDER_MODE 0x5
+
 /**
  * iProc PCIe outbound mapping controller specific parameters
  *
@@ -295,6 +306,15 @@ enum iproc_pcie_reg {
/* enable APB error for unsupported requests */
IPROC_PCIE_APB_ERR_EN,
 
+   /* Ordering Mode configuration registers */
+   IPROC_PCIE_ORDERING_CFG,
+   IPROC_PCIE_MPS_MRRS_CFG,
+   IPROC_PCIE_IMAP0_RO_CONTROL,
+   IPROC_PCIE_IMAP1_RO_CONTROL,
+   IPROC_PCIE_IMAP2_RO_CONTROL,
+   IPROC_PCIE_IMAP3_RO_CONTROL,
+   IPROC_PCIE_IMAP4_RO_CONTROL,
+
/* total number of core registers */
IPROC_PCIE_MAX_NUM_REG,
 };
@@ -352,6 +372,13 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_IMAP4]  = 0xe70,
[IPROC_PCIE_LINK_STATUS]= 0xf0c,
[IPROC_PCIE_APB_ERR_EN] = 0xf40,
+   [IPROC_PCIE_ORDERING_CFG]   = 0x2000,
+   [IPROC_PCIE_MPS_MRRS_CFG]   = 0x2008,
+   [IPROC_PCIE_IMAP0_RO_CONTROL]   = 0x201c,
+   [IPROC_PCIE_IMAP1_RO_CONTROL]   = 0x2020,
+   [IPROC_PCIE_IMAP2_RO_CONTROL]   = 0x2024,
+   [IPROC_PCIE_IMAP3_RO_CONTROL]   = 0x2028,
+   [IPROC_PCIE_IMAP4_RO_CONTROL]   = 0x202c,
 };
 
 /* iProc PCIe PAXC v1 registers */
@@ -1401,6 +1428,97 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
return 0;
 }
 
+static
+ssize_t order_mode_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buff)
+{
+   struct pci_host_bridge *host = to_pci_host_bridge(dev);
+   struct iproc_pcie *pcie = pci_host_bridge_priv(host);
+
+   return sprintf(buff, "Current PAXB order configuration %d\n",
+  pcie->order_cfg);
+}
+
+static void pcie_iproc_set_dynamic_order(struct iproc_pcie *pcie)
+{
+   u32 val = 0, mps;
+
+   /* Set all IMAPs to relaxed order in dynamic order mode */
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_ORDERING_CFG,
+DYNAMIC_ORDER_MODE);
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_IMAP0_RO_CONTROL,
+RO_ALL_WINDOW);
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_IMAP1_RO_CONTROL,
+RO_ALL_WINDOW);
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_IMAP2_RO_CONTROL,
+RO_ALL_WINDOW);
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_IMAP3_RO_CONTROL,
+RO_ALL_WINDOW);
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_IMAP4_RO_CONTROL,
+RO_ALL_WINDOW);
+
+   /* PAXB MPS/MRRS settings configuration */
+   iproc_pci_raw_config_read32(pcie, 0, IPROC_PCI_EXP_CAP + PCI_EXP_DEVCTL,
+   2, &mps);
+   mps = (mps & PCI_EXP_DEVCTL_PAYLOAD) >> 5;
+   /* set MRRS to match system MPS */
+   val |= (mps << MPS_MRRS_CFG_MRRS_SHIFT);
+   /* set MPS to 4096 bytes */
+   val |= (0x5 << MPS_MRRS_CFG_MPS_SHIFT);
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_MPS_MRRS_CFG, val);
+}
+
+static
+ssize_t order_mode_store(struct device *dev,
+   

[PATCH 2/3] PCI: iproc: CRS state check in config request

2019-01-17 Thread Srinath Mannam
In the current implementation, config read of 0x0001 data
is assumed as CRS completion. but sometimes 0x0001 can be
a valid data.
IPROC PCIe RC has a register to show config request status flags
like SC, UR, CRS and CA.
So that extra check is added in the code to confirm the CRS
state using this register before reissue config request.

Signed-off-by: Srinath Mannam 
Reviewed-by: Ray Jui 
---
 drivers/pci/controller/pcie-iproc.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/pcie-iproc.c 
b/drivers/pci/controller/pcie-iproc.c
index 13ce80f..ee89d56 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -63,6 +63,10 @@
 #define APB_ERR_EN_SHIFT   0
 #define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
 
+#define CFG_RD_SUCCESS 0
+#define CFG_RD_UR  1
+#define CFG_RD_CRS 2
+#define CFG_RD_CA  3
 #define CFG_RETRY_STATUS   0x0001
 #define CFG_RETRY_STATUS_TIMEOUT_US50 /* 500 milliseconds */
 
@@ -300,6 +304,9 @@ enum iproc_pcie_reg {
IPROC_PCIE_IARR4,
IPROC_PCIE_IMAP4,
 
+   /* config read status */
+   IPROC_PCIE_CFG_RD_STATUS,
+
/* link status */
IPROC_PCIE_LINK_STATUS,
 
@@ -370,6 +377,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_IMAP3]  = 0xe08,
[IPROC_PCIE_IARR4]  = 0xe68,
[IPROC_PCIE_IMAP4]  = 0xe70,
+   [IPROC_PCIE_CFG_RD_STATUS]  = 0xee0,
[IPROC_PCIE_LINK_STATUS]= 0xf0c,
[IPROC_PCIE_APB_ERR_EN] = 0xf40,
[IPROC_PCIE_ORDERING_CFG]   = 0x2000,
@@ -501,10 +509,12 @@ static void __iomem *iproc_pcie_map_ep_cfg_reg(struct 
iproc_pcie *pcie,
return (pcie->base + offset);
 }
 
-static unsigned int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+static unsigned int iproc_pcie_cfg_retry(struct iproc_pcie *pcie,
+void __iomem *cfg_data_p)
 {
int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
unsigned int data;
+   u32 status;
 
/*
 * As per PCIe spec r3.1, sec 2.3.2, CRS Software Visibility only
@@ -525,6 +535,15 @@ static unsigned int iproc_pcie_cfg_retry(void __iomem 
*cfg_data_p)
 */
data = readl(cfg_data_p);
while (data == CFG_RETRY_STATUS && timeout--) {
+   /*
+* CRS state is set in CFG_RD status register
+* This will handle the case where CFG_RETRY_STATUS is
+* valid config data.
+*/
+   status = iproc_pcie_read_reg(pcie, IPROC_PCIE_CFG_RD_STATUS);
+   if (status != CFG_RD_CRS)
+   return data;
+
udelay(1);
data = readl(cfg_data_p);
}
@@ -603,7 +622,7 @@ static int iproc_pcie_config_read(struct pci_bus *bus, 
unsigned int devfn,
if (!cfg_data_p)
return PCIBIOS_DEVICE_NOT_FOUND;
 
-   data = iproc_pcie_cfg_retry(cfg_data_p);
+   data = iproc_pcie_cfg_retry(pcie, cfg_data_p);
 
*val = data;
if (size <= 2)
-- 
2.7.4



[PATCH 0/3] Add IPROC PCIe new features

2019-01-17 Thread Srinath Mannam
Add changes related to IPROC PCIe RC IP new features.

This patch set is based on Linux-5.0-rc2.

Srinath Mannam (3):
  PCI: iproc: Add feature to set order mode
  PCI: iproc: CRS state check in config request
  PCI: iproc: Add PCIe 32bit outbound memory configuration

 drivers/pci/controller/pcie-iproc.c | 172 +++-
 drivers/pci/controller/pcie-iproc.h |  16 
 2 files changed, 184 insertions(+), 4 deletions(-)

-- 
2.7.4



Re: [patch 1/9] block: Cleanup license notice

2019-01-17 Thread Jens Axboe
On 1/17/19 4:14 PM, Thomas Gleixner wrote:
> Remove the imprecise and sloppy:
> 
>   "This files is licensed under the GPL."
> 
> license notice in the top level comment.
> 
> 1) The file already contains a SPDX license identifier which clearly
>states that the license of the file is GPL V2 only
> 
> 2) The notice resolves to GPL v1 or later for scanners which is just
>contrary to the intent of SPDX identifiers to provide clear and non
>ambiguous license information. Aside of that the value add of this
>notice is below zero,

Applied, thanks Thomas.

-- 
Jens Axboe



Re: [PATCH] dt-bindings: aspeed-lpc: Make parameter optional

2019-01-17 Thread Andrew Jeffery
Hi Vijay,

On Fri, 18 Jan 2019, at 05:38, Vijay Khemka wrote:
> Memory-region and flash phandle is not a required parameter, it is
> optional to describe in device tree and needed only use basis.
> 
> Signed-off-by: Vijay Khemka 
> ---
>  Documentation/devicetree/bindings/mfd/aspeed-lpc.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/
> Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> index 34dd89087cff..ff0cb28903dd 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -135,6 +135,10 @@ Required properties:
>  - clocks:contains a phandle to the syscon node describing the clocks.
>   There should then be one cell representing the clock to use
>  
> +Optional properties:
> +These below properties are optional and required only if one need to use it
> +through ioctl.

I'd just say "Optional properties". Leave the description off, as we probably
shouldn't be talking about ioctls and such in the bindings.

Andrew

> +
>  - memory-region: A phandle to a reserved_memory region to be used for the LPC
>   to AHB mapping
>  
> -- 
> 2.17.1
> 


[PATCH v2] virtio_net: bulk free tx skbs

2019-01-17 Thread Michael S. Tsirkin
Use napi_consume_skb() to get bulk free.  Note that napi_consume_skb is
safe to call in a non-napi context as long as the napi_budget flag is
correct.

Signed-off-by: Michael S. Tsirkin 
---

Changes from v1:
rebase on master.

lightly tested on developer's box.

 drivers/net/virtio_net.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 023725086046..8fadd8eaf601 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1330,7 +1330,7 @@ static int virtnet_receive(struct receive_queue *rq, int 
budget,
return stats.packets;
 }
 
-static void free_old_xmit_skbs(struct send_queue *sq)
+static void free_old_xmit_skbs(struct send_queue *sq, bool in_napi)
 {
struct sk_buff *skb;
unsigned int len;
@@ -1343,7 +1343,7 @@ static void free_old_xmit_skbs(struct send_queue *sq)
bytes += skb->len;
packets++;
 
-   dev_consume_skb_any(skb);
+   napi_consume_skb(skb, in_napi);
}
 
/* Avoid overhead when no packets have been processed
@@ -1369,7 +1369,7 @@ static void virtnet_poll_cleantx(struct receive_queue *rq)
return;
 
if (__netif_tx_trylock(txq)) {
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, true);
__netif_tx_unlock(txq);
}
 
@@ -1445,7 +1445,7 @@ static int virtnet_poll_tx(struct napi_struct *napi, int 
budget)
struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
 
__netif_tx_lock(txq, raw_smp_processor_id());
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, true);
__netif_tx_unlock(txq);
 
virtqueue_napi_complete(napi, sq->vq, 0);
@@ -1514,7 +1514,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct 
net_device *dev)
bool use_napi = sq->napi.weight;
 
/* Free up any pending old buffers before queueing new ones. */
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, false);
 
if (use_napi && kick)
virtqueue_enable_cb_delayed(sq->vq);
@@ -1557,7 +1557,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct 
net_device *dev)
if (!use_napi &&
unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
/* More just got used, free them then recheck. */
-   free_old_xmit_skbs(sq);
+   free_old_xmit_skbs(sq, false);
if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
netif_start_subqueue(dev, qnum);
virtqueue_disable_cb(sq->vq);
-- 
MST


Re: [PATCH 00/12] selftests: Miscellaneous fixes

2019-01-17 Thread Masahiro Yamada
On Mon, Jan 14, 2019 at 10:52 PM Geert Uytterhoeven
 wrote:
>
> Hi all,
>
> This patch series contains several build fixes and cleanups for issues I
> encountered when trying to cross-build an rtctest binary in a separate
> output directory (like I use for all my kernel builds).

Geert,
Thanks for working on this!


My fundamental question is,
why did tools/ opt out Kbuild?

I think lots of mess comes in
in order to support
  cd tools/gpio; make

instead of

  make tools/gpio/


Lots of files are duplicated in tools/build/
in order to invent a different build system for tools/


Similar, but not exactly the same files. For example,

diff -u scripts/basic/fixdep.c tools/build/fixdep.c




> Most patches are independent. Exceptions are:
>   - Patch 3 depends on patch 2,
>   - Patch 7 depends on patch 6,
>   - Patch 11 depends on patches 2 and 3,
>
> This has been tested with native (amd64):
>   - make kselftest-build
>   - make -C tools/testing/selftests
>   - make O=/tmp/kselftest kselftest-build
>   - make O=/tmp/kselftest -C tools/testing/selftests
> and cross-builds (arm):
>   - make kselftest-build (from a separate output directory).
>
> Known remaining issues (not introduced by this patch series):
>   - tools/lib/bpf fails to build in some cases (cfr.
> 
> https://lore.kernel.org/lkml/CAMuHMdXRN=msktjznbsxqi-pkgsrkqeanxd-gb+hqc8pdjx...@mail.gmail.com/),
>   - tools/gpio is not always built correctly,
>   - When building in a separate output directory, there are still files
> created in the source directory under:
> - arch/x86/include/generated/,
> - arch/x86/tools/,
> - include/generated/uapi/linux,
> - scripts (fixdep and unifdef),
>   - Some tests may fail to find the installed header files,
>   - There may be^H^H^H^H^H^Hare more.
>
> Thanks for your comments!
>
> Geert Uytterhoeven (12):
>   selftests: gpio-mockup-chardev: Check asprintf() for error
>   selftests: Fix output directory with O=
>   selftests: Fix header install directory with O=
>   selftests: android: ion: Fix ionmap_test dependencies
>   selftests: seccomp: Fix test dependencies and rules
>   selftests: lib.mk: Add rule to build object file from C source file
>   selftests: memfd: Fix build with O=
>   selftests: timestamping: Remove superfluous rules
>   selftests: sparc64: Remove superfluous rules
>   selftests: intel_pstate: Remove unused header dependency rule
>   selftests: Add kselftest-build target
>   [RFC] selftests: gpio: Fix building tools/gpio from kselftests
>
>  Documentation/dev-tools/kselftest.rst |  4 
>  Makefile  |  9 +++--
>  tools/testing/selftests/android/ion/Makefile  |  6 +-
>  tools/testing/selftests/gpio/Makefile | 12 +++-
>  .../testing/selftests/gpio/gpio-mockup-chardev.c  |  9 ++---
>  tools/testing/selftests/intel_pstate/Makefile |  2 --
>  tools/testing/selftests/lib.mk|  4 
>  tools/testing/selftests/memfd/Makefile|  8 +++-
>  .../selftests/networking/timestamping/Makefile|  5 -
>  tools/testing/selftests/seccomp/Makefile  | 15 +++
>  tools/testing/selftests/sparc64/drivers/Makefile  |  4 
>  11 files changed, 35 insertions(+), 43 deletions(-)
>
> --
> 2.17.1
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds



-- 
Best Regards
Masahiro Yamada


[PATCH] kbuild: remove meaningless prepare2 target

2019-01-17 Thread Masahiro Yamada
There is no build order among the following:
  prepare3
  outputmakefile
  asm-generic
  $(version_h)
  $(autoksyms_h)
  include/generated/utsrelease.h

It is meaningless to insert the prepare2 target between the first
three and the last three.

The comment says, "prepare2 creates a makefile if using a separate
output directory." Let me explain it more precisely. The prepare
targets cannot be executed without the .config file. Because the
configuration targets depend on the outputmakefile target, the
generated makefile is already there before the parepare2 is run.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index 9851a44..cddcdb8 100644
--- a/Makefile
+++ b/Makefile
@@ -1062,7 +1062,7 @@ scripts: scripts_basic scripts_dtc
 # archprepare is used in arch Makefiles and when processed asm symlink,
 # version.h and scripts_basic is processed / created.
 
-PHONY += prepare archprepare prepare1 prepare2 prepare3
+PHONY += prepare archprepare prepare1 prepare3
 
 # prepare3 is used to check if we are building in a separate output directory,
 # and if so do:
@@ -1077,12 +1077,8 @@ ifneq ($(KBUILD_SRC),)
fi;
 endif
 
-# prepare2 creates a makefile if using a separate output directory.
-# From this point forward, .config has been reprocessed, so any rules
-# that need to depend on updated CONFIG_* values can be checked here.
-prepare2: prepare3 outputmakefile asm-generic
-
-prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h
+prepare1: prepare3 outputmakefile asm-generic $(version_h) $(autoksyms_h) \
+   include/generated/utsrelease.h
$(cmd_crmodverdir)
 
 archprepare: archheaders archscripts prepare1 scripts
-- 
2.7.4



Re: [PATCH] wireless: remove unneeded semicolon

2019-01-17 Thread Pkshih
On Fri, 2019-01-18 at 11:32 +0800, YueHaibing wrote:
> remove unneeded semicolon
> 
> Signed-off-by: YueHaibing 
> ---
>  drivers/net/wireless/ath/ath10k/wmi.h | 2 +-
>  drivers/net/wireless/ath/ath6kl/init.c| 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +-
>  drivers/net/wireless/ray_cs.c | 2 +-
>  drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c  | 6 +++---

For rtlwifi driver,
Acked-by: Ping-Ke Shih 



[GIT PULL] Please pull RDMA subsystem changes

2019-01-17 Thread Jason Gunthorpe
Hi Linus,

Just a small batch of patches for -rc today. Thanks

The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:

  Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus

for you to fetch changes up to d6f4a21f309dfe10a5693ad236358dd6fcc46f7a:

  RDMA/uverbs: Mark ioctl responses with UVERBS_ATTR_F_VALID_OUTPUT (2019-01-14 
14:02:22 -0700)


First 5.0 rc pull request

Not much so far, but I'm feeling like the 2nd PR -rc will be larger than
this. We have the usual batch of bugs and two fixes to code merged this cycle.

- Restore valgrind support for the ioctl verbs interface merged this window,
  and fix a missed error code on an error path from that conversion

- A user reported crash on obsolete mthca hardware

- pvrdma was using the wrong command opcode toward the hypervisor

- NULL pointer crash regression when dumping rdma-cm over netlink

- Be conservative about exposing the global rkey


Adit Ranadive (1):
  RDMA/vmw_pvrdma: Return the correct opcode when creating WR

Gal Pressman (1):
  RDMA/uverbs: Fix post send success return value in case of error

Jason Gunthorpe (1):
  RDMA/uverbs: Mark ioctl responses with UVERBS_ATTR_F_VALID_OUTPUT

Leon Romanovsky (2):
  RDMA/nldev: Don't expose unsafe global rkey to regular user
  RDMA/mthca: Clear QP objects during their allocation

Steve Wise (1):
  RDMA/cma: Add cm_id restrack resource based on kernel or user cm_id type

 drivers/infiniband/core/cma.c|  5 ++-
 drivers/infiniband/core/nldev.c  |  4 --
 drivers/infiniband/core/rdma_core.h  |  2 +
 drivers/infiniband/core/uverbs_cmd.c | 11 -
 drivers/infiniband/core/uverbs_ioctl.c   | 62 ++--
 drivers/infiniband/core/uverbs_main.c|  1 +
 drivers/infiniband/hw/mthca/mthca_provider.c |  4 +-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h| 35 +++-
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c |  6 +++
 include/uapi/rdma/vmw_pvrdma-abi.h   |  1 +
 10 files changed, 109 insertions(+), 22 deletions(-)


signature.asc
Description: PGP signature


Re: [PATCHv2] watchdog: qcom: Add suspend/resume support

2019-01-17 Thread Guenter Roeck

On 1/17/19 6:58 PM, Sai Prakash Ranjan wrote:

On 1/17/2019 11:46 PM, Guenter Roeck wrote:

On Thu, Jan 17, 2019 at 08:49:42PM +0530, Sai Prakash Ranjan wrote:

This adds the support for qcom watchdog suspend and resume
when entering and exiting deep sleep states. Otherwise
having watchdog active after suspend would result in unwanted
crashes/resets if resume happens after a long time.

Signed-off-by: Sai Prakash Ranjan 


Reviewed-by: Guenter Roeck 



Thanks Guenter. Should I send a v3 with your reviewed-by?



I add it to my watchdog-next branch and Wim will pick it up from there.
No need to resend.

Guenter


Re: [PATCH v11 0/9] Add power domain driver for corners on msm8996/sdm845

2019-01-17 Thread Rajendra Nayak




On 1/17/2019 8:33 PM, Marc Gonzalez wrote:

On 10/01/2019 05:02, Rajendra Nayak wrote:


Rajendra Nayak (9):
   dt-bindings: opp: Introduce opp-level bindings
   OPP: Add support for parsing the 'opp-level' property
   dt-bindings: power: Add qcom rpm power domain driver bindings
   soc: qcom: rpmpd: Add a Power domain driver to model corners
   soc: qcom: rpmpd: Add support for get/set performance state
   arm64: dts: msm8996: Add rpmpd device node
   soc: qcom: rpmhpd: Add RPMh power domain driver
   arm64: dts: sdm845: Add rpmh powercontroller node
   soc: qcom: rpmhpd: Mark mx as a parent for cx

  Documentation/devicetree/bindings/opp/opp.txt |   3 +
  .../devicetree/bindings/power/qcom,rpmpd.txt  | 145 +++
  arch/arm64/boot/dts/qcom/msm8996.dtsi |  34 ++
  arch/arm64/boot/dts/qcom/sdm845.dtsi  |  51 +++


Whenever I see these patches adding support for msm8996 (aka sdm820) and sdm845
simultaneously, I think to myself: "Why is sdm835 being left out? It was 
released
between sdm820 and sdm845, it cannot be /that/ different."


It isn't that different, and it should be quite straight forward to add support 
for it
with the rpmpd driver (the rpmhpd is for platforms sdm845 and beyond which use 
rpmh)

When I started working on these patches, support for sdm835 upstream was 
non-existent
so I started off with what was the better supported one which was the 820 
(msm8996).

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


Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

2019-01-17 Thread Dave Young
Pingfan, thanks for the post.

On 01/15/19 at 04:07pm, Pingfan Liu wrote:
> People reported a bug on a high end server with many pcie devices, where
> kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> though we still see much memory under 896 MB, the finding still failed
> intermittently. Because currently we can only find region under 896 MB,
> if without ',high' specified. Then KASLR breaks 896 MB into several parts
> randomly, and crashkernel reservation need be aligned to 128 MB, that's
> why failure is found. It raises confusion to the end user that sometimes
> crashkernel=X works while sometimes fails.
> If want to make it succeed, customer can change kernel option to
> "crashkernel=384M,high". Just this give "crashkernel=xx@yy" a very
> limited space to behave even though its grammar looks more generic.
> And we can't answer questions raised from customer that confidently:
> 1) why it doesn't succeed to reserve 896 MB;
> 2) what's wrong with memory region under 4G;
> 3) why I have to add ',high', I only require 384 MB, not 3840 MB.
> This patch tries to get memory region from 896 MB firstly, then [896MB,4G],
> finally above 4G.

The patch log still looks not very good.  It needs some cleanup like
paragraph line breaks to make it more readable.

For example you can take like below:
--
People reported crashkernel=384M reservation failed on a high end server
with KASLR enabled.  In that case there is enough free memory under 896M
but crashkernel reservation still fails intermittently.

The situation is crashkernel reservation code only finds free region under
896 MB with 128M aligned in case no ',high' being used.  And KASLR could
break the first 896M into several parts randomly thus the failure happens.
User has no way to predict and make sure crashkernel=xM working unless
he/she use 'crashkernel=xM,high'.  Since 'crashkernel=xM' is the most
common use case this issue is a serious bug.

And we can't answer questions raised from customer:
1) why it doesn't succeed to reserve 896 MB;
2) what's wrong with memory region under 4G;
3) why I have to add ',high', I only require 384 MB, not 3840 MB.

This patch tries to get memory region from 896 MB firstly, then [896MB,4G],
finally above 4G.

> Dave Young sent the original post, and I just re-post it with commit log
> improvement as his requirement.
> http://lists.infradead.org/pipermail/kexec/2017-October/019571.html
> There was an old discussion below (previously posted by Chao Wang):
> https://lkml.org/lkml/2013/10/15/601

I hope someone else can provide review because I posted it previously.

But I think previously when I posted it is a good to have improvement,
but now it is a real serious bug which need to be fixed.  I can review
and ack if you can repost with a better log.

> 
> Signed-off-by: Pingfan Liu 
> Cc: Dave Young 
> Cc: Baoquan He 
> Cc: Andrew Morton 
> Cc: Mike Rapoport 
> Cc: ying...@kernel.org,
> Cc: vgo...@redhat.com
> Cc: Randy Dunlap 
> ---
> v6 -> v7: fix spelling mistake pointed out by Randy
>  arch/x86/kernel/setup.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 3d872a5..fa62c81 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -551,6 +551,22 @@ static void __init reserve_crashkernel(void)
>   high ? CRASH_ADDR_HIGH_MAX
>: CRASH_ADDR_LOW_MAX,
>   crash_size, CRASH_ALIGN);
> +#ifdef CONFIG_X86_64
> + /*
> +  * crashkernel=X reserve below 896M fails? Try below 4G
> +  */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + (1ULL << 32),
> + crash_size, CRASH_ALIGN);
> + /*
> +  * crashkernel=X reserve below 4G fails? Try MAXMEM
> +  */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + CRASH_ADDR_HIGH_MAX,
> + crash_size, CRASH_ALIGN);
> +#endif
>   if (!crash_base) {
>   pr_info("crashkernel reservation failed - No suitable 
> area found.\n");
>   return;
> -- 
> 2.7.4
> 

Thanks
Dave


[PATCH]spi: pl022: add a message state STATE_TIMEOUT for timeout transfer

2019-01-17 Thread Jiwei Sun
When transfer timeout, give -EAGAIN to the message's status, and it can
make the spi device driver choose repeated transimation or not. And if
transfer timeout, output some useful information for tracing the issue.

Signed-off-by: Jiwei Sun 
---
 drivers/spi/spi-pl022.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 0c793e31d60f..26684178786f 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -253,6 +253,7 @@
 #define STATE_RUNNING  ((void *) 1)
 #define STATE_DONE ((void *) 2)
 #define STATE_ERROR((void *) -1)
+#define STATE_TIMEOUT  ((void *) -2)
 
 /*
  * SSP State - Whether Enabled or Disabled
@@ -1484,6 +1485,30 @@ static void do_interrupt_dma_transfer(struct pl022 
*pl022)
writew(irqflags, SSP_IMSC(pl022->virtbase));
 }
 
+static void print_current_status(struct pl022 *pl022)
+{
+   u32 read_cr0;
+   u16 read_cr1, read_dmacr, read_sr;
+
+   if (pl022->vendor->extended_cr)
+   read_cr0 = readl(SSP_CR0(pl022->virtbase));
+   else
+   read_cr0 = readw(SSP_CR0(pl022->virtbase));
+   read_cr1 = readw(SSP_CR1(pl022->virtbase));
+   read_dmacr = readw(SSP_DMACR(pl022->virtbase));
+   read_sr = readw(SSP_SR(pl022->virtbase));
+
+   dev_warn(&pl022->adev->dev, "spi-pl022 CR0: %x\n", read_cr0);
+   dev_warn(&pl022->adev->dev, "spi-pl022 CR1: %x\n", read_cr1);
+   dev_warn(&pl022->adev->dev, "spi-pl022 DMACR: %x\n", read_dmacr);
+   dev_warn(&pl022->adev->dev, "spi-pl022 SR: %x\n", read_sr);
+   dev_warn(&pl022->adev->dev,
+   "spi-pl022 exp_fifo_level/fifodepth: %u/%d\n",
+   pl022->exp_fifo_level,
+   pl022->vendor->fifodepth);
+
+}
+
 static void do_polling_transfer(struct pl022 *pl022)
 {
struct spi_message *message = NULL;
@@ -1535,7 +1560,8 @@ static void do_polling_transfer(struct pl022 *pl022)
if (time_after(time, timeout)) {
dev_warn(&pl022->adev->dev,
"%s: timeout!\n", __func__);
-   message->state = STATE_ERROR;
+   message->state = STATE_TIMEOUT;
+   print_current_status(pl022);
goto out;
}
cpu_relax();
@@ -1553,6 +1579,8 @@ static void do_polling_transfer(struct pl022 *pl022)
/* Handle end of message */
if (message->state == STATE_DONE)
message->status = 0;
+   else if (message->state == STATE_TIMEOUT)
+   message->status = -EAGAIN;
else
message->status = -EIO;
 
-- 
2.20.1



  1   2   3   4   5   6   7   8   9   10   >