Re: [PATCH 00/12] selftests: Miscellaneous fixes
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
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
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
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(>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(>lock, flags);
}
@@ -60,9 +60,9 @@ static void imx_irqsteer_irq_mask(struct irq_data *d)
u32 val;
raw_spin_lock_irqsave(>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(>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, , 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(>lock);
- of_property_read_u32(np, "fsl,irq-groups", >irq_groups);
+ of_property_read_u32(np, "fsl,chan-irq-number", >reg_num);
of_property_read_u32(np, "fsl,channel", >channel);
+ /* one register bit map represents 32 input interrupts */
+ data->reg_num /= 32;
+
if (IS_ENABLED(CONFIG_PM_SLEEP)) {
data->saved_reg = devm_kzalloc(>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,
_irqsteer_domain_ops, data);
if (!data->domain) {
dev_err(>dev, "failed to create IRQ domain\n");
@@ -199,9 +202,9 @@ static void
[PATCH 1/4] dt-binding: irq: imx-irqsteer: use irq number per channel instead of group number
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 = < 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
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
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
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
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(>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(>dev, "failed to get irq\n");
- return -ENODEV;
- }
-
data->ipg_clk = devm_clk_get(>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
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
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
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
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, _phys, GFP_KERNEL);
> + buf_virt = dma_alloc_coherent(sdma->dev, size, _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(>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, >bd0_phys,
> + sdma->bd0 = dma_zalloc_coherent(sdma->dev, PAGE_SIZE,
> >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, >bd_phys,
> - GFP_NOWAIT);
> + desc->bd = dma_zalloc_coherent(desc->sdmac->sdma->dev, bd_size,
> +>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),
> _phys, GFP_KERNEL);
> --
> 2.17.1
[PATCH 1/1] irqchip: gpcv2: make config option visible
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
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
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()
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
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
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(_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
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
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_MOD 917>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 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()
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
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(_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(_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, _tlb_nslabs);
+ if (!ent)
+ goto fail;
+
+ ent = debugfs_create_ulong("io_tlb_used", 0400,
+ d_swiotlb_usage, _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
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(_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
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 = >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
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
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
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(>pi_desc)) {
+ if (!bitmap_empty((unsigned long *)vmx->pi_desc.pir, NR_VECTORS)) {
pi_clear_on(>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
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
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(_device.ha_lock, flags);
list_for_each_entry(has, _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(_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(_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(_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 *valid_end);
extern
Re: [PATCH] irqchip/irq-csky-mpintc: Add triger type and priority setting
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 = <>;
> > + };
> > +
> > + 1: device-example {
> > + ...
> > + interrupts = <34 ((priority << 4) | IRQ_TYPE_EDGE_RISING)>;
> > + interrupt-parent = <>;
> > + };
> > 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 these magic
Re: [PATCH] mtd: rawnand: denali: get ->setup_data_interface() working again
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
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 = _controller_ops;
Re: [PATCH v3 4/4] usb: musb: Add support for MediaTek musb controller
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
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
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
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
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
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
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(_cbcmac_tmpl);
- if (err)
- goto out;
-
- err = crypto_register_template(_ccm_base_tmpl);
- if (err)
- goto out_undo_cbcmac;
-
- err = crypto_register_template(_ccm_tmpl);
- if (err)
- goto out_undo_base;
-
- err = crypto_register_template(_rfc4309_tmpl);
- if (err)
- goto out_undo_ccm;
-
-out:
- return err;
-
-out_undo_ccm:
- crypto_unregister_template(_ccm_tmpl);
-out_undo_base:
- crypto_unregister_template(_ccm_base_tmpl);
-out_undo_cbcmac:
- crypto_register_template(_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(_rfc4309_tmpl);
- crypto_unregister_template(_ccm_tmpl);
- crypto_unregister_template(_ccm_base_tmpl);
- crypto_unregister_template(_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
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([i]);
+ if (err)
+ goto out;
+ }
+ return 0;
+
+out:
+ for (--i; i >= 0; --i)
+ crypto_unregister_template([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([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
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(_zeroes->sg, gcm_zeroes->buf, sizeof(gcm_zeroes->buf));
- err = crypto_register_template(_gcm_base_tmpl);
- if (err)
- goto out;
-
- err = crypto_register_template(_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(_rfc4106_tmpl);
- if (err)
- goto out_undo_gcm;
-
- err = crypto_register_template(_rfc4543_tmpl);
- if (err)
- goto out_undo_rfc4106;
-
- return 0;
-
-out_undo_rfc4106:
- crypto_unregister_template(_rfc4106_tmpl);
-out_undo_gcm:
- crypto_unregister_template(_gcm_tmpl);
-out_undo_base:
- crypto_unregister_template(_gcm_base_tmpl);
-out:
- kfree(gcm_zeroes);
return err;
}
static void __exit crypto_gcm_module_exit(void)
{
kfree(gcm_zeroes);
- crypto_unregister_template(_rfc4543_tmpl);
- crypto_unregister_template(_rfc4106_tmpl);
- crypto_unregister_template(_gcm_tmpl);
- crypto_unregister_template(_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
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(_ctr_tmpl);
- if (err)
- goto out;
-
- err = crypto_register_template(_rfc3686_tmpl);
- if (err)
- goto out_drop_ctr;
-
-out:
- return err;
-
-out_drop_ctr:
- crypto_unregister_template(_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(_rfc3686_tmpl);
- crypto_unregister_template(_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
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(_tmpl);
- if (err)
- return err;
-
- err = crypto_register_template(_tmpl);
- if (err)
- crypto_unregister_template(_tmpl);
-
- return err;
+ return crypto_register_templates(rfc7539_tmpls,
+ARRAY_SIZE(rfc7539_tmpls));
}
static void __exit chacha20poly1305_module_exit(void)
{
- crypto_unregister_template(_tmpl);
- crypto_unregister_template(_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
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
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
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_MOD 917>;
+ power-domains = < R8A77995_PD_ALWAYS_ON>;
+ resets = < 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
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
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
Re: [PATCH] sb1000: fix a couple of indentation issues
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
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
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
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
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, >regs->site[data->sensor_id].tritsr);
+ val = tmu_read(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, _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(>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(
+ >dev, id, qdata->sensor[id], _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, >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, >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(>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(>dev, "Failed to get sensor id\n");
- ret = -ENODEV;
- goto err_iomap;
- }
-
[git pull] drm nouveau TU102 hw support
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
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
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
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
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
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
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 = _controller_ops;
--
2.7.4
Re: [PATCH v6] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
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
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=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
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
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
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
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.
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
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, , 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, );
> - 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, );
> + 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();
> @@ -214,22 +230,22 @@ static int aspeed_lpc_ctrl_probe(struct
> platform_device *pdev)
>
> dev_set_drvdata(>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, );
> + of_node_put(node);
> + if (rc) {
> + dev_err(dev, "Couldn't address to resource for reserved
> memory\n");
> + return -ENOMEM;
Wow, I think this is an abuse
[RFC PATCH] ALSA: core: Add DMA share buffer support
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
+++
Re: [PATCH 3/4] crypto: hisilicon: Add HiSilicon ZIP accelerator support
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
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
[].. 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
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
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, _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, _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,
> _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
_test_objects[i].list_node.rhead));
567 if (err == -EAGAIN)
568 err = 0;
569 } else
570 err = rhltable_insert(rhlt,
571
_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
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, _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();
> > > }
> > >
> > > + 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
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
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
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
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'
+ 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
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
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
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
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 Linux 5.0-rc2) Merging usb-gadget-fixes/fixes (87b6d2c56825 usb: dwc2: gadget: Fix Remote
[PATCH 3/3] PCI: iproc: Add PCIe 32bit outbound memory configuration
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
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 & 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
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
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
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
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
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
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
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
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
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
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
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
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
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(>adev->dev, "spi-pl022 CR0: %x\n", read_cr0);
+ dev_warn(>adev->dev, "spi-pl022 CR1: %x\n", read_cr1);
+ dev_warn(>adev->dev, "spi-pl022 DMACR: %x\n", read_dmacr);
+ dev_warn(>adev->dev, "spi-pl022 SR: %x\n", read_sr);
+ dev_warn(>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(>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
