Re: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller devicetree binding information
On Fri, 8 Jun 2018 05:20:33 +
Naga Sureshkumar Relli wrote:
> Hi Miquel,
>
> Thanks for the review.
>
> > -Original Message-
> > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> > Sent: Thursday, June 7, 2018 9:12 PM
> > To: Naga Sureshkumar Relli
> > Cc: boris.brezil...@bootlin.com; rich...@nod.at; w...@infradead.org;
> > computersforpe...@gmail.com; marek.va...@gmail.com; f.faine...@gmail.com;
> > mma...@broadcom.com; rog...@ti.com; la...@linux-mips.org; a...@thorsis.com;
> > honghui.zh...@mediatek.com; linux-...@lists.infradead.org;
> > linux-kernel@vger.kernel.org;
> > nagasureshkumarre...@gmail.com
> > Subject: Re: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller
> > devicetree
> > binding information
> >
> > Hi Naga,
> >
> > On Wed, 6 Jun 2018 13:19:39 +0530, Naga Sureshkumar Relli
> > wrote:
> >
> > > Add pl353 static memory controller devicetree binding information.
> > >
> > > Signed-off-by: Naga Sureshkumar Relli
> > >
> > > ---
> > > Changes in v9:
> > > - Addressed commens given by Randy Dunlap and Miquel Raynal
> >
> > Can you please be more specific in your next changelog? I don't remember
> > what I suggested a
> > few months ago :)
> Ok, I will update.
>
> >
> > > Changes in v8:
> > > - None
> > > Changes in v7:
> > > - Corrected clocks description
> > > - prefixed '#' for address and size cells Changes in v6:
> > > - None
> > > Changes in v5:
> > > - Removed timing properties
> > > Changes in v4:
> > > - none
> > > Changes in v3:
> > > - none
> > > Changes in v2:
> > > - modified timing binding info as per onfi timing parameters
> > > - add suffix nano second as timing unit
> > > - modified the clock names as per the IP spec
> > > ---
> > > .../bindings/memory-controllers/pl353-smc.txt | 53
> > ++
> > > 1 file changed, 53 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > > b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > > new file mode 100644
> > > index 000..551e66b
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.t
> > > +++ xt
> > > @@ -0,0 +1,53 @@
> > > +Device tree bindings for ARM PL353 static memory controller
> > > +
> > > +PL353 static memory controller supports two kinds of memory
> > > +interfaces.i.e NAND and SRAM/NOR interfaces.
> > > +The actual devices are instantiated from the child nodes of pl353 smc
> > > node.
> > > +
> > > +Required properties:
> > > +- compatible : Should be "arm,pl353-smc-r2p1"
> >
> > I thing Rob prefers:
> >
> > - compatible: Must be one of:
> > * arm, pl353-smc-r2p1
> Are you suggesting any other compatibles?
> Or just a change from "should be to Must be one of"?
> >
> > > +- reg: Controller registers map and length.
> > > +- clock-names: List of input clock names - "ref_clk",
> > > "aper_clk"
> > > + (See clock bindings for details).
> > > +- clocks : Clock phandles (see clock bindings for details).
> > > +- address-cells : Address cells, must be 1.
> > > +- size-cells : Size cells. Must be 1.
> >
> > Please avoid padding, just this is enough:
> >
> > - something: And another thing.
> Ok, I will update it.
>
> >
> > > +
> > > +Child nodes:
> > > + For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash"
> > > +drivers are supported as child nodes.
> > > +
> > > +Mandatory timing properties for child nodes:
> > > +- arm,nand-cycle-t0 : Read cycle time(t_rc).
> > > +- arm,nand-cycle-t1 : Write cycle time(t_wc).
> > > +- arm,nand-cycle-t2 : re_n assertion delay(t_rea).
> > > +- arm,nand-cycle-t3 : we_n de-assertion delay(t_wp).
> > > +- arm,nand-cycle-t4 : Status read time(t_clr)
> > > +- arm,nand-cycle-t5 : ID read time(t_ar)
> > > +- arm,nand-cycle-t6 : busy to re_n(t_rr)
> >
> > I think this has nothing to do in the DT, you should handle timings from
> > the -
> > >setup_data_interface() hook. If you need, you may use different
> > >compatibles to distinguish
> > different platform data.
> >
> This controller is applicable only to Zynq platform. No other platform will
> use this.
> Basically pl353-smc.c and pl353-nand.c, both are different drivers.
> And this data_interface hook is in nand, and to set this timings if we read
> it from setup_data_interface(), then
> We need to make call from nand to smc driver.
> Let me try this.
>
> > > +
> > > +for nand partition information please refer the below file
> >
> > s/nand/NAND/
> I will update in next version.
>
> >
> > > +Documentation/devicetree/bindings/mtd/partition.txt
> > > +
> > > +Example:
> > > + pl353smcc_0: pl353smcc@e000e000 {
> >
> > Why not something more explicit with the
Re: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller devicetree binding information
On Fri, 8 Jun 2018 05:20:33 +
Naga Sureshkumar Relli wrote:
> Hi Miquel,
>
> Thanks for the review.
>
> > -Original Message-
> > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> > Sent: Thursday, June 7, 2018 9:12 PM
> > To: Naga Sureshkumar Relli
> > Cc: boris.brezil...@bootlin.com; rich...@nod.at; w...@infradead.org;
> > computersforpe...@gmail.com; marek.va...@gmail.com; f.faine...@gmail.com;
> > mma...@broadcom.com; rog...@ti.com; la...@linux-mips.org; a...@thorsis.com;
> > honghui.zh...@mediatek.com; linux-...@lists.infradead.org;
> > linux-kernel@vger.kernel.org;
> > nagasureshkumarre...@gmail.com
> > Subject: Re: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller
> > devicetree
> > binding information
> >
> > Hi Naga,
> >
> > On Wed, 6 Jun 2018 13:19:39 +0530, Naga Sureshkumar Relli
> > wrote:
> >
> > > Add pl353 static memory controller devicetree binding information.
> > >
> > > Signed-off-by: Naga Sureshkumar Relli
> > >
> > > ---
> > > Changes in v9:
> > > - Addressed commens given by Randy Dunlap and Miquel Raynal
> >
> > Can you please be more specific in your next changelog? I don't remember
> > what I suggested a
> > few months ago :)
> Ok, I will update.
>
> >
> > > Changes in v8:
> > > - None
> > > Changes in v7:
> > > - Corrected clocks description
> > > - prefixed '#' for address and size cells Changes in v6:
> > > - None
> > > Changes in v5:
> > > - Removed timing properties
> > > Changes in v4:
> > > - none
> > > Changes in v3:
> > > - none
> > > Changes in v2:
> > > - modified timing binding info as per onfi timing parameters
> > > - add suffix nano second as timing unit
> > > - modified the clock names as per the IP spec
> > > ---
> > > .../bindings/memory-controllers/pl353-smc.txt | 53
> > ++
> > > 1 file changed, 53 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > > b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > > new file mode 100644
> > > index 000..551e66b
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.t
> > > +++ xt
> > > @@ -0,0 +1,53 @@
> > > +Device tree bindings for ARM PL353 static memory controller
> > > +
> > > +PL353 static memory controller supports two kinds of memory
> > > +interfaces.i.e NAND and SRAM/NOR interfaces.
> > > +The actual devices are instantiated from the child nodes of pl353 smc
> > > node.
> > > +
> > > +Required properties:
> > > +- compatible : Should be "arm,pl353-smc-r2p1"
> >
> > I thing Rob prefers:
> >
> > - compatible: Must be one of:
> > * arm, pl353-smc-r2p1
> Are you suggesting any other compatibles?
> Or just a change from "should be to Must be one of"?
> >
> > > +- reg: Controller registers map and length.
> > > +- clock-names: List of input clock names - "ref_clk",
> > > "aper_clk"
> > > + (See clock bindings for details).
> > > +- clocks : Clock phandles (see clock bindings for details).
> > > +- address-cells : Address cells, must be 1.
> > > +- size-cells : Size cells. Must be 1.
> >
> > Please avoid padding, just this is enough:
> >
> > - something: And another thing.
> Ok, I will update it.
>
> >
> > > +
> > > +Child nodes:
> > > + For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash"
> > > +drivers are supported as child nodes.
> > > +
> > > +Mandatory timing properties for child nodes:
> > > +- arm,nand-cycle-t0 : Read cycle time(t_rc).
> > > +- arm,nand-cycle-t1 : Write cycle time(t_wc).
> > > +- arm,nand-cycle-t2 : re_n assertion delay(t_rea).
> > > +- arm,nand-cycle-t3 : we_n de-assertion delay(t_wp).
> > > +- arm,nand-cycle-t4 : Status read time(t_clr)
> > > +- arm,nand-cycle-t5 : ID read time(t_ar)
> > > +- arm,nand-cycle-t6 : busy to re_n(t_rr)
> >
> > I think this has nothing to do in the DT, you should handle timings from
> > the -
> > >setup_data_interface() hook. If you need, you may use different
> > >compatibles to distinguish
> > different platform data.
> >
> This controller is applicable only to Zynq platform. No other platform will
> use this.
> Basically pl353-smc.c and pl353-nand.c, both are different drivers.
> And this data_interface hook is in nand, and to set this timings if we read
> it from setup_data_interface(), then
> We need to make call from nand to smc driver.
> Let me try this.
>
> > > +
> > > +for nand partition information please refer the below file
> >
> > s/nand/NAND/
> I will update in next version.
>
> >
> > > +Documentation/devicetree/bindings/mtd/partition.txt
> > > +
> > > +Example:
> > > + pl353smcc_0: pl353smcc@e000e000 {
> >
> > Why not something more explicit with the
[PATCH v2 2/5] Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled during interrupt"
This reverts commit 2746e2c389f9d50043d21e2204270403efb9d62f.
Don't need this patch anymore,since we can easily check 'sdmac->desc' to avoid
handling dma interrupt after channel disabled if virt-dma used.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 8d0c1fd..d93b58f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -354,7 +354,6 @@ struct sdma_channel {
unsigned intchn_count;
unsigned intchn_real_count;
struct imx_dma_data data;
- boolenabled;
};
#define IMX_DMA_SG_LOOPBIT(0)
@@ -615,14 +614,7 @@ static int sdma_config_ownership(struct sdma_channel
*sdmac,
static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
{
- unsigned long flags;
- struct sdma_channel *sdmac = >channel[channel];
-
writel(BIT(channel), sdma->regs + SDMA_H_START);
-
- spin_lock_irqsave(>lock, flags);
- sdmac->enabled = true;
- spin_unlock_irqrestore(>lock, flags);
}
/*
@@ -740,14 +732,6 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
struct sdma_buffer_descriptor *bd;
int error = 0;
enum dma_status old_status = sdmac->status;
- unsigned long flags;
-
- spin_lock_irqsave(>lock, flags);
- if (!sdmac->enabled) {
- spin_unlock_irqrestore(>lock, flags);
- return;
- }
- spin_unlock_irqrestore(>lock, flags);
/*
* loop mode. Iterate over descriptors, re-setup them and
@@ -1008,15 +992,10 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
- unsigned long flags;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
- spin_lock_irqsave(>lock, flags);
- sdmac->enabled = false;
- spin_unlock_irqrestore(>lock, flags);
-
return 0;
}
--
2.7.4
[PATCH v2 2/5] Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled during interrupt"
This reverts commit 2746e2c389f9d50043d21e2204270403efb9d62f.
Don't need this patch anymore,since we can easily check 'sdmac->desc' to avoid
handling dma interrupt after channel disabled if virt-dma used.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 8d0c1fd..d93b58f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -354,7 +354,6 @@ struct sdma_channel {
unsigned intchn_count;
unsigned intchn_real_count;
struct imx_dma_data data;
- boolenabled;
};
#define IMX_DMA_SG_LOOPBIT(0)
@@ -615,14 +614,7 @@ static int sdma_config_ownership(struct sdma_channel
*sdmac,
static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
{
- unsigned long flags;
- struct sdma_channel *sdmac = >channel[channel];
-
writel(BIT(channel), sdma->regs + SDMA_H_START);
-
- spin_lock_irqsave(>lock, flags);
- sdmac->enabled = true;
- spin_unlock_irqrestore(>lock, flags);
}
/*
@@ -740,14 +732,6 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
struct sdma_buffer_descriptor *bd;
int error = 0;
enum dma_status old_status = sdmac->status;
- unsigned long flags;
-
- spin_lock_irqsave(>lock, flags);
- if (!sdmac->enabled) {
- spin_unlock_irqrestore(>lock, flags);
- return;
- }
- spin_unlock_irqrestore(>lock, flags);
/*
* loop mode. Iterate over descriptors, re-setup them and
@@ -1008,15 +992,10 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
- unsigned long flags;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
- spin_lock_irqsave(>lock, flags);
- sdmac->enabled = false;
- spin_unlock_irqrestore(>lock, flags);
-
return 0;
}
--
2.7.4
[PATCH v2 3/5] dmaengine: imx-sdma: remove usless lock
No need anymore for 'lock' now since virtual dma will provide
the common lock instead.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d93b58f..6faec89 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -349,7 +349,6 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- spinlock_t lock;
enum dma_status status;
unsigned intchn_count;
unsigned intchn_real_count;
@@ -1908,7 +1907,6 @@ static int sdma_probe(struct platform_device *pdev)
struct sdma_channel *sdmac = >channel[i];
sdmac->sdma = sdma;
- spin_lock_init(>lock);
sdmac->channel = i;
sdmac->vc.desc_free = sdma_desc_free;
--
2.7.4
[PATCH v2 5/5] dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
There are lot of codes overlap between prep_sg and prep_cyclic function.
Add sdma_transfer_init() function to elimated the code overlap.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 83 ++
1 file changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index afaee72..25de89e 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1255,6 +1255,40 @@ static void sdma_free_chan_resources(struct dma_chan
*chan)
clk_disable(sdma->clk_ahb);
}
+static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction, u32 bds)
+{
+ struct sdma_desc *desc;
+
+ desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ if (!desc)
+ goto err_out;
+
+ sdmac->status = DMA_IN_PROGRESS;
+ sdmac->direction = direction;
+ sdmac->flags = 0;
+
+ desc->chn_count = 0;
+ desc->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->sdmac = sdmac;
+ desc->num_bd = bds;
+
+ if (sdma_alloc_bd(desc))
+ goto err_desc_out;
+
+ if (sdma_load_context(sdmac))
+ goto err_desc_out;
+
+ return desc;
+
+err_desc_out:
+ kfree(desc);
+err_out:
+ return NULL;
+}
+
static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1267,36 +1301,13 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
struct scatterlist *sg;
struct sdma_desc *desc;
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- sdmac->flags = 0;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, sg_len);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = sg_len;
- desc->chn_real_count = 0;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
- sdmac->direction = direction;
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
-
- desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = >bd[i];
int param;
@@ -1372,38 +1383,18 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int ret, i = 0, buf = 0;
+ int i = 0, buf = 0;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, num_periods);
if (!desc)
goto err_out;
-
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = num_periods;
- desc->chn_real_count = 0;
desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
- sdmac->direction = direction;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
--
2.7.4
[PATCH v2 3/5] dmaengine: imx-sdma: remove usless lock
No need anymore for 'lock' now since virtual dma will provide
the common lock instead.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d93b58f..6faec89 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -349,7 +349,6 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- spinlock_t lock;
enum dma_status status;
unsigned intchn_count;
unsigned intchn_real_count;
@@ -1908,7 +1907,6 @@ static int sdma_probe(struct platform_device *pdev)
struct sdma_channel *sdmac = >channel[i];
sdmac->sdma = sdma;
- spin_lock_init(>lock);
sdmac->channel = i;
sdmac->vc.desc_free = sdma_desc_free;
--
2.7.4
[PATCH v2 5/5] dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
There are lot of codes overlap between prep_sg and prep_cyclic function.
Add sdma_transfer_init() function to elimated the code overlap.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 83 ++
1 file changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index afaee72..25de89e 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1255,6 +1255,40 @@ static void sdma_free_chan_resources(struct dma_chan
*chan)
clk_disable(sdma->clk_ahb);
}
+static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction, u32 bds)
+{
+ struct sdma_desc *desc;
+
+ desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ if (!desc)
+ goto err_out;
+
+ sdmac->status = DMA_IN_PROGRESS;
+ sdmac->direction = direction;
+ sdmac->flags = 0;
+
+ desc->chn_count = 0;
+ desc->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->sdmac = sdmac;
+ desc->num_bd = bds;
+
+ if (sdma_alloc_bd(desc))
+ goto err_desc_out;
+
+ if (sdma_load_context(sdmac))
+ goto err_desc_out;
+
+ return desc;
+
+err_desc_out:
+ kfree(desc);
+err_out:
+ return NULL;
+}
+
static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1267,36 +1301,13 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
struct scatterlist *sg;
struct sdma_desc *desc;
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- sdmac->flags = 0;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, sg_len);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = sg_len;
- desc->chn_real_count = 0;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
- sdmac->direction = direction;
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
-
- desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = >bd[i];
int param;
@@ -1372,38 +1383,18 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int ret, i = 0, buf = 0;
+ int i = 0, buf = 0;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, num_periods);
if (!desc)
goto err_out;
-
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = num_periods;
- desc->chn_real_count = 0;
desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
- sdmac->direction = direction;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
--
2.7.4
[PATCH v2 1/5] dmaengine: imx-sdma: add virt-dma support
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
The main changes as below:
--new "sdma_desc" structure containing virt_dma_desc and some members
which moved from "sdma_channel" such as "num_bd","bd_phys","bd",etc,
since multi descriptors may exist on virtual dma framework
rather than only one as before.
--remove some members of "sdma_channel" structure since it's handled
by virtual dma common framework, such as "tasklet", "dma_chan",etc.
--add specific BD0 for channel0 since such bd descriptor is must and
basic for other dma channel, no need alloc/free as other channel,so
request it during probe.
--remove sdma_request_channel(),sdma_tx_submit(),etc.
--alloc/free bd descriptor added and code changes for virtual dma.
Signed-off-by: Robin Gong
---
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 332 -
2 files changed, 220 insertions(+), 113 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index ca1680a..d4a4230 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -250,6 +250,7 @@ config IMX_SDMA
tristate "i.MX SDMA support"
depends on ARCH_MXC
select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
help
Support the i.MX SDMA engine. This engine is integrated into
Freescale i.MX25/31/35/51/53/6 chips.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccd03c3..8d0c1fd 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -48,6 +48,7 @@
#include
#include "dmaengine.h"
+#include "virt-dma.h"
/* SDMA registers */
#define SDMA_H_C0PTR 0x000
@@ -296,6 +297,31 @@ struct sdma_context_data {
struct sdma_engine;
/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ struct virt_dma_descvd;
+ unsigned intnum_bd;
+ dma_addr_t bd_phys;
+ unsigned intbuf_tail;
+ unsigned intbuf_ptail;
+ unsigned intperiod_len;
+ unsigned intchn_real_count;
+ unsigned intchn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
+/**
* struct sdma_channel - housekeeping for a SDMA channel
*
* @sdma pointer to the SDMA engine for this channel
@@ -305,11 +331,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct virt_dma_chanvc;
+ struct sdma_desc*desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -317,12 +342,6 @@ struct sdma_channel {
unsigned intevent_id0;
unsigned intevent_id1;
enum dma_slave_buswidth word_size;
- unsigned intbuf_tail;
- unsigned intbuf_ptail;
- unsigned intnum_bd;
- unsigned intperiod_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
[PATCH v2 1/5] dmaengine: imx-sdma: add virt-dma support
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
The main changes as below:
--new "sdma_desc" structure containing virt_dma_desc and some members
which moved from "sdma_channel" such as "num_bd","bd_phys","bd",etc,
since multi descriptors may exist on virtual dma framework
rather than only one as before.
--remove some members of "sdma_channel" structure since it's handled
by virtual dma common framework, such as "tasklet", "dma_chan",etc.
--add specific BD0 for channel0 since such bd descriptor is must and
basic for other dma channel, no need alloc/free as other channel,so
request it during probe.
--remove sdma_request_channel(),sdma_tx_submit(),etc.
--alloc/free bd descriptor added and code changes for virtual dma.
Signed-off-by: Robin Gong
---
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 332 -
2 files changed, 220 insertions(+), 113 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index ca1680a..d4a4230 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -250,6 +250,7 @@ config IMX_SDMA
tristate "i.MX SDMA support"
depends on ARCH_MXC
select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
help
Support the i.MX SDMA engine. This engine is integrated into
Freescale i.MX25/31/35/51/53/6 chips.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccd03c3..8d0c1fd 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -48,6 +48,7 @@
#include
#include "dmaengine.h"
+#include "virt-dma.h"
/* SDMA registers */
#define SDMA_H_C0PTR 0x000
@@ -296,6 +297,31 @@ struct sdma_context_data {
struct sdma_engine;
/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ struct virt_dma_descvd;
+ unsigned intnum_bd;
+ dma_addr_t bd_phys;
+ unsigned intbuf_tail;
+ unsigned intbuf_ptail;
+ unsigned intperiod_len;
+ unsigned intchn_real_count;
+ unsigned intchn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
+/**
* struct sdma_channel - housekeeping for a SDMA channel
*
* @sdma pointer to the SDMA engine for this channel
@@ -305,11 +331,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct virt_dma_chanvc;
+ struct sdma_desc*desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -317,12 +342,6 @@ struct sdma_channel {
unsigned intevent_id0;
unsigned intevent_id1;
enum dma_slave_buswidth word_size;
- unsigned intbuf_tail;
- unsigned intbuf_ptail;
- unsigned intnum_bd;
- unsigned intperiod_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
[PATCH v2 0/5] add virt-dma support for imx-sdma
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Change from v1:
1. split v1 patch into 5 patches.
2. remove some unnecessary condition check.
3. remove unneccessary 'pending' list.
Robin Gong (5):
dmaengine: imx-sdma: add virt-dma support
Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled
during interrupt"
dmaengine: imx-sdma: remove usless lock
dmaengine: imx-sdma: remove the maximum limation for bd numbers
dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 392 -
2 files changed, 227 insertions(+), 166 deletions(-)
--
2.7.4
[PATCH v2 4/5] dmaengine: imx-sdma: remove the maximum limation for bd numbers
No this limitation now after virtual dma used since bd is allocated
dynamically instead of static.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 6faec89..afaee72 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -292,7 +292,6 @@ struct sdma_context_data {
u32 scratch7;
} __attribute__ ((packed));
-#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
struct sdma_engine;
@@ -1297,13 +1296,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
if (ret)
goto err_bd_out;
- if (sg_len > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, sg_len, NUM_BD);
- ret = -EINVAL;
- goto err_bd_out;
- }
-
desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = >bd[i];
@@ -1413,12 +1405,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
if (ret)
goto err_bd_out;
- if (num_periods > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, num_periods, NUM_BD);
- goto err_bd_out;
- }
-
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
channel, period_len, 0x);
--
2.7.4
[PATCH v2 0/5] add virt-dma support for imx-sdma
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Change from v1:
1. split v1 patch into 5 patches.
2. remove some unnecessary condition check.
3. remove unneccessary 'pending' list.
Robin Gong (5):
dmaengine: imx-sdma: add virt-dma support
Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled
during interrupt"
dmaengine: imx-sdma: remove usless lock
dmaengine: imx-sdma: remove the maximum limation for bd numbers
dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 392 -
2 files changed, 227 insertions(+), 166 deletions(-)
--
2.7.4
[PATCH v2 4/5] dmaengine: imx-sdma: remove the maximum limation for bd numbers
No this limitation now after virtual dma used since bd is allocated
dynamically instead of static.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 6faec89..afaee72 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -292,7 +292,6 @@ struct sdma_context_data {
u32 scratch7;
} __attribute__ ((packed));
-#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
struct sdma_engine;
@@ -1297,13 +1296,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
if (ret)
goto err_bd_out;
- if (sg_len > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, sg_len, NUM_BD);
- ret = -EINVAL;
- goto err_bd_out;
- }
-
desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = >bd[i];
@@ -1413,12 +1405,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
if (ret)
goto err_bd_out;
- if (num_periods > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, num_periods, NUM_BD);
- goto err_bd_out;
- }
-
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
channel, period_len, 0x);
--
2.7.4
[git pull] vfs.git fix proc_fill_cache() regression
Regression fix for proc_fill_cache() braino introduced when switching instantiate() callback to d_splice_alias(). [with apologies for being MIA for several days - flu started on Sunday and got really nasty on Tuesday; back to normal now, hopefully] The following changes since commit 888e2b03ef56694290e58bd9ac23f8033bf6369f: switch the rest of procfs lookups to d_splice_alias() (2018-05-26 14:20:50 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.lookup for you to fetch changes up to d85b399b64e85a311c09205c675d4ae1c5af6246: fix proc_fill_cache() in case of d_alloc_parallel() failure (2018-06-08 01:17:11 -0400) Al Viro (1): fix proc_fill_cache() in case of d_alloc_parallel() failure fs/proc/base.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
[git pull] vfs.git fix proc_fill_cache() regression
Regression fix for proc_fill_cache() braino introduced when switching instantiate() callback to d_splice_alias(). [with apologies for being MIA for several days - flu started on Sunday and got really nasty on Tuesday; back to normal now, hopefully] The following changes since commit 888e2b03ef56694290e58bd9ac23f8033bf6369f: switch the rest of procfs lookups to d_splice_alias() (2018-05-26 14:20:50 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.lookup for you to fetch changes up to d85b399b64e85a311c09205c675d4ae1c5af6246: fix proc_fill_cache() in case of d_alloc_parallel() failure (2018-06-08 01:17:11 -0400) Al Viro (1): fix proc_fill_cache() in case of d_alloc_parallel() failure fs/proc/base.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
[git pull] vfs.git - aio ioprio
The rest of aio stuff for this cycle - Adam's aio ioprio series The following changes since commit 1da92779e2e8f309d5aecbbed346e7f812b174e8: aio: sanitize the limit checking in io_submit(2) (2018-05-29 23:20:17 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.aio for you to fetch changes up to 9a6d9a62e0fd4b9927c3124db0f25fc6b4fb6576: fs: aio ioprio use ioprio_check_cap ret val (2018-06-04 14:20:39 -0400) Adam Manzanares (7): block: add ioprio_check_cap function fs: Convert kiocb rw_hint from enum to u16 fs: Add aio iopriority support fs: blkdev set bio prio from kiocb prio fs: iomap dio set bio prio from kiocb prio fs: aio ioprio add explicit block layer dependence fs: aio ioprio use ioprio_check_cap ret val block/ioprio.c | 22 -- drivers/block/loop.c | 3 +++ fs/aio.c | 18 +- fs/block_dev.c | 2 ++ fs/iomap.c | 1 + include/linux/fs.h | 16 ++-- include/linux/ioprio.h | 9 + include/uapi/linux/aio_abi.h | 1 + 8 files changed, 63 insertions(+), 9 deletions(-)
[git pull] vfs.git - aio ioprio
The rest of aio stuff for this cycle - Adam's aio ioprio series The following changes since commit 1da92779e2e8f309d5aecbbed346e7f812b174e8: aio: sanitize the limit checking in io_submit(2) (2018-05-29 23:20:17 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.aio for you to fetch changes up to 9a6d9a62e0fd4b9927c3124db0f25fc6b4fb6576: fs: aio ioprio use ioprio_check_cap ret val (2018-06-04 14:20:39 -0400) Adam Manzanares (7): block: add ioprio_check_cap function fs: Convert kiocb rw_hint from enum to u16 fs: Add aio iopriority support fs: blkdev set bio prio from kiocb prio fs: iomap dio set bio prio from kiocb prio fs: aio ioprio add explicit block layer dependence fs: aio ioprio use ioprio_check_cap ret val block/ioprio.c | 22 -- drivers/block/loop.c | 3 +++ fs/aio.c | 18 +- fs/block_dev.c | 2 ++ fs/iomap.c | 1 + include/linux/fs.h | 16 ++-- include/linux/ioprio.h | 9 + include/uapi/linux/aio_abi.h | 1 + 8 files changed, 63 insertions(+), 9 deletions(-)
linux-next: Tree for Jun 8
Hi all, News: There will be no linux-next release on Monday. Note: please do *not* add any v4.19 material to your linux-next included branches until after v4.18-rc1 has been released. Changes since 20180607: Non-merge commits (relative to Linus' tree): 4298 4027 files changed, 122295 insertions(+), 272707 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 278 trees (counting Linus' and 64 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (289cf155d95d Merge tag 'devicetree-for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (b04e217704b7 Linux 4.17-rc7) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (82034c23fcbc arm64: Make sure permission updates happen for pmd/pud) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (faf37c44a105 powerpc/64s: Clear PCR on boot) Merging sparc/master (1c1ff29da6c8 sparc: fix compat siginfo ABI regression) CONFLICT (content): Merge conflict in arch/sparc/kernel/traps_64.c CONFLICT (content): Merge conflict in arch/sparc/kernel/traps_32.c Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (8d97ca6b6755 bpfilter: fix OUTPUT_FORMAT) Merging bpf/master (58990d1ff3f7 bpf: reject passing modified ctx to helper functions) Merging ipsec/master (1c8c5a9d38f6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next) Merging netfilter/master (64e6dd1fb2f1 netfilter: nf_conntrack: Increase __IPS_MAX_BIT with new bit IPS_OFFLOAD_BIT) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (ab1068d6866e iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs) Merging mac80211/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging rdma-fixes/for-rc (a840c93ca758 IB/core: Fix error code for invalid GID entry) Merging sound-current/for-linus (d4d5a1cd298e Merge tag 'asoc-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (2858e2cfc2ef Merge branch 'asoc-4.17' into asoc-linus) Merging regmap-fixes/for-linus (97fe106a8027 Merge branch 'regmap-4.17' into regmap-linus) Merging regulator-fixes/for-linus (59ce5f3e5530 Merge branch 'regulator-4.17' into regulator-linus) Merging spi-fixes/for-linus (5d3257b8ea48 Merge branch 'spi-4.17' into spi-linus) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (1c8c5a9d38f6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next) Merging tty.current/tty-linus (af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq) Merging usb.current/usb-linus (af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq) Merging usb-gadget-fixes/fixes (6d08b06e67cd Linux 4.17-rc2) Merg
linux-next: Tree for Jun 8
Hi all, News: There will be no linux-next release on Monday. Note: please do *not* add any v4.19 material to your linux-next included branches until after v4.18-rc1 has been released. Changes since 20180607: Non-merge commits (relative to Linus' tree): 4298 4027 files changed, 122295 insertions(+), 272707 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 278 trees (counting Linus' and 64 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (289cf155d95d Merge tag 'devicetree-for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (b04e217704b7 Linux 4.17-rc7) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (82034c23fcbc arm64: Make sure permission updates happen for pmd/pud) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (faf37c44a105 powerpc/64s: Clear PCR on boot) Merging sparc/master (1c1ff29da6c8 sparc: fix compat siginfo ABI regression) CONFLICT (content): Merge conflict in arch/sparc/kernel/traps_64.c CONFLICT (content): Merge conflict in arch/sparc/kernel/traps_32.c Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (8d97ca6b6755 bpfilter: fix OUTPUT_FORMAT) Merging bpf/master (58990d1ff3f7 bpf: reject passing modified ctx to helper functions) Merging ipsec/master (1c8c5a9d38f6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next) Merging netfilter/master (64e6dd1fb2f1 netfilter: nf_conntrack: Increase __IPS_MAX_BIT with new bit IPS_OFFLOAD_BIT) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (ab1068d6866e iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs) Merging mac80211/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging rdma-fixes/for-rc (a840c93ca758 IB/core: Fix error code for invalid GID entry) Merging sound-current/for-linus (d4d5a1cd298e Merge tag 'asoc-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (2858e2cfc2ef Merge branch 'asoc-4.17' into asoc-linus) Merging regmap-fixes/for-linus (97fe106a8027 Merge branch 'regmap-4.17' into regmap-linus) Merging regulator-fixes/for-linus (59ce5f3e5530 Merge branch 'regulator-4.17' into regulator-linus) Merging spi-fixes/for-linus (5d3257b8ea48 Merge branch 'spi-4.17' into spi-linus) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (1c8c5a9d38f6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next) Merging tty.current/tty-linus (af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq) Merging usb.current/usb-linus (af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq) Merging usb-gadget-fixes/fixes (6d08b06e67cd Linux 4.17-rc2) Merg
[PATCH] tee: optee: making OPTEE_SHM_NUM_PRIV_PAGES configurable via Kconfig
This change adds KCONFIG option to set number of pages out of whole shared memory to be used for OP-TEE driver private data structures. Signed-off-by: Sahil Malhotra --- drivers/tee/optee/Kconfig | 8 drivers/tee/optee/core.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index 524c7a80fde4..f425c960a5a2 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -12,3 +12,11 @@ config OPTEE_BENCHMARK help This enables benchmarking feature in the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_SHM_NUM_PRIV_PAGES + int "Private Shared Memory Pages" + default 1 + depends on OPTEE + help + This sets the number of private shared memory pages to be + used by OP-TEE TEE driver. diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 4a2c420d4fe4..8d3be6b1bb96 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -33,7 +33,7 @@ #define DRIVER_NAME "optee" -#define OPTEE_SHM_NUM_PRIV_PAGES 1 +#define OPTEE_SHM_NUM_PRIV_PAGES CONFIG_OPTEE_SHM_NUM_PRIV_PAGES /** * optee_from_msg_param() - convert from OPTEE_MSG parameters to -- 2.17.0
[PATCH] tee: optee: making OPTEE_SHM_NUM_PRIV_PAGES configurable via Kconfig
This change adds KCONFIG option to set number of pages out of whole shared memory to be used for OP-TEE driver private data structures. Signed-off-by: Sahil Malhotra --- drivers/tee/optee/Kconfig | 8 drivers/tee/optee/core.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index 524c7a80fde4..f425c960a5a2 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -12,3 +12,11 @@ config OPTEE_BENCHMARK help This enables benchmarking feature in the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_SHM_NUM_PRIV_PAGES + int "Private Shared Memory Pages" + default 1 + depends on OPTEE + help + This sets the number of private shared memory pages to be + used by OP-TEE TEE driver. diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 4a2c420d4fe4..8d3be6b1bb96 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -33,7 +33,7 @@ #define DRIVER_NAME "optee" -#define OPTEE_SHM_NUM_PRIV_PAGES 1 +#define OPTEE_SHM_NUM_PRIV_PAGES CONFIG_OPTEE_SHM_NUM_PRIV_PAGES /** * optee_from_msg_param() - convert from OPTEE_MSG parameters to -- 2.17.0
RE: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller devicetree binding information
Hi Miquel,
Thanks for the review.
> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Thursday, June 7, 2018 9:12 PM
> To: Naga Sureshkumar Relli
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; w...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; f.faine...@gmail.com;
> mma...@broadcom.com; rog...@ti.com; la...@linux-mips.org; a...@thorsis.com;
> honghui.zh...@mediatek.com; linux-...@lists.infradead.org;
> linux-kernel@vger.kernel.org;
> nagasureshkumarre...@gmail.com
> Subject: Re: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller
> devicetree
> binding information
>
> Hi Naga,
>
> On Wed, 6 Jun 2018 13:19:39 +0530, Naga Sureshkumar Relli
> wrote:
>
> > Add pl353 static memory controller devicetree binding information.
> >
> > Signed-off-by: Naga Sureshkumar Relli
> >
> > ---
> > Changes in v9:
> > - Addressed commens given by Randy Dunlap and Miquel Raynal
>
> Can you please be more specific in your next changelog? I don't remember what
> I suggested a
> few months ago :)
Ok, I will update.
>
> > Changes in v8:
> > - None
> > Changes in v7:
> > - Corrected clocks description
> > - prefixed '#' for address and size cells Changes in v6:
> > - None
> > Changes in v5:
> > - Removed timing properties
> > Changes in v4:
> > - none
> > Changes in v3:
> > - none
> > Changes in v2:
> > - modified timing binding info as per onfi timing parameters
> > - add suffix nano second as timing unit
> > - modified the clock names as per the IP spec
> > ---
> > .../bindings/memory-controllers/pl353-smc.txt | 53
> ++
> > 1 file changed, 53 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > new file mode 100644
> > index 000..551e66b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.t
> > +++ xt
> > @@ -0,0 +1,53 @@
> > +Device tree bindings for ARM PL353 static memory controller
> > +
> > +PL353 static memory controller supports two kinds of memory
> > +interfaces.i.e NAND and SRAM/NOR interfaces.
> > +The actual devices are instantiated from the child nodes of pl353 smc node.
> > +
> > +Required properties:
> > +- compatible : Should be "arm,pl353-smc-r2p1"
>
> I thing Rob prefers:
>
> - compatible: Must be one of:
> * arm, pl353-smc-r2p1
Are you suggesting any other compatibles?
Or just a change from "should be to Must be one of"?
>
> > +- reg : Controller registers map and length.
> > +- clock-names : List of input clock names - "ref_clk",
> > "aper_clk"
> > + (See clock bindings for details).
> > +- clocks : Clock phandles (see clock bindings for details).
> > +- address-cells: Address cells, must be 1.
> > +- size-cells : Size cells. Must be 1.
>
> Please avoid padding, just this is enough:
>
> - something: And another thing.
Ok, I will update it.
>
> > +
> > +Child nodes:
> > + For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash"
> > +drivers are supported as child nodes.
> > +
> > +Mandatory timing properties for child nodes:
> > +- arm,nand-cycle-t0: Read cycle time(t_rc).
> > +- arm,nand-cycle-t1: Write cycle time(t_wc).
> > +- arm,nand-cycle-t2: re_n assertion delay(t_rea).
> > +- arm,nand-cycle-t3: we_n de-assertion delay(t_wp).
> > +- arm,nand-cycle-t4: Status read time(t_clr)
> > +- arm,nand-cycle-t5: ID read time(t_ar)
> > +- arm,nand-cycle-t6: busy to re_n(t_rr)
>
> I think this has nothing to do in the DT, you should handle timings from the -
> >setup_data_interface() hook. If you need, you may use different compatibles
> >to distinguish
> different platform data.
>
This controller is applicable only to Zynq platform. No other platform will use
this.
Basically pl353-smc.c and pl353-nand.c, both are different drivers.
And this data_interface hook is in nand, and to set this timings if we read it
from setup_data_interface(), then
We need to make call from nand to smc driver.
Let me try this.
> > +
> > +for nand partition information please refer the below file
>
> s/nand/NAND/
I will update in next version.
>
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > + pl353smcc_0: pl353smcc@e000e000 {
>
> Why not something more explicit with the '-flash-controller' suffix?
Is this ok?
smcc: memory-controller@e000e000 {}
>
> > + compatible = "arm,pl353-smc-r2p1"
> > + clock-names = "memclk", "aclk";
> > + clocks = < 11>, < 44>;
> > + reg = <0xe000e000 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells
RE: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller devicetree binding information
Hi Miquel,
Thanks for the review.
> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Thursday, June 7, 2018 9:12 PM
> To: Naga Sureshkumar Relli
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; w...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; f.faine...@gmail.com;
> mma...@broadcom.com; rog...@ti.com; la...@linux-mips.org; a...@thorsis.com;
> honghui.zh...@mediatek.com; linux-...@lists.infradead.org;
> linux-kernel@vger.kernel.org;
> nagasureshkumarre...@gmail.com
> Subject: Re: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller
> devicetree
> binding information
>
> Hi Naga,
>
> On Wed, 6 Jun 2018 13:19:39 +0530, Naga Sureshkumar Relli
> wrote:
>
> > Add pl353 static memory controller devicetree binding information.
> >
> > Signed-off-by: Naga Sureshkumar Relli
> >
> > ---
> > Changes in v9:
> > - Addressed commens given by Randy Dunlap and Miquel Raynal
>
> Can you please be more specific in your next changelog? I don't remember what
> I suggested a
> few months ago :)
Ok, I will update.
>
> > Changes in v8:
> > - None
> > Changes in v7:
> > - Corrected clocks description
> > - prefixed '#' for address and size cells Changes in v6:
> > - None
> > Changes in v5:
> > - Removed timing properties
> > Changes in v4:
> > - none
> > Changes in v3:
> > - none
> > Changes in v2:
> > - modified timing binding info as per onfi timing parameters
> > - add suffix nano second as timing unit
> > - modified the clock names as per the IP spec
> > ---
> > .../bindings/memory-controllers/pl353-smc.txt | 53
> ++
> > 1 file changed, 53 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > new file mode 100644
> > index 000..551e66b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.t
> > +++ xt
> > @@ -0,0 +1,53 @@
> > +Device tree bindings for ARM PL353 static memory controller
> > +
> > +PL353 static memory controller supports two kinds of memory
> > +interfaces.i.e NAND and SRAM/NOR interfaces.
> > +The actual devices are instantiated from the child nodes of pl353 smc node.
> > +
> > +Required properties:
> > +- compatible : Should be "arm,pl353-smc-r2p1"
>
> I thing Rob prefers:
>
> - compatible: Must be one of:
> * arm, pl353-smc-r2p1
Are you suggesting any other compatibles?
Or just a change from "should be to Must be one of"?
>
> > +- reg : Controller registers map and length.
> > +- clock-names : List of input clock names - "ref_clk",
> > "aper_clk"
> > + (See clock bindings for details).
> > +- clocks : Clock phandles (see clock bindings for details).
> > +- address-cells: Address cells, must be 1.
> > +- size-cells : Size cells. Must be 1.
>
> Please avoid padding, just this is enough:
>
> - something: And another thing.
Ok, I will update it.
>
> > +
> > +Child nodes:
> > + For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash"
> > +drivers are supported as child nodes.
> > +
> > +Mandatory timing properties for child nodes:
> > +- arm,nand-cycle-t0: Read cycle time(t_rc).
> > +- arm,nand-cycle-t1: Write cycle time(t_wc).
> > +- arm,nand-cycle-t2: re_n assertion delay(t_rea).
> > +- arm,nand-cycle-t3: we_n de-assertion delay(t_wp).
> > +- arm,nand-cycle-t4: Status read time(t_clr)
> > +- arm,nand-cycle-t5: ID read time(t_ar)
> > +- arm,nand-cycle-t6: busy to re_n(t_rr)
>
> I think this has nothing to do in the DT, you should handle timings from the -
> >setup_data_interface() hook. If you need, you may use different compatibles
> >to distinguish
> different platform data.
>
This controller is applicable only to Zynq platform. No other platform will use
this.
Basically pl353-smc.c and pl353-nand.c, both are different drivers.
And this data_interface hook is in nand, and to set this timings if we read it
from setup_data_interface(), then
We need to make call from nand to smc driver.
Let me try this.
> > +
> > +for nand partition information please refer the below file
>
> s/nand/NAND/
I will update in next version.
>
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > + pl353smcc_0: pl353smcc@e000e000 {
>
> Why not something more explicit with the '-flash-controller' suffix?
Is this ok?
smcc: memory-controller@e000e000 {}
>
> > + compatible = "arm,pl353-smc-r2p1"
> > + clock-names = "memclk", "aclk";
> > + clocks = < 11>, < 44>;
> > + reg = <0xe000e000 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells
Re: 4.17-ad1: -march=native support or Kernel Ricers wanted
Hi Alexey, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17] [cannot apply to tip/x86/core next-20180607] [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/Alexey-Dobriyan/4-17-ad1-march-native-support-or-Kernel-Ricers-wanted/20180605-090623 config: x86_64-kexec (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): make[3]: execvp: scripts/march-native.sh: Permission denied make[3]: *** [syncconfig] Error 127 make[2]: *** [syncconfig] Error 2 >> make[1]: *** No rule to make target 'include/config/auto.conf', needed by >> 'include/config/kernel.release'. make[1]: Target 'prepare' not remade because of errors. make: *** [sub-make] Error 2 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: 4.17-ad1: -march=native support or Kernel Ricers wanted
Hi Alexey, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17] [cannot apply to tip/x86/core next-20180607] [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/Alexey-Dobriyan/4-17-ad1-march-native-support-or-Kernel-Ricers-wanted/20180605-090623 config: x86_64-kexec (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): make[3]: execvp: scripts/march-native.sh: Permission denied make[3]: *** [syncconfig] Error 127 make[2]: *** [syncconfig] Error 2 >> make[1]: *** No rule to make target 'include/config/auto.conf', needed by >> 'include/config/kernel.release'. make[1]: Target 'prepare' not remade because of errors. make: *** [sub-make] Error 2 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()
On 2018-06-08 03:04, Bjorn Helgaas wrote:
On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote:
On 2018-06-07 11:30, Oza Pawandeep wrote:
> We are handling ERR_FATAL by resetting the Link in software,skipping the
> driver pci_error_handlers callbacks, removing the devices from the PCI
> subsystem, and re-enumerating, as a result of that, no more calling
> pcie_portdrv_slot_reset in ERR_FATAL case.
>
> Signed-off-by: Oza Pawandeep
>
> diff --git a/drivers/pci/pcie/portdrv_pci.c
> b/drivers/pci/pcie/portdrv_pci.c
> index 973f1b8..92f5d330 100644
> --- a/drivers/pci/pcie/portdrv_pci.c
> +++ b/drivers/pci/pcie/portdrv_pci.c
> @@ -42,17 +42,6 @@ __setup("pcie_ports=", pcie_port_setup);
>
> /* global data */
>
> -static int pcie_portdrv_restore_config(struct pci_dev *dev)
> -{
> - int retval;
> -
> - retval = pci_enable_device(dev);
> - if (retval)
> - return retval;
> - pci_set_master(dev);
> - return 0;
> -}
> -
> #ifdef CONFIG_PM
> static int pcie_port_runtime_suspend(struct device *dev)
> {
> @@ -162,14 +151,6 @@ static pci_ers_result_t
> pcie_portdrv_mmio_enabled(struct pci_dev *dev)
>
> static pci_ers_result_t pcie_portdrv_slot_reset(struct pci_dev *dev)
> {
> - /* If fatal, restore cfg space for possible link reset at upstream */
> - if (dev->error_state == pci_channel_io_frozen) {
> - dev->state_saved = true;
> - pci_restore_state(dev);
> - pcie_portdrv_restore_config(dev);
> - pci_enable_pcie_error_reporting(dev);
> - }
> -
>return PCI_ERS_RESULT_RECOVERED;
> }
Hi Bjorn,
the above patch removes ERR_FATAL handling from
pcie_portdrv_slot_reset()
because now we are handling ERR_FATAL differently than before.
I tried to dig into pcie_portdrv_slot_reset() handling for ERR_FATAL
case
where it
restores the config space, enable device, set master and enable error
reporting
and as far as I understand this is being done for upstream link
(bridges
etc..)
why was it done at the first point (I checked the commit description,
but
could not really get it)
and do we need to handle the same thing in ERR_FATAL now ?
You mean 4bf3392e0bf5 ("PCI-Express AER implemetation: pcie_portdrv
error handler"), which added pcie_portdrv_slot_reset()? I agree, that
commit log has no useful information. I don't know any of the history
behind it.
Yes Bjorn thats right.
I am trying to understand it but no clue.
since it is restoring the stuffs in ERR_FATAL case, why would PCIe
bridge loose all the settings ? [config space, aer bits, master, device
enable etc..)
Max we do is link_reset in ERR_FATAL case, and Secondary bus reset
should affect downstream components (not upstream)
Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()
On 2018-06-08 03:04, Bjorn Helgaas wrote:
On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote:
On 2018-06-07 11:30, Oza Pawandeep wrote:
> We are handling ERR_FATAL by resetting the Link in software,skipping the
> driver pci_error_handlers callbacks, removing the devices from the PCI
> subsystem, and re-enumerating, as a result of that, no more calling
> pcie_portdrv_slot_reset in ERR_FATAL case.
>
> Signed-off-by: Oza Pawandeep
>
> diff --git a/drivers/pci/pcie/portdrv_pci.c
> b/drivers/pci/pcie/portdrv_pci.c
> index 973f1b8..92f5d330 100644
> --- a/drivers/pci/pcie/portdrv_pci.c
> +++ b/drivers/pci/pcie/portdrv_pci.c
> @@ -42,17 +42,6 @@ __setup("pcie_ports=", pcie_port_setup);
>
> /* global data */
>
> -static int pcie_portdrv_restore_config(struct pci_dev *dev)
> -{
> - int retval;
> -
> - retval = pci_enable_device(dev);
> - if (retval)
> - return retval;
> - pci_set_master(dev);
> - return 0;
> -}
> -
> #ifdef CONFIG_PM
> static int pcie_port_runtime_suspend(struct device *dev)
> {
> @@ -162,14 +151,6 @@ static pci_ers_result_t
> pcie_portdrv_mmio_enabled(struct pci_dev *dev)
>
> static pci_ers_result_t pcie_portdrv_slot_reset(struct pci_dev *dev)
> {
> - /* If fatal, restore cfg space for possible link reset at upstream */
> - if (dev->error_state == pci_channel_io_frozen) {
> - dev->state_saved = true;
> - pci_restore_state(dev);
> - pcie_portdrv_restore_config(dev);
> - pci_enable_pcie_error_reporting(dev);
> - }
> -
>return PCI_ERS_RESULT_RECOVERED;
> }
Hi Bjorn,
the above patch removes ERR_FATAL handling from
pcie_portdrv_slot_reset()
because now we are handling ERR_FATAL differently than before.
I tried to dig into pcie_portdrv_slot_reset() handling for ERR_FATAL
case
where it
restores the config space, enable device, set master and enable error
reporting
and as far as I understand this is being done for upstream link
(bridges
etc..)
why was it done at the first point (I checked the commit description,
but
could not really get it)
and do we need to handle the same thing in ERR_FATAL now ?
You mean 4bf3392e0bf5 ("PCI-Express AER implemetation: pcie_portdrv
error handler"), which added pcie_portdrv_slot_reset()? I agree, that
commit log has no useful information. I don't know any of the history
behind it.
Yes Bjorn thats right.
I am trying to understand it but no clue.
since it is restoring the stuffs in ERR_FATAL case, why would PCIe
bridge loose all the settings ? [config space, aer bits, master, device
enable etc..)
Max we do is link_reset in ERR_FATAL case, and Secondary bus reset
should affect downstream components (not upstream)
Re: [PATCH V5] powercap/drivers/idle_injection: Add an idle injection framework
On 07-06-18, 16:11, Daniel Lezcano wrote: > >> I'm wondering if we can have a CPU hotplugged right after the > >> 'put_online_cpus', resulting in the 'should park' flag set and then the > >> thread goes in the kthread_parkme instead of jumping back the idle > >> injection function and decrease the count, leading up to the timer not > >> being set again. > > > > True. That looks like a valid problem to me as well. > > > > What about starting the hrtimer right from this routine itself, after taking > > into account running-time, idle-time, delay, etc ? That would get rid of the > > count stuff, this get_online_cpus(), etc. > > > > Even if we restart the next play-idle cycle a bit early or with some delay, > > sky > > wouldn't fall :) > > We won't be able to call completion() in this case. I was just having a look at smpboot.h and saw the park/unpark callbacks. I think you can very much use them to align things with CPU hotplug. -- viresh
Re: [PATCH V5] powercap/drivers/idle_injection: Add an idle injection framework
On 07-06-18, 16:11, Daniel Lezcano wrote: > >> I'm wondering if we can have a CPU hotplugged right after the > >> 'put_online_cpus', resulting in the 'should park' flag set and then the > >> thread goes in the kthread_parkme instead of jumping back the idle > >> injection function and decrease the count, leading up to the timer not > >> being set again. > > > > True. That looks like a valid problem to me as well. > > > > What about starting the hrtimer right from this routine itself, after taking > > into account running-time, idle-time, delay, etc ? That would get rid of the > > count stuff, this get_online_cpus(), etc. > > > > Even if we restart the next play-idle cycle a bit early or with some delay, > > sky > > wouldn't fall :) > > We won't be able to call completion() in this case. I was just having a look at smpboot.h and saw the park/unpark callbacks. I think you can very much use them to align things with CPU hotplug. -- viresh
Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()
On 2018-06-08 03:04, Bjorn Helgaas wrote:
On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote:
On 2018-06-07 11:30, Oza Pawandeep wrote:
> We are handling ERR_FATAL by resetting the Link in software,skipping the
> driver pci_error_handlers callbacks, removing the devices from the PCI
> subsystem, and re-enumerating, as a result of that, no more calling
> pcie_portdrv_slot_reset in ERR_FATAL case.
>
> Signed-off-by: Oza Pawandeep
>
> diff --git a/drivers/pci/pcie/portdrv_pci.c
> b/drivers/pci/pcie/portdrv_pci.c
> index 973f1b8..92f5d330 100644
> --- a/drivers/pci/pcie/portdrv_pci.c
> +++ b/drivers/pci/pcie/portdrv_pci.c
> @@ -42,17 +42,6 @@ __setup("pcie_ports=", pcie_port_setup);
>
> /* global data */
>
> -static int pcie_portdrv_restore_config(struct pci_dev *dev)
> -{
> - int retval;
> -
> - retval = pci_enable_device(dev);
> - if (retval)
> - return retval;
> - pci_set_master(dev);
> - return 0;
> -}
> -
> #ifdef CONFIG_PM
> static int pcie_port_runtime_suspend(struct device *dev)
> {
> @@ -162,14 +151,6 @@ static pci_ers_result_t
> pcie_portdrv_mmio_enabled(struct pci_dev *dev)
>
> static pci_ers_result_t pcie_portdrv_slot_reset(struct pci_dev *dev)
> {
> - /* If fatal, restore cfg space for possible link reset at upstream */
> - if (dev->error_state == pci_channel_io_frozen) {
> - dev->state_saved = true;
> - pci_restore_state(dev);
> - pcie_portdrv_restore_config(dev);
> - pci_enable_pcie_error_reporting(dev);
> - }
> -
>return PCI_ERS_RESULT_RECOVERED;
> }
Hi Bjorn,
the above patch removes ERR_FATAL handling from
pcie_portdrv_slot_reset()
because now we are handling ERR_FATAL differently than before.
I tried to dig into pcie_portdrv_slot_reset() handling for ERR_FATAL
case
where it
restores the config space, enable device, set master and enable error
reporting
and as far as I understand this is being done for upstream link
(bridges
etc..)
why was it done at the first point (I checked the commit description,
but
could not really get it)
and do we need to handle the same thing in ERR_FATAL now ?
You mean 4bf3392e0bf5 ("PCI-Express AER implemetation: pcie_portdrv
error handler"), which added pcie_portdrv_slot_reset()? I agree, that
commit log has no useful information. I don't know any of the history
behind it.
Keith,
do you know why in ERR_FATAL case following was done ?
have a look at pcie_portdrv_slot_reset() handling (for bridges, switches
etc..)
Regards,
Oza.
Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()
On 2018-06-08 03:04, Bjorn Helgaas wrote:
On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote:
On 2018-06-07 11:30, Oza Pawandeep wrote:
> We are handling ERR_FATAL by resetting the Link in software,skipping the
> driver pci_error_handlers callbacks, removing the devices from the PCI
> subsystem, and re-enumerating, as a result of that, no more calling
> pcie_portdrv_slot_reset in ERR_FATAL case.
>
> Signed-off-by: Oza Pawandeep
>
> diff --git a/drivers/pci/pcie/portdrv_pci.c
> b/drivers/pci/pcie/portdrv_pci.c
> index 973f1b8..92f5d330 100644
> --- a/drivers/pci/pcie/portdrv_pci.c
> +++ b/drivers/pci/pcie/portdrv_pci.c
> @@ -42,17 +42,6 @@ __setup("pcie_ports=", pcie_port_setup);
>
> /* global data */
>
> -static int pcie_portdrv_restore_config(struct pci_dev *dev)
> -{
> - int retval;
> -
> - retval = pci_enable_device(dev);
> - if (retval)
> - return retval;
> - pci_set_master(dev);
> - return 0;
> -}
> -
> #ifdef CONFIG_PM
> static int pcie_port_runtime_suspend(struct device *dev)
> {
> @@ -162,14 +151,6 @@ static pci_ers_result_t
> pcie_portdrv_mmio_enabled(struct pci_dev *dev)
>
> static pci_ers_result_t pcie_portdrv_slot_reset(struct pci_dev *dev)
> {
> - /* If fatal, restore cfg space for possible link reset at upstream */
> - if (dev->error_state == pci_channel_io_frozen) {
> - dev->state_saved = true;
> - pci_restore_state(dev);
> - pcie_portdrv_restore_config(dev);
> - pci_enable_pcie_error_reporting(dev);
> - }
> -
>return PCI_ERS_RESULT_RECOVERED;
> }
Hi Bjorn,
the above patch removes ERR_FATAL handling from
pcie_portdrv_slot_reset()
because now we are handling ERR_FATAL differently than before.
I tried to dig into pcie_portdrv_slot_reset() handling for ERR_FATAL
case
where it
restores the config space, enable device, set master and enable error
reporting
and as far as I understand this is being done for upstream link
(bridges
etc..)
why was it done at the first point (I checked the commit description,
but
could not really get it)
and do we need to handle the same thing in ERR_FATAL now ?
You mean 4bf3392e0bf5 ("PCI-Express AER implemetation: pcie_portdrv
error handler"), which added pcie_portdrv_slot_reset()? I agree, that
commit log has no useful information. I don't know any of the history
behind it.
Keith,
do you know why in ERR_FATAL case following was done ?
have a look at pcie_portdrv_slot_reset() handling (for bridges, switches
etc..)
Regards,
Oza.
linux-next: build warning after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from fs/fat/inode.c:24:0:
fs/fat/inode.c: In function '__fat_get_block':
fs/fat/inode.c:163:9: warning: format '%ld' expects argument of type 'long
int', but argument 5 has type 'sector_t {aka long long unsigned int}'
[-Wformat=]
"invalid FAT chain (i_pos %lld, last_block %ld)",
^
fs/fat/fat.h:397:24: note: in definition of macro 'fat_fs_error'
__fat_fs_error(sb, 1, fmt , ## args)
^~~
Introduced by commit
3bdac70a1921 ("fat: use fat_fs_error() instead of BUG_ON() in
__fat_get_block()")
--
Cheers,
Stephen Rothwell
pgpZZNY9AlJz2.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from fs/fat/inode.c:24:0:
fs/fat/inode.c: In function '__fat_get_block':
fs/fat/inode.c:163:9: warning: format '%ld' expects argument of type 'long
int', but argument 5 has type 'sector_t {aka long long unsigned int}'
[-Wformat=]
"invalid FAT chain (i_pos %lld, last_block %ld)",
^
fs/fat/fat.h:397:24: note: in definition of macro 'fat_fs_error'
__fat_fs_error(sb, 1, fmt , ## args)
^~~
Introduced by commit
3bdac70a1921 ("fat: use fat_fs_error() instead of BUG_ON() in
__fat_get_block()")
--
Cheers,
Stephen Rothwell
pgpZZNY9AlJz2.pgp
Description: OpenPGP digital signature
Re: [PATCH] cpufreq: kryo: Add module remove and exit
On 07-06-18, 20:58, ilia@gmail.com wrote:
> From: Ilia Lin
>
> Add device remove and module exit code to make the driver
> functioning as a loadable module.
>
> Fixes: ac28927659be (cpufreq: kryo: allow building as a loadable module)
> Signed-off-by: Ilia Lin
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
> b/drivers/cpufreq/qcom-cpufreq-kryo.c
> index d049fe4b80c4..a08de0253169 100644
> --- a/drivers/cpufreq/qcom-cpufreq-kryo.c
> +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
> @@ -71,10 +71,10 @@ static enum _msm8996_version __init
> qcom_cpufreq_kryo_get_msm_id(void)
> return version;
> }
>
> +struct platform_device *cpufreq_dt_pdev;
Move this and the other platform device pointer at the top of the file after the
enum declarations. They don't look nice in the middle of nowhere.
> static int qcom_cpufreq_kryo_probe(struct platform_device *pdev)
> {
> struct opp_table *opp_tables[NR_CPUS] = {0};
> - struct platform_device *cpufreq_dt_pdev;
> enum _msm8996_version msm8996_version;
> struct nvmem_cell *speedbin_nvmem;
> struct device_node *np;
> @@ -115,6 +115,8 @@ static int qcom_cpufreq_kryo_probe(struct platform_device
> *pdev)
>
> speedbin = nvmem_cell_read(speedbin_nvmem, );
> nvmem_cell_put(speedbin_nvmem);
> + if (IS_ERR(speedbin))
> + return PTR_ERR(speedbin);
This doesn't look related to this patch. Should it be a different commit ?
And I just saw definition of nvmem_cell_read() and it says the returned buffer
must be freed by caller using kfree(). I dont' see you doing that. Please also
check if any other such resources are there which you forgot to free.
>
> switch (msm8996_version) {
> case MSM8996_V3:
> @@ -162,8 +164,15 @@ static int qcom_cpufreq_kryo_probe(struct
> platform_device *pdev)
> return ret;
> }
>
> +static int qcom_cpufreq_kryo_remove(struct platform_device *pdev)
> +{
> + platform_device_unregister(cpufreq_dt_pdev);
> + return 0;
> +}
> +
> static struct platform_driver qcom_cpufreq_kryo_driver = {
> .probe = qcom_cpufreq_kryo_probe,
> + .remove = qcom_cpufreq_kryo_remove,
> .driver = {
> .name = "qcom-cpufreq-kryo",
> },
> @@ -174,6 +183,7 @@ static const struct of_device_id
> qcom_cpufreq_kryo_match_list[] __initconst = {
> { .compatible = "qcom,msm8996", },
> };
>
> +struct platform_device *kryo_cpufreq_pdev;
> /*
> * Since the driver depends on smem and nvmem drivers, which may
> * return EPROBE_DEFER, all the real activity is done in the probe,
> @@ -198,8 +208,9 @@ static int __init qcom_cpufreq_kryo_init(void)
> if (unlikely(ret < 0))
> return ret;
>
> - ret = PTR_ERR_OR_ZERO(platform_device_register_simple(
> - "qcom-cpufreq-kryo", -1, NULL, 0));
> + kryo_cpufreq_pdev = platform_device_register_simple(
> + "qcom-cpufreq-kryo", -1, NULL, 0);
> + ret = PTR_ERR_OR_ZERO(kryo_cpufreq_pdev);
> if (0 == ret)
> return 0;
>
> @@ -208,5 +219,12 @@ static int __init qcom_cpufreq_kryo_init(void)
> }
> module_init(qcom_cpufreq_kryo_init);
>
> +static void __init qcom_cpufreq_kryo_exit(void)
> +{
> + platform_device_unregister(kryo_cpufreq_pdev);
> + platform_driver_unregister(_cpufreq_kryo_driver);
> +}
> +module_exit(qcom_cpufreq_kryo_exit);
> +
> MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
> MODULE_LICENSE("GPL v2");
--
viresh
Re: [PATCH] cpufreq: kryo: Add module remove and exit
On 07-06-18, 20:58, ilia@gmail.com wrote:
> From: Ilia Lin
>
> Add device remove and module exit code to make the driver
> functioning as a loadable module.
>
> Fixes: ac28927659be (cpufreq: kryo: allow building as a loadable module)
> Signed-off-by: Ilia Lin
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
> b/drivers/cpufreq/qcom-cpufreq-kryo.c
> index d049fe4b80c4..a08de0253169 100644
> --- a/drivers/cpufreq/qcom-cpufreq-kryo.c
> +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
> @@ -71,10 +71,10 @@ static enum _msm8996_version __init
> qcom_cpufreq_kryo_get_msm_id(void)
> return version;
> }
>
> +struct platform_device *cpufreq_dt_pdev;
Move this and the other platform device pointer at the top of the file after the
enum declarations. They don't look nice in the middle of nowhere.
> static int qcom_cpufreq_kryo_probe(struct platform_device *pdev)
> {
> struct opp_table *opp_tables[NR_CPUS] = {0};
> - struct platform_device *cpufreq_dt_pdev;
> enum _msm8996_version msm8996_version;
> struct nvmem_cell *speedbin_nvmem;
> struct device_node *np;
> @@ -115,6 +115,8 @@ static int qcom_cpufreq_kryo_probe(struct platform_device
> *pdev)
>
> speedbin = nvmem_cell_read(speedbin_nvmem, );
> nvmem_cell_put(speedbin_nvmem);
> + if (IS_ERR(speedbin))
> + return PTR_ERR(speedbin);
This doesn't look related to this patch. Should it be a different commit ?
And I just saw definition of nvmem_cell_read() and it says the returned buffer
must be freed by caller using kfree(). I dont' see you doing that. Please also
check if any other such resources are there which you forgot to free.
>
> switch (msm8996_version) {
> case MSM8996_V3:
> @@ -162,8 +164,15 @@ static int qcom_cpufreq_kryo_probe(struct
> platform_device *pdev)
> return ret;
> }
>
> +static int qcom_cpufreq_kryo_remove(struct platform_device *pdev)
> +{
> + platform_device_unregister(cpufreq_dt_pdev);
> + return 0;
> +}
> +
> static struct platform_driver qcom_cpufreq_kryo_driver = {
> .probe = qcom_cpufreq_kryo_probe,
> + .remove = qcom_cpufreq_kryo_remove,
> .driver = {
> .name = "qcom-cpufreq-kryo",
> },
> @@ -174,6 +183,7 @@ static const struct of_device_id
> qcom_cpufreq_kryo_match_list[] __initconst = {
> { .compatible = "qcom,msm8996", },
> };
>
> +struct platform_device *kryo_cpufreq_pdev;
> /*
> * Since the driver depends on smem and nvmem drivers, which may
> * return EPROBE_DEFER, all the real activity is done in the probe,
> @@ -198,8 +208,9 @@ static int __init qcom_cpufreq_kryo_init(void)
> if (unlikely(ret < 0))
> return ret;
>
> - ret = PTR_ERR_OR_ZERO(platform_device_register_simple(
> - "qcom-cpufreq-kryo", -1, NULL, 0));
> + kryo_cpufreq_pdev = platform_device_register_simple(
> + "qcom-cpufreq-kryo", -1, NULL, 0);
> + ret = PTR_ERR_OR_ZERO(kryo_cpufreq_pdev);
> if (0 == ret)
> return 0;
>
> @@ -208,5 +219,12 @@ static int __init qcom_cpufreq_kryo_init(void)
> }
> module_init(qcom_cpufreq_kryo_init);
>
> +static void __init qcom_cpufreq_kryo_exit(void)
> +{
> + platform_device_unregister(kryo_cpufreq_pdev);
> + platform_driver_unregister(_cpufreq_kryo_driver);
> +}
> +module_exit(qcom_cpufreq_kryo_exit);
> +
> MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
> MODULE_LICENSE("GPL v2");
--
viresh
Re: [PATCH 6/6] Convert intel uncore to struct_size
Hi Matthew,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180607]
[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/Matthew-Wilcox/More-conversions-to-struct_size/20180608-112654
config: x86_64-randconfig-x016-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
arch/x86/events/intel/uncore.c: In function 'uncore_type_init':
>> arch/x86/events/intel/uncore.c:838:24: error: implicit declaration of
>> function 'struct_size' [-Werror=implicit-function-declaration]
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^~~
arch/x86/events/intel/uncore.c:838:48: error: 'attrs' undeclared (first use
in this function); did you mean 'iattr'?
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^
iattr
arch/x86/events/intel/uncore.c:838:48: note: each undeclared identifier is
reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +/struct_size +838 arch/x86/events/intel/uncore.c
804
805 static int __init uncore_type_init(struct intel_uncore_type *type, bool
setid)
806 {
807 struct intel_uncore_pmu *pmus;
808 size_t size;
809 int i, j;
810
811 pmus = kzalloc(sizeof(*pmus) * type->num_boxes, GFP_KERNEL);
812 if (!pmus)
813 return -ENOMEM;
814
815 size = max_packages * sizeof(struct intel_uncore_box *);
816
817 for (i = 0; i < type->num_boxes; i++) {
818 pmus[i].func_id = setid ? i : -1;
819 pmus[i].pmu_idx = i;
820 pmus[i].type= type;
821 pmus[i].boxes = kzalloc(size, GFP_KERNEL);
822 if (!pmus[i].boxes)
823 goto err;
824 }
825
826 type->pmus = pmus;
827 type->unconstrainted = (struct event_constraint)
828 __EVENT_CONSTRAINT(0, (1ULL << type->num_counters) - 1,
829 0, type->num_counters, 0, 0);
830
831 if (type->event_descs) {
832 struct {
833 struct attribute_group group;
834 struct attribute *attrs[];
835 } *attr_group;
836 for (i = 0; type->event_descs[i].attr.attr.name; i++);
837
> 838 attr_group = kzalloc(struct_size(attr_group, attrs, i +
> 1),
839
GFP_KERNEL);
840 if (!attr_group)
841 goto err;
842
843 attr_group->group.name = "events";
844 attr_group->group.attrs = attr_group->attrs;
845
846 for (j = 0; j < i; j++)
847 attr_group->attrs[j] =
>event_descs[j].attr.attr;
848
849 type->events_group = _group->group;
850 }
851
852 type->pmu_group = _pmu_attr_group;
853
854 return 0;
855
856 err:
857 for (i = 0; i < type->num_boxes; i++)
858 kfree(pmus[i].boxes);
859 kfree(pmus);
860
861 return -ENOMEM;
862 }
863
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 6/6] Convert intel uncore to struct_size
Hi Matthew,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180607]
[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/Matthew-Wilcox/More-conversions-to-struct_size/20180608-112654
config: x86_64-randconfig-x016-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
arch/x86/events/intel/uncore.c: In function 'uncore_type_init':
>> arch/x86/events/intel/uncore.c:838:24: error: implicit declaration of
>> function 'struct_size' [-Werror=implicit-function-declaration]
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^~~
arch/x86/events/intel/uncore.c:838:48: error: 'attrs' undeclared (first use
in this function); did you mean 'iattr'?
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^
iattr
arch/x86/events/intel/uncore.c:838:48: note: each undeclared identifier is
reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +/struct_size +838 arch/x86/events/intel/uncore.c
804
805 static int __init uncore_type_init(struct intel_uncore_type *type, bool
setid)
806 {
807 struct intel_uncore_pmu *pmus;
808 size_t size;
809 int i, j;
810
811 pmus = kzalloc(sizeof(*pmus) * type->num_boxes, GFP_KERNEL);
812 if (!pmus)
813 return -ENOMEM;
814
815 size = max_packages * sizeof(struct intel_uncore_box *);
816
817 for (i = 0; i < type->num_boxes; i++) {
818 pmus[i].func_id = setid ? i : -1;
819 pmus[i].pmu_idx = i;
820 pmus[i].type= type;
821 pmus[i].boxes = kzalloc(size, GFP_KERNEL);
822 if (!pmus[i].boxes)
823 goto err;
824 }
825
826 type->pmus = pmus;
827 type->unconstrainted = (struct event_constraint)
828 __EVENT_CONSTRAINT(0, (1ULL << type->num_counters) - 1,
829 0, type->num_counters, 0, 0);
830
831 if (type->event_descs) {
832 struct {
833 struct attribute_group group;
834 struct attribute *attrs[];
835 } *attr_group;
836 for (i = 0; type->event_descs[i].attr.attr.name; i++);
837
> 838 attr_group = kzalloc(struct_size(attr_group, attrs, i +
> 1),
839
GFP_KERNEL);
840 if (!attr_group)
841 goto err;
842
843 attr_group->group.name = "events";
844 attr_group->group.attrs = attr_group->attrs;
845
846 for (j = 0; j < i; j++)
847 attr_group->attrs[j] =
>event_descs[j].attr.attr;
848
849 type->events_group = _group->group;
850 }
851
852 type->pmu_group = _pmu_attr_group;
853
854 return 0;
855
856 err:
857 for (i = 0; i < type->num_boxes; i++)
858 kfree(pmus[i].boxes);
859 kfree(pmus);
860
861 return -ENOMEM;
862 }
863
---
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] sched: cpufreq: Fix long idle judgement logic in load calculation
On 08-06-18, 09:07, Chen Yu wrote: > According to current code implementation, detecting the long > idle period is done by checking if the interval between two > adjacent utilization update handers is long enough. Although > this mechanism can detect if the idle period is long enough > (no utilization hooks invoked during idle period), it might > not contain a corner case: if the task has occupied the cpu > for too long which causes no context switch during that > period, then no utilization handler will be launched until this > high prio task is switched out. As a result, the idle_periods > field might be calculated incorrectly because it regards the > 100% load as 0% and makes the conservative governor who uses > this field confusing. > > Change the judgement to compare the idle_time with sampling_rate > directly. > > Reported-by: Artem S. Tashkinov > Cc: Artem S Tashkinov > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: linux...@vger.kernel.org > Signed-off-by: Chen Yu > --- > v2: Per Viresh's suggestion, ignore idle_time longer than 30mins and > simplify the code. > --- > drivers/cpufreq/cpufreq_governor.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH][v2] sched: cpufreq: Fix long idle judgement logic in load calculation
On 08-06-18, 09:07, Chen Yu wrote: > According to current code implementation, detecting the long > idle period is done by checking if the interval between two > adjacent utilization update handers is long enough. Although > this mechanism can detect if the idle period is long enough > (no utilization hooks invoked during idle period), it might > not contain a corner case: if the task has occupied the cpu > for too long which causes no context switch during that > period, then no utilization handler will be launched until this > high prio task is switched out. As a result, the idle_periods > field might be calculated incorrectly because it regards the > 100% load as 0% and makes the conservative governor who uses > this field confusing. > > Change the judgement to compare the idle_time with sampling_rate > directly. > > Reported-by: Artem S. Tashkinov > Cc: Artem S Tashkinov > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: linux...@vger.kernel.org > Signed-off-by: Chen Yu > --- > v2: Per Viresh's suggestion, ignore idle_time longer than 30mins and > simplify the code. > --- > drivers/cpufreq/cpufreq_governor.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH 3/6] Convert v4l2 event to struct_size
Hi Matthew,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180607]
[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/Matthew-Wilcox/More-conversions-to-struct_size/20180608-112654
config: x86_64-randconfig-x017-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/media/v4l2-core/v4l2-event.c: In function 'v4l2_event_subscribe':
>> drivers/media/v4l2-core/v4l2-event.c:218:17: error: implicit declaration of
>> function 'struct_size'; did you mean 'resource_size'?
>> [-Werror=implicit-function-declaration]
sev = kvzalloc(struct_size(sev, events, elems), GFP_KERNEL);
^~~
resource_size
drivers/media/v4l2-core/v4l2-event.c:218:34: error: 'events' undeclared
(first use in this function); did you mean 'elems'?
sev = kvzalloc(struct_size(sev, events, elems), GFP_KERNEL);
^~
elems
drivers/media/v4l2-core/v4l2-event.c:218:34: note: each undeclared
identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +218 drivers/media/v4l2-core/v4l2-event.c
203
204 int v4l2_event_subscribe(struct v4l2_fh *fh,
205 const struct v4l2_event_subscription *sub,
unsigned elems,
206 const struct v4l2_subscribed_event_ops *ops)
207 {
208 struct v4l2_subscribed_event *sev, *found_ev;
209 unsigned long flags;
210 unsigned i;
211
212 if (sub->type == V4L2_EVENT_ALL)
213 return -EINVAL;
214
215 if (elems < 1)
216 elems = 1;
217
> 218 sev = kvzalloc(struct_size(sev, events, elems), GFP_KERNEL);
219 if (!sev)
220 return -ENOMEM;
221 for (i = 0; i < elems; i++)
222 sev->events[i].sev = sev;
223 sev->type = sub->type;
224 sev->id = sub->id;
225 sev->flags = sub->flags;
226 sev->fh = fh;
227 sev->ops = ops;
228
229 spin_lock_irqsave(>vdev->fh_lock, flags);
230 found_ev = v4l2_event_subscribed(fh, sub->type, sub->id);
231 if (!found_ev)
232 list_add(>list, >subscribed);
233 spin_unlock_irqrestore(>vdev->fh_lock, flags);
234
235 if (found_ev) {
236 kvfree(sev);
237 return 0; /* Already listening */
238 }
239
240 if (sev->ops && sev->ops->add) {
241 int ret = sev->ops->add(sev, elems);
242 if (ret) {
243 sev->ops = NULL;
244 v4l2_event_unsubscribe(fh, sub);
245 return ret;
246 }
247 }
248
249 /* Mark as ready for use */
250 sev->elems = elems;
251
252 return 0;
253 }
254 EXPORT_SYMBOL_GPL(v4l2_event_subscribe);
255
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 6/6] Convert intel uncore to struct_size
Hi Matthew,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180607]
[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/Matthew-Wilcox/More-conversions-to-struct_size/20180608-112654
config: x86_64-randconfig-x015-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
arch/x86/events/intel/uncore.c: In function 'uncore_type_init':
>> arch/x86/events/intel/uncore.c:838:24: error: implicit declaration of
>> function 'struct_size'; did you mean 'bd_set_size'?
>> [-Werror=implicit-function-declaration]
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^~~
bd_set_size
>> arch/x86/events/intel/uncore.c:838:48: error: 'attrs' undeclared (first use
>> in this function); did you mean 'iattr'?
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^
iattr
arch/x86/events/intel/uncore.c:838:48: note: each undeclared identifier is
reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +838 arch/x86/events/intel/uncore.c
804
805 static int __init uncore_type_init(struct intel_uncore_type *type, bool
setid)
806 {
807 struct intel_uncore_pmu *pmus;
808 size_t size;
809 int i, j;
810
811 pmus = kzalloc(sizeof(*pmus) * type->num_boxes, GFP_KERNEL);
812 if (!pmus)
813 return -ENOMEM;
814
815 size = max_packages * sizeof(struct intel_uncore_box *);
816
817 for (i = 0; i < type->num_boxes; i++) {
818 pmus[i].func_id = setid ? i : -1;
819 pmus[i].pmu_idx = i;
820 pmus[i].type= type;
821 pmus[i].boxes = kzalloc(size, GFP_KERNEL);
822 if (!pmus[i].boxes)
823 goto err;
824 }
825
826 type->pmus = pmus;
827 type->unconstrainted = (struct event_constraint)
828 __EVENT_CONSTRAINT(0, (1ULL << type->num_counters) - 1,
829 0, type->num_counters, 0, 0);
830
831 if (type->event_descs) {
832 struct {
833 struct attribute_group group;
834 struct attribute *attrs[];
835 } *attr_group;
836 for (i = 0; type->event_descs[i].attr.attr.name; i++);
837
> 838 attr_group = kzalloc(struct_size(attr_group, attrs, i +
> 1),
839
GFP_KERNEL);
840 if (!attr_group)
841 goto err;
842
843 attr_group->group.name = "events";
844 attr_group->group.attrs = attr_group->attrs;
845
846 for (j = 0; j < i; j++)
847 attr_group->attrs[j] =
>event_descs[j].attr.attr;
848
849 type->events_group = _group->group;
850 }
851
852 type->pmu_group = _pmu_attr_group;
853
854 return 0;
855
856 err:
857 for (i = 0; i < type->num_boxes; i++)
858 kfree(pmus[i].boxes);
859 kfree(pmus);
860
861 return -ENOMEM;
862 }
863
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 3/6] Convert v4l2 event to struct_size
Hi Matthew,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180607]
[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/Matthew-Wilcox/More-conversions-to-struct_size/20180608-112654
config: x86_64-randconfig-x017-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/media/v4l2-core/v4l2-event.c: In function 'v4l2_event_subscribe':
>> drivers/media/v4l2-core/v4l2-event.c:218:17: error: implicit declaration of
>> function 'struct_size'; did you mean 'resource_size'?
>> [-Werror=implicit-function-declaration]
sev = kvzalloc(struct_size(sev, events, elems), GFP_KERNEL);
^~~
resource_size
drivers/media/v4l2-core/v4l2-event.c:218:34: error: 'events' undeclared
(first use in this function); did you mean 'elems'?
sev = kvzalloc(struct_size(sev, events, elems), GFP_KERNEL);
^~
elems
drivers/media/v4l2-core/v4l2-event.c:218:34: note: each undeclared
identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +218 drivers/media/v4l2-core/v4l2-event.c
203
204 int v4l2_event_subscribe(struct v4l2_fh *fh,
205 const struct v4l2_event_subscription *sub,
unsigned elems,
206 const struct v4l2_subscribed_event_ops *ops)
207 {
208 struct v4l2_subscribed_event *sev, *found_ev;
209 unsigned long flags;
210 unsigned i;
211
212 if (sub->type == V4L2_EVENT_ALL)
213 return -EINVAL;
214
215 if (elems < 1)
216 elems = 1;
217
> 218 sev = kvzalloc(struct_size(sev, events, elems), GFP_KERNEL);
219 if (!sev)
220 return -ENOMEM;
221 for (i = 0; i < elems; i++)
222 sev->events[i].sev = sev;
223 sev->type = sub->type;
224 sev->id = sub->id;
225 sev->flags = sub->flags;
226 sev->fh = fh;
227 sev->ops = ops;
228
229 spin_lock_irqsave(>vdev->fh_lock, flags);
230 found_ev = v4l2_event_subscribed(fh, sub->type, sub->id);
231 if (!found_ev)
232 list_add(>list, >subscribed);
233 spin_unlock_irqrestore(>vdev->fh_lock, flags);
234
235 if (found_ev) {
236 kvfree(sev);
237 return 0; /* Already listening */
238 }
239
240 if (sev->ops && sev->ops->add) {
241 int ret = sev->ops->add(sev, elems);
242 if (ret) {
243 sev->ops = NULL;
244 v4l2_event_unsubscribe(fh, sub);
245 return ret;
246 }
247 }
248
249 /* Mark as ready for use */
250 sev->elems = elems;
251
252 return 0;
253 }
254 EXPORT_SYMBOL_GPL(v4l2_event_subscribe);
255
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 6/6] Convert intel uncore to struct_size
Hi Matthew,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180607]
[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/Matthew-Wilcox/More-conversions-to-struct_size/20180608-112654
config: x86_64-randconfig-x015-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
arch/x86/events/intel/uncore.c: In function 'uncore_type_init':
>> arch/x86/events/intel/uncore.c:838:24: error: implicit declaration of
>> function 'struct_size'; did you mean 'bd_set_size'?
>> [-Werror=implicit-function-declaration]
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^~~
bd_set_size
>> arch/x86/events/intel/uncore.c:838:48: error: 'attrs' undeclared (first use
>> in this function); did you mean 'iattr'?
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^
iattr
arch/x86/events/intel/uncore.c:838:48: note: each undeclared identifier is
reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +838 arch/x86/events/intel/uncore.c
804
805 static int __init uncore_type_init(struct intel_uncore_type *type, bool
setid)
806 {
807 struct intel_uncore_pmu *pmus;
808 size_t size;
809 int i, j;
810
811 pmus = kzalloc(sizeof(*pmus) * type->num_boxes, GFP_KERNEL);
812 if (!pmus)
813 return -ENOMEM;
814
815 size = max_packages * sizeof(struct intel_uncore_box *);
816
817 for (i = 0; i < type->num_boxes; i++) {
818 pmus[i].func_id = setid ? i : -1;
819 pmus[i].pmu_idx = i;
820 pmus[i].type= type;
821 pmus[i].boxes = kzalloc(size, GFP_KERNEL);
822 if (!pmus[i].boxes)
823 goto err;
824 }
825
826 type->pmus = pmus;
827 type->unconstrainted = (struct event_constraint)
828 __EVENT_CONSTRAINT(0, (1ULL << type->num_counters) - 1,
829 0, type->num_counters, 0, 0);
830
831 if (type->event_descs) {
832 struct {
833 struct attribute_group group;
834 struct attribute *attrs[];
835 } *attr_group;
836 for (i = 0; type->event_descs[i].attr.attr.name; i++);
837
> 838 attr_group = kzalloc(struct_size(attr_group, attrs, i +
> 1),
839
GFP_KERNEL);
840 if (!attr_group)
841 goto err;
842
843 attr_group->group.name = "events";
844 attr_group->group.attrs = attr_group->attrs;
845
846 for (j = 0; j < i; j++)
847 attr_group->attrs[j] =
>event_descs[j].attr.attr;
848
849 type->events_group = _group->group;
850 }
851
852 type->pmu_group = _pmu_attr_group;
853
854 return 0;
855
856 err:
857 for (i = 0; i < type->num_boxes; i++)
858 kfree(pmus[i].boxes);
859 kfree(pmus);
860
861 return -ENOMEM;
862 }
863
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
linux-next: build warning after merge of the random tree
Hi Theodore,
After merging the random tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
lib/vsprintf.c:1668:13: warning: 'have_filled_random_ptr_key' defined but not
used [-Wunused-variable]
static bool have_filled_random_ptr_key __read_mostly;
^~
Introduced by commit
bfe80ed3d7c7 ("vsprintf: add command line option debug_boot_weak_hash")
--
Cheers,
Stephen Rothwell
pgpS1IXSQVb8z.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the random tree
Hi Theodore,
After merging the random tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
lib/vsprintf.c:1668:13: warning: 'have_filled_random_ptr_key' defined but not
used [-Wunused-variable]
static bool have_filled_random_ptr_key __read_mostly;
^~
Introduced by commit
bfe80ed3d7c7 ("vsprintf: add command line option debug_boot_weak_hash")
--
Cheers,
Stephen Rothwell
pgpS1IXSQVb8z.pgp
Description: OpenPGP digital signature
Proposal
-- Good day, i know you do not know me personally but i have checked your profile and i see generosity in you, There's an urgent offer attach to your name here in the office of Mr. Fawaz KhE. Al Saleh Member of the Board of Directors, Kuveyt Türk Participation Bank (Turkey) and head of private banking and wealth management Regards, Mr. Fawaz KhE. Al Saleh
[PATCH v2 09/12] macintosh/via-pmu: Replace via-pmu68k driver with via-pmu driver
Now that the PowerMac via-pmu driver supports m68k PowerBooks,
switch over to that driver and remove the via-pmu68k driver.
Cc: Geert Uytterhoeven
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/m68k/configs/mac_defconfig | 2 +-
arch/m68k/configs/multi_defconfig | 2 +-
arch/m68k/mac/config.c| 2 +-
arch/m68k/mac/misc.c | 48 +--
drivers/macintosh/Kconfig | 13 +-
drivers/macintosh/Makefile| 1 -
drivers/macintosh/adb.c | 2 +-
drivers/macintosh/via-pmu68k.c| 846 --
include/uapi/linux/pmu.h | 1 -
9 files changed, 13 insertions(+), 904 deletions(-)
delete mode 100644 drivers/macintosh/via-pmu68k.c
diff --git a/arch/m68k/configs/mac_defconfig b/arch/m68k/configs/mac_defconfig
index 390d4a87441c..ee63f1242e9a 100644
--- a/arch/m68k/configs/mac_defconfig
+++ b/arch/m68k/configs/mac_defconfig
@@ -370,7 +370,7 @@ CONFIG_TCM_PSCSI=m
CONFIG_ADB=y
CONFIG_ADB_MACII=y
CONFIG_ADB_IOP=y
-CONFIG_ADB_PMU68K=y
+CONFIG_ADB_PMU=y
CONFIG_ADB_CUDA=y
CONFIG_INPUT_ADBHID=y
CONFIG_MAC_EMUMOUSEBTN=y
diff --git a/arch/m68k/configs/multi_defconfig
b/arch/m68k/configs/multi_defconfig
index 77be97d82dc3..6421a3da616c 100644
--- a/arch/m68k/configs/multi_defconfig
+++ b/arch/m68k/configs/multi_defconfig
@@ -403,7 +403,7 @@ CONFIG_TCM_PSCSI=m
CONFIG_ADB=y
CONFIG_ADB_MACII=y
CONFIG_ADB_IOP=y
-CONFIG_ADB_PMU68K=y
+CONFIG_ADB_PMU=y
CONFIG_ADB_CUDA=y
CONFIG_INPUT_ADBHID=y
CONFIG_MAC_EMUMOUSEBTN=y
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index e522307db47c..92e80cf0d8aa 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -891,7 +891,7 @@ static void __init mac_identify(void)
#ifdef CONFIG_ADB_CUDA
find_via_cuda();
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
find_via_pmu();
#endif
}
diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c
index 7ccb799eeb57..28090a44fa09 100644
--- a/arch/m68k/mac/misc.c
+++ b/arch/m68k/mac/misc.c
@@ -85,7 +85,7 @@ static void cuda_write_pram(int offset, __u8 data)
}
#endif /* CONFIG_ADB_CUDA */
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
static long pmu_read_time(void)
{
struct adb_request req;
@@ -136,7 +136,7 @@ static void pmu_write_pram(int offset, __u8 data)
while (!req.complete)
pmu_poll();
}
-#endif /* CONFIG_ADB_PMU68K */
+#endif /* CONFIG_ADB_PMU */
/*
* VIA PRAM/RTC access routines
@@ -367,38 +367,6 @@ static void cuda_shutdown(void)
}
#endif /* CONFIG_ADB_CUDA */
-#ifdef CONFIG_ADB_PMU68K
-
-void pmu_restart(void)
-{
- struct adb_request req;
- if (pmu_request(, NULL,
- 2, PMU_SET_INTR_MASK, PMU_INT_ADB|PMU_INT_TICK) < 0)
- return;
- while (!req.complete)
- pmu_poll();
- if (pmu_request(, NULL, 1, PMU_RESET) < 0)
- return;
- while (!req.complete)
- pmu_poll();
-}
-
-void pmu_shutdown(void)
-{
- struct adb_request req;
- if (pmu_request(, NULL,
- 2, PMU_SET_INTR_MASK, PMU_INT_ADB|PMU_INT_TICK) < 0)
- return;
- while (!req.complete)
- pmu_poll();
- if (pmu_request(, NULL, 5, PMU_SHUTDOWN, 'M', 'A', 'T', 'T') < 0)
- return;
- while (!req.complete)
- pmu_poll();
-}
-
-#endif
-
/*
*---
* Below this point are the generic routines; they'll dispatch to the
@@ -423,7 +391,7 @@ void mac_pram_read(int offset, __u8 *buffer, int len)
func = cuda_read_pram;
break;
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
case MAC_ADB_PB2:
func = pmu_read_pram;
break;
@@ -453,7 +421,7 @@ void mac_pram_write(int offset, __u8 *buffer, int len)
func = cuda_write_pram;
break;
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
case MAC_ADB_PB2:
func = pmu_write_pram;
break;
@@ -477,7 +445,7 @@ void mac_poweroff(void)
macintosh_config->adb_type == MAC_ADB_CUDA) {
cuda_shutdown();
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
} else if (macintosh_config->adb_type == MAC_ADB_PB2) {
pmu_shutdown();
#endif
@@ -518,7 +486,7 @@ void mac_reset(void)
macintosh_config->adb_type == MAC_ADB_CUDA) {
cuda_restart();
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
} else if (macintosh_config->adb_type == MAC_ADB_PB2) {
pmu_restart();
#endif
@@ -670,7 +638,7 @@ int mac_hwclk(int op, struct rtc_time *t)
now = cuda_read_time();
break;
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
case MAC_ADB_PB2:
now =
Proposal
-- Good day, i know you do not know me personally but i have checked your profile and i see generosity in you, There's an urgent offer attach to your name here in the office of Mr. Fawaz KhE. Al Saleh Member of the Board of Directors, Kuveyt Türk Participation Bank (Turkey) and head of private banking and wealth management Regards, Mr. Fawaz KhE. Al Saleh
[PATCH v2 09/12] macintosh/via-pmu: Replace via-pmu68k driver with via-pmu driver
Now that the PowerMac via-pmu driver supports m68k PowerBooks,
switch over to that driver and remove the via-pmu68k driver.
Cc: Geert Uytterhoeven
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/m68k/configs/mac_defconfig | 2 +-
arch/m68k/configs/multi_defconfig | 2 +-
arch/m68k/mac/config.c| 2 +-
arch/m68k/mac/misc.c | 48 +--
drivers/macintosh/Kconfig | 13 +-
drivers/macintosh/Makefile| 1 -
drivers/macintosh/adb.c | 2 +-
drivers/macintosh/via-pmu68k.c| 846 --
include/uapi/linux/pmu.h | 1 -
9 files changed, 13 insertions(+), 904 deletions(-)
delete mode 100644 drivers/macintosh/via-pmu68k.c
diff --git a/arch/m68k/configs/mac_defconfig b/arch/m68k/configs/mac_defconfig
index 390d4a87441c..ee63f1242e9a 100644
--- a/arch/m68k/configs/mac_defconfig
+++ b/arch/m68k/configs/mac_defconfig
@@ -370,7 +370,7 @@ CONFIG_TCM_PSCSI=m
CONFIG_ADB=y
CONFIG_ADB_MACII=y
CONFIG_ADB_IOP=y
-CONFIG_ADB_PMU68K=y
+CONFIG_ADB_PMU=y
CONFIG_ADB_CUDA=y
CONFIG_INPUT_ADBHID=y
CONFIG_MAC_EMUMOUSEBTN=y
diff --git a/arch/m68k/configs/multi_defconfig
b/arch/m68k/configs/multi_defconfig
index 77be97d82dc3..6421a3da616c 100644
--- a/arch/m68k/configs/multi_defconfig
+++ b/arch/m68k/configs/multi_defconfig
@@ -403,7 +403,7 @@ CONFIG_TCM_PSCSI=m
CONFIG_ADB=y
CONFIG_ADB_MACII=y
CONFIG_ADB_IOP=y
-CONFIG_ADB_PMU68K=y
+CONFIG_ADB_PMU=y
CONFIG_ADB_CUDA=y
CONFIG_INPUT_ADBHID=y
CONFIG_MAC_EMUMOUSEBTN=y
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index e522307db47c..92e80cf0d8aa 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -891,7 +891,7 @@ static void __init mac_identify(void)
#ifdef CONFIG_ADB_CUDA
find_via_cuda();
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
find_via_pmu();
#endif
}
diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c
index 7ccb799eeb57..28090a44fa09 100644
--- a/arch/m68k/mac/misc.c
+++ b/arch/m68k/mac/misc.c
@@ -85,7 +85,7 @@ static void cuda_write_pram(int offset, __u8 data)
}
#endif /* CONFIG_ADB_CUDA */
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
static long pmu_read_time(void)
{
struct adb_request req;
@@ -136,7 +136,7 @@ static void pmu_write_pram(int offset, __u8 data)
while (!req.complete)
pmu_poll();
}
-#endif /* CONFIG_ADB_PMU68K */
+#endif /* CONFIG_ADB_PMU */
/*
* VIA PRAM/RTC access routines
@@ -367,38 +367,6 @@ static void cuda_shutdown(void)
}
#endif /* CONFIG_ADB_CUDA */
-#ifdef CONFIG_ADB_PMU68K
-
-void pmu_restart(void)
-{
- struct adb_request req;
- if (pmu_request(, NULL,
- 2, PMU_SET_INTR_MASK, PMU_INT_ADB|PMU_INT_TICK) < 0)
- return;
- while (!req.complete)
- pmu_poll();
- if (pmu_request(, NULL, 1, PMU_RESET) < 0)
- return;
- while (!req.complete)
- pmu_poll();
-}
-
-void pmu_shutdown(void)
-{
- struct adb_request req;
- if (pmu_request(, NULL,
- 2, PMU_SET_INTR_MASK, PMU_INT_ADB|PMU_INT_TICK) < 0)
- return;
- while (!req.complete)
- pmu_poll();
- if (pmu_request(, NULL, 5, PMU_SHUTDOWN, 'M', 'A', 'T', 'T') < 0)
- return;
- while (!req.complete)
- pmu_poll();
-}
-
-#endif
-
/*
*---
* Below this point are the generic routines; they'll dispatch to the
@@ -423,7 +391,7 @@ void mac_pram_read(int offset, __u8 *buffer, int len)
func = cuda_read_pram;
break;
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
case MAC_ADB_PB2:
func = pmu_read_pram;
break;
@@ -453,7 +421,7 @@ void mac_pram_write(int offset, __u8 *buffer, int len)
func = cuda_write_pram;
break;
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
case MAC_ADB_PB2:
func = pmu_write_pram;
break;
@@ -477,7 +445,7 @@ void mac_poweroff(void)
macintosh_config->adb_type == MAC_ADB_CUDA) {
cuda_shutdown();
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
} else if (macintosh_config->adb_type == MAC_ADB_PB2) {
pmu_shutdown();
#endif
@@ -518,7 +486,7 @@ void mac_reset(void)
macintosh_config->adb_type == MAC_ADB_CUDA) {
cuda_restart();
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
} else if (macintosh_config->adb_type == MAC_ADB_PB2) {
pmu_restart();
#endif
@@ -670,7 +638,7 @@ int mac_hwclk(int op, struct rtc_time *t)
now = cuda_read_time();
break;
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
case MAC_ADB_PB2:
now =
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
Hi Jayant, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17 next-20180607] [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/Jayant-Chowdhary/uapi-Make-generic-uapi-headers-compile-standalone/20180608-014548 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) /usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h:417:9: sparse: preprocessor token offsetof redefined include/linux/stddef.h:17:9: this was the original definition >> drivers/hv/hv_fcopy.c:160:34: sparse: incorrect type in argument 1 >> (different type sizes) @@expected unsigned short const [usertype] *pwcs >> @@got nst [usertype] *pwcs @@ drivers/hv/hv_fcopy.c:160:34:expected unsigned short const [usertype] *pwcs drivers/hv/hv_fcopy.c:160:34:got int [usertype] * drivers/hv/hv_fcopy.c:164:34: sparse: incorrect type in argument 1 (different type sizes) @@expected unsigned short const [usertype] *pwcs @@ got nst [usertype] *pwcs @@ drivers/hv/hv_fcopy.c:164:34:expected unsigned short const [usertype] *pwcs drivers/hv/hv_fcopy.c:164:34:got int [usertype] * -- /usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h:417:9: sparse: preprocessor token offsetof redefined include/linux/stddef.h:17:9: this was the original definition drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
Hi Jayant, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17 next-20180607] [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/Jayant-Chowdhary/uapi-Make-generic-uapi-headers-compile-standalone/20180608-014548 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) /usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h:417:9: sparse: preprocessor token offsetof redefined include/linux/stddef.h:17:9: this was the original definition >> drivers/hv/hv_fcopy.c:160:34: sparse: incorrect type in argument 1 >> (different type sizes) @@expected unsigned short const [usertype] *pwcs >> @@got nst [usertype] *pwcs @@ drivers/hv/hv_fcopy.c:160:34:expected unsigned short const [usertype] *pwcs drivers/hv/hv_fcopy.c:160:34:got int [usertype] * drivers/hv/hv_fcopy.c:164:34: sparse: incorrect type in argument 1 (different type sizes) @@expected unsigned short const [usertype] *pwcs @@ got nst [usertype] *pwcs @@ drivers/hv/hv_fcopy.c:164:34:expected unsigned short const [usertype] *pwcs drivers/hv/hv_fcopy.c:164:34:got int [usertype] * -- /usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h:417:9: sparse: preprocessor token offsetof redefined include/linux/stddef.h:17:9: this was the original definition drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using
Re: [RFC] IB/mad: Use IDR instead of per-port list
On Thu, Jun 07, 2018 at 04:49:26PM -0700, Matthew Wilcox wrote: > On Thu, Jun 07, 2018 at 04:26:46PM -0600, Jason Gunthorpe wrote: > > On Thu, Jun 07, 2018 at 12:08:32PM -0700, Matthew Wilcox wrote: > > > > > > Hans reports a bug where the mlx4 driver uses the MSB of the agent number > > > to store slave number, meaning we can only use agent numbers up to 2^24. > > > Fix this by using an IDR to assign the agent numbers and also look up the > > > agent when a MSD packet is received. > > > > > > I've changed the locking substantially, so this may well have a > > > performance issue. There are a few different possibilities for fixing > > > that, including moving to an RCU-based lookup. > > > > I do like this better than the last series.. > > > > This are is somewhat performance sensitive and it would be nice to > > avoid this global lock. > > OK, I wasn't sure whether it was worth it. > > > What about using a read/write spinlock instead of the IDR internal > > lock? Then all the per-port reading threads calling find_mad_agent can > > run concurrently.. > > It'd be better to switch to RCU ... the IDR is RCU-safe, but the > version/class/method or OUI match isn't. Do you have any feeling on > the relative frequency of the two types of "routing"? I would say they are close to equally important, perhaps the version/class/method is slightly more important. > Actually, I think we can use the radix tree data structure for the > version/class/method too ... that's going to take a little more work. I was wondering about that as well, this code is very old so there must be better data structure helpers these days. Jason
Re: [RFC] IB/mad: Use IDR instead of per-port list
On Thu, Jun 07, 2018 at 04:49:26PM -0700, Matthew Wilcox wrote: > On Thu, Jun 07, 2018 at 04:26:46PM -0600, Jason Gunthorpe wrote: > > On Thu, Jun 07, 2018 at 12:08:32PM -0700, Matthew Wilcox wrote: > > > > > > Hans reports a bug where the mlx4 driver uses the MSB of the agent number > > > to store slave number, meaning we can only use agent numbers up to 2^24. > > > Fix this by using an IDR to assign the agent numbers and also look up the > > > agent when a MSD packet is received. > > > > > > I've changed the locking substantially, so this may well have a > > > performance issue. There are a few different possibilities for fixing > > > that, including moving to an RCU-based lookup. > > > > I do like this better than the last series.. > > > > This are is somewhat performance sensitive and it would be nice to > > avoid this global lock. > > OK, I wasn't sure whether it was worth it. > > > What about using a read/write spinlock instead of the IDR internal > > lock? Then all the per-port reading threads calling find_mad_agent can > > run concurrently.. > > It'd be better to switch to RCU ... the IDR is RCU-safe, but the > version/class/method or OUI match isn't. Do you have any feeling on > the relative frequency of the two types of "routing"? I would say they are close to equally important, perhaps the version/class/method is slightly more important. > Actually, I think we can use the radix tree data structure for the > version/class/method too ... that's going to take a little more work. I was wondering about that as well, this code is very old so there must be better data structure helpers these days. Jason
Re: [PATCH] slab: Clean up the code comment in slab kmem_cache struct
On 06/06/18 at 11:48pm, Christopher Lameter wrote:
> On Wed, 6 Jun 2018, Baoquan He wrote:
>
> > I am back porting Thomas's sl[a|u]b freelist randomization feature to
> > our distros, need go through slab code for better understanding. From
> > git log history, they were 'obj_offset' and 'obj_size'. Later on
> > 'obj_size' was renamed to 'object_size' in commit 3b0efdfa1e("mm, sl[aou]b:
> > Extract common fields from struct kmem_cache") which is from your patch.
> > With my understanding, I guess you changed that on purpose because
> > object_size is size of each object, obj_offset is for the whole cache,
> > representing the offset the real object starts to be stored. And putting
> > them separately is for better desribing them in code comment and
> > distinction, e.g 'object_size' is in "4) cache creation/removal",
> > while 'obj_offset' is put alone to indicate it's for the whole.
>
> obj_offset only applies when CONFIG_SLAB_DEBUG is set. Ok so that screwy
> name also indicates that something special goes on.
They are a little confusing when combine SLAB with SLUB,
SLABSLUB
sizesize
object_size object_size
obj_offset offset
object_size also only applies when CONFIG_SLAB_DEBUG is set,
otherwise it's equal to size in SLAB case. Whereas SLUB always has
object plus freeptr for each object space.
Thought to add code comment to make them clearer, on second thought,
anyone who want to understand slab/slub code well, has to go through the
whole header file and souce code, this pain need be borne.
Re: [PATCH] slab: Clean up the code comment in slab kmem_cache struct
On 06/06/18 at 11:48pm, Christopher Lameter wrote:
> On Wed, 6 Jun 2018, Baoquan He wrote:
>
> > I am back porting Thomas's sl[a|u]b freelist randomization feature to
> > our distros, need go through slab code for better understanding. From
> > git log history, they were 'obj_offset' and 'obj_size'. Later on
> > 'obj_size' was renamed to 'object_size' in commit 3b0efdfa1e("mm, sl[aou]b:
> > Extract common fields from struct kmem_cache") which is from your patch.
> > With my understanding, I guess you changed that on purpose because
> > object_size is size of each object, obj_offset is for the whole cache,
> > representing the offset the real object starts to be stored. And putting
> > them separately is for better desribing them in code comment and
> > distinction, e.g 'object_size' is in "4) cache creation/removal",
> > while 'obj_offset' is put alone to indicate it's for the whole.
>
> obj_offset only applies when CONFIG_SLAB_DEBUG is set. Ok so that screwy
> name also indicates that something special goes on.
They are a little confusing when combine SLAB with SLUB,
SLABSLUB
sizesize
object_size object_size
obj_offset offset
object_size also only applies when CONFIG_SLAB_DEBUG is set,
otherwise it's equal to size in SLAB case. Whereas SLUB always has
object plus freeptr for each object space.
Thought to add code comment to make them clearer, on second thought,
anyone who want to understand slab/slub code well, has to go through the
whole header file and souce code, this pain need be borne.
[PATCH] component: enhance handling of devres group for master
From: Banajit Goswami
The devres group opened for a master is left open-ended (without
devres_group_close) even after bind() is complete. Similarly, while
releasing the devres resources for master, the most recently opened
devres group is selected, and released without identifying the
targeted group. As the devres group opened before master bind was
never closed, there may have unintended consequences of releasing
devres resources that were allocated after master bind() function
was complete.
Change adds a devres_group_close() after bind() call to master, to
encapsulate the resources allocated during bind, and then use a
group ID to specifically identify the group in release, so that
during master unbind, only the resources that are part of that
specific devres group, are released.
Signed-off-by: Banajit Goswami
---
drivers/base/component.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 89b032f..f9ce937 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -155,17 +155,19 @@ static int try_to_bring_up_master(struct master *master,
return 0;
}
- if (!devres_open_group(master->dev, NULL, GFP_KERNEL))
+ if (!devres_open_group(master->dev, master, GFP_KERNEL))
return -ENOMEM;
/* Found all components */
ret = master->ops->bind(master->dev);
if (ret < 0) {
- devres_release_group(master->dev, NULL);
+ devres_release_group(master->dev, master);
dev_info(master->dev, "master bind failed: %d\n", ret);
return ret;
}
+ devres_close_group(master->dev, master);
+
master->bound = true;
return 1;
}
@@ -190,7 +192,7 @@ static void take_down_master(struct master *master)
{
if (master->bound) {
master->ops->unbind(master->dev);
- devres_release_group(master->dev, NULL);
+ devres_release_group(master->dev, master);
master->bound = false;
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] component: enhance handling of devres group for master
From: Banajit Goswami
The devres group opened for a master is left open-ended (without
devres_group_close) even after bind() is complete. Similarly, while
releasing the devres resources for master, the most recently opened
devres group is selected, and released without identifying the
targeted group. As the devres group opened before master bind was
never closed, there may have unintended consequences of releasing
devres resources that were allocated after master bind() function
was complete.
Change adds a devres_group_close() after bind() call to master, to
encapsulate the resources allocated during bind, and then use a
group ID to specifically identify the group in release, so that
during master unbind, only the resources that are part of that
specific devres group, are released.
Signed-off-by: Banajit Goswami
---
drivers/base/component.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 89b032f..f9ce937 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -155,17 +155,19 @@ static int try_to_bring_up_master(struct master *master,
return 0;
}
- if (!devres_open_group(master->dev, NULL, GFP_KERNEL))
+ if (!devres_open_group(master->dev, master, GFP_KERNEL))
return -ENOMEM;
/* Found all components */
ret = master->ops->bind(master->dev);
if (ret < 0) {
- devres_release_group(master->dev, NULL);
+ devres_release_group(master->dev, master);
dev_info(master->dev, "master bind failed: %d\n", ret);
return ret;
}
+ devres_close_group(master->dev, master);
+
master->bound = true;
return 1;
}
@@ -190,7 +192,7 @@ static void take_down_master(struct master *master)
{
if (master->bound) {
master->ops->unbind(master->dev);
- devres_release_group(master->dev, NULL);
+ devres_release_group(master->dev, master);
master->bound = false;
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] fs: reclaim least recently used dquots
From: Greg Thelen
The dquots in the free_dquots list are not reclaimed in LRU way.
put_dquot_last() puts entries to the tail and dqcache_shrink_scan()
frees from the tail. Free unreferenced dquots in LRU order because it
seems more reasonable than freeing most recently used.
Signed-off-by: Greg Thelen
Signed-off-by: Shakeel Butt
---
fs/quota/dquot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index d88231e3b2be..241b00f835b9 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -716,7 +716,7 @@ dqcache_shrink_scan(struct shrinker *shrink, struct
shrink_control *sc)
unsigned long freed = 0;
spin_lock(_list_lock);
- head = free_dquots.prev;
+ head = free_dquots.next;
while (head != _dquots && sc->nr_to_scan) {
dquot = list_entry(head, struct dquot, dq_free);
remove_dquot_hash(dquot);
@@ -725,7 +725,7 @@ dqcache_shrink_scan(struct shrinker *shrink, struct
shrink_control *sc)
do_destroy_dquot(dquot);
sc->nr_to_scan--;
freed++;
- head = free_dquots.prev;
+ head = free_dquots.next;
}
spin_unlock(_list_lock);
return freed;
--
2.18.0.rc1.242.g61856ae69a-goog
[PATCH] fs: reclaim least recently used dquots
From: Greg Thelen
The dquots in the free_dquots list are not reclaimed in LRU way.
put_dquot_last() puts entries to the tail and dqcache_shrink_scan()
frees from the tail. Free unreferenced dquots in LRU order because it
seems more reasonable than freeing most recently used.
Signed-off-by: Greg Thelen
Signed-off-by: Shakeel Butt
---
fs/quota/dquot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index d88231e3b2be..241b00f835b9 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -716,7 +716,7 @@ dqcache_shrink_scan(struct shrinker *shrink, struct
shrink_control *sc)
unsigned long freed = 0;
spin_lock(_list_lock);
- head = free_dquots.prev;
+ head = free_dquots.next;
while (head != _dquots && sc->nr_to_scan) {
dquot = list_entry(head, struct dquot, dq_free);
remove_dquot_hash(dquot);
@@ -725,7 +725,7 @@ dqcache_shrink_scan(struct shrinker *shrink, struct
shrink_control *sc)
do_destroy_dquot(dquot);
sc->nr_to_scan--;
freed++;
- head = free_dquots.prev;
+ head = free_dquots.next;
}
spin_unlock(_list_lock);
return freed;
--
2.18.0.rc1.242.g61856ae69a-goog
Re: [PATCH] md: Unify mddev destruction paths
On 6/7/18 6:52 PM, Kent Overstreet wrote: > Previously, mddev_put() had a couple different paths for freeing a > mddev, due to the fact that the kobject wasn't initialized when the > mddev was first allocated. If we move the kobject_init() to when it's > first allocated and just use kobject_add() later, we can clean all this > up. > > This also removes a hack in mddev_put() to avoid freeing biosets under a > spinlock, which involved copying biosets on the stack after the reset > bioset_init() changes. Looks good to me, much nicer than the previous hack. -- Jens Axboe
Re: [PATCH] md: Unify mddev destruction paths
On 6/7/18 6:52 PM, Kent Overstreet wrote: > Previously, mddev_put() had a couple different paths for freeing a > mddev, due to the fact that the kobject wasn't initialized when the > mddev was first allocated. If we move the kobject_init() to when it's > first allocated and just use kobject_add() later, we can clean all this > up. > > This also removes a hack in mddev_put() to avoid freeing biosets under a > spinlock, which involved copying biosets on the stack after the reset > bioset_init() changes. Looks good to me, much nicer than the previous hack. -- Jens Axboe
Re: [PATCH 3.16 012/410] scsi: libsas: direct call probe and destruct
On 2018/6/8 2:18, Ben Hutchings wrote:
On Thu, 2018-06-07 at 17:32 +0100, John Garry wrote:
On 07/06/2018 15:05, Ben Hutchings wrote:
3.16.57-rc1 review patch. If anyone has any objections, please let me know.
--
Hi Ben,
I noticed that you are looking to backport this patch to 3.16
I am wondering why you are taking this libsas patch (and a couple other
libsas patches) in isolation, when these patches were part of a series
to fix libsas hotplug issues? I'm not sure if cherry-picking certain
patches is ok.
Maybe Jason (cc'ed) can comment further.
This one apparently fixed a security issue (CVE-2017-18232), though I'm
certainly not convinced it's a particularly serious one.
But please send objections to the list, not just privately.
Hi Ben,
This patch is in the series below. I recommend to backport them
together. If you really want to do this, I'm happy to help you to
backport them.
1689c9367bfa scsi: libsas: notify event PORTE_BROADCAST_RCVD in
sas_enable_revalidation()
0558f33c06bb scsi: libsas: direct call probe and destruct
517e5153d242 scsi: libsas: use flush_workqueue to process disco events
synchronously
93bdbd06b164 scsi: libsas: Use new workqueue to run sas event and disco
event
8eea9dd84e45 scsi: libsas: make the event threshold configurable
f12486e06ae8 scsi: libsas: shut down the PHY if events reached the threshold
1c393b970e0f scsi: libsas: Use dynamic alloced work to avoid sas event lost
Ben.
Thanks,
John
From: Jason Yan
commit 0558f33c06bb910e2879e355192227a8e8f0219d upstream.
In commit 87c8331fcf72 ("[SCSI] libsas: prevent domain rediscovery
competing with ata error handling") introduced disco mutex to prevent
rediscovery competing with ata error handling and put the whole
revalidation in the mutex. But the rphy add/remove needs to wait for the
error handling which also grabs the disco mutex. This may leads to dead
lock.So the probe and destruct event were introduce to do the rphy
add/remove asynchronously and out of the lock.
The asynchronously processed workers makes the whole discovery process
not atomic, the other events may interrupt the process. For example,
if a loss of signal event inserted before the probe event, the
sas_deform_port() is called and the port will be deleted.
And sas_port_delete() may run before the destruct event, but the
port-x:x is the top parent of end device or expander. This leads to
a kernel WARNING such as:
[ 82.042979] sysfs group 'power' not found for kobject 'phy-1:0:22'
[ 82.042983] [ cut here ]
[ 82.042986] WARNING: CPU: 54 PID: 1714 at fs/sysfs/group.c:237
sysfs_remove_group+0x94/0xa0
[ 82.043059] Call trace:
[ 82.043082] [] sysfs_remove_group+0x94/0xa0
[ 82.043085] [] dpm_sysfs_remove+0x60/0x70
[ 82.043086] [] device_del+0x138/0x308
[ 82.043089] [] sas_phy_delete+0x38/0x60
[ 82.043091] [] do_sas_phy_delete+0x6c/0x80
[ 82.043093] [] device_for_each_child+0x58/0xa0
[ 82.043095] [] sas_remove_children+0x40/0x50
[ 82.043100] [] sas_destruct_devices+0x64/0xa0
[ 82.043102] [] process_one_work+0x1fc/0x4b0
[ 82.043104] [] worker_thread+0x50/0x490
[ 82.043105] [] kthread+0xfc/0x128
[ 82.043107] [] ret_from_fork+0x10/0x50
Make probe and destruct a direct call in the disco and revalidate function,
but put them outside the lock. The whole discovery or revalidate won't
be interrupted by other events. And the DISCE_PROBE and DISCE_DESTRUCT
event are deleted as a result of the direct call.
Introduce a new list to destruct the sas_port and put the port delete after
the destruct. This makes sure the right order of destroying the sysfs
kobject and fix the warning above.
In sas_ex_revalidate_domain() have a loop to find all broadcasted
device, and sometimes we have a chance to find the same expander twice.
Because the sas_port will be deleted at the end of the whole revalidate
process, sas_port with the same name cannot be added before this.
Otherwise the sysfs will complain of creating duplicate filename. Since
the LLDD will send broadcast for every device change, we can only
process one expander's revalidation.
[mkp: kbuild test robot warning]
Signed-off-by: Jason Yan
CC: John Garry
CC: Johannes Thumshirn
CC: Ewan Milne
CC: Christoph Hellwig
CC: Tomas Henzl
CC: Dan Williams
Reviewed-by: Hannes Reinecke
Signed-off-by: Martin K. Petersen
[bwh: Backported to 4.9: adjust context]
Signed-off-by: Ben Hutchings
---
drivers/scsi/libsas/sas_ata.c | 1 -
drivers/scsi/libsas/sas_discover.c | 32 +-
drivers/scsi/libsas/sas_expander.c | 8 +++-
drivers/scsi/libsas/sas_internal.h | 1 +
drivers/scsi/libsas/sas_port.c | 3 +++
include/scsi/libsas.h | 3 +--
include/scsi/scsi_transport_sas.h | 1 +
7 files changed, 27 insertions(+), 22 deletions(-)
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -782,7 +782,6 @@ int sas_discover_sata(struct domain_devi
if
Re: [PATCH 3.16 012/410] scsi: libsas: direct call probe and destruct
On 2018/6/8 2:18, Ben Hutchings wrote:
On Thu, 2018-06-07 at 17:32 +0100, John Garry wrote:
On 07/06/2018 15:05, Ben Hutchings wrote:
3.16.57-rc1 review patch. If anyone has any objections, please let me know.
--
Hi Ben,
I noticed that you are looking to backport this patch to 3.16
I am wondering why you are taking this libsas patch (and a couple other
libsas patches) in isolation, when these patches were part of a series
to fix libsas hotplug issues? I'm not sure if cherry-picking certain
patches is ok.
Maybe Jason (cc'ed) can comment further.
This one apparently fixed a security issue (CVE-2017-18232), though I'm
certainly not convinced it's a particularly serious one.
But please send objections to the list, not just privately.
Hi Ben,
This patch is in the series below. I recommend to backport them
together. If you really want to do this, I'm happy to help you to
backport them.
1689c9367bfa scsi: libsas: notify event PORTE_BROADCAST_RCVD in
sas_enable_revalidation()
0558f33c06bb scsi: libsas: direct call probe and destruct
517e5153d242 scsi: libsas: use flush_workqueue to process disco events
synchronously
93bdbd06b164 scsi: libsas: Use new workqueue to run sas event and disco
event
8eea9dd84e45 scsi: libsas: make the event threshold configurable
f12486e06ae8 scsi: libsas: shut down the PHY if events reached the threshold
1c393b970e0f scsi: libsas: Use dynamic alloced work to avoid sas event lost
Ben.
Thanks,
John
From: Jason Yan
commit 0558f33c06bb910e2879e355192227a8e8f0219d upstream.
In commit 87c8331fcf72 ("[SCSI] libsas: prevent domain rediscovery
competing with ata error handling") introduced disco mutex to prevent
rediscovery competing with ata error handling and put the whole
revalidation in the mutex. But the rphy add/remove needs to wait for the
error handling which also grabs the disco mutex. This may leads to dead
lock.So the probe and destruct event were introduce to do the rphy
add/remove asynchronously and out of the lock.
The asynchronously processed workers makes the whole discovery process
not atomic, the other events may interrupt the process. For example,
if a loss of signal event inserted before the probe event, the
sas_deform_port() is called and the port will be deleted.
And sas_port_delete() may run before the destruct event, but the
port-x:x is the top parent of end device or expander. This leads to
a kernel WARNING such as:
[ 82.042979] sysfs group 'power' not found for kobject 'phy-1:0:22'
[ 82.042983] [ cut here ]
[ 82.042986] WARNING: CPU: 54 PID: 1714 at fs/sysfs/group.c:237
sysfs_remove_group+0x94/0xa0
[ 82.043059] Call trace:
[ 82.043082] [] sysfs_remove_group+0x94/0xa0
[ 82.043085] [] dpm_sysfs_remove+0x60/0x70
[ 82.043086] [] device_del+0x138/0x308
[ 82.043089] [] sas_phy_delete+0x38/0x60
[ 82.043091] [] do_sas_phy_delete+0x6c/0x80
[ 82.043093] [] device_for_each_child+0x58/0xa0
[ 82.043095] [] sas_remove_children+0x40/0x50
[ 82.043100] [] sas_destruct_devices+0x64/0xa0
[ 82.043102] [] process_one_work+0x1fc/0x4b0
[ 82.043104] [] worker_thread+0x50/0x490
[ 82.043105] [] kthread+0xfc/0x128
[ 82.043107] [] ret_from_fork+0x10/0x50
Make probe and destruct a direct call in the disco and revalidate function,
but put them outside the lock. The whole discovery or revalidate won't
be interrupted by other events. And the DISCE_PROBE and DISCE_DESTRUCT
event are deleted as a result of the direct call.
Introduce a new list to destruct the sas_port and put the port delete after
the destruct. This makes sure the right order of destroying the sysfs
kobject and fix the warning above.
In sas_ex_revalidate_domain() have a loop to find all broadcasted
device, and sometimes we have a chance to find the same expander twice.
Because the sas_port will be deleted at the end of the whole revalidate
process, sas_port with the same name cannot be added before this.
Otherwise the sysfs will complain of creating duplicate filename. Since
the LLDD will send broadcast for every device change, we can only
process one expander's revalidation.
[mkp: kbuild test robot warning]
Signed-off-by: Jason Yan
CC: John Garry
CC: Johannes Thumshirn
CC: Ewan Milne
CC: Christoph Hellwig
CC: Tomas Henzl
CC: Dan Williams
Reviewed-by: Hannes Reinecke
Signed-off-by: Martin K. Petersen
[bwh: Backported to 4.9: adjust context]
Signed-off-by: Ben Hutchings
---
drivers/scsi/libsas/sas_ata.c | 1 -
drivers/scsi/libsas/sas_discover.c | 32 +-
drivers/scsi/libsas/sas_expander.c | 8 +++-
drivers/scsi/libsas/sas_internal.h | 1 +
drivers/scsi/libsas/sas_port.c | 3 +++
include/scsi/libsas.h | 3 +--
include/scsi/scsi_transport_sas.h | 1 +
7 files changed, 27 insertions(+), 22 deletions(-)
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -782,7 +782,6 @@ int sas_discover_sata(struct domain_devi
if
Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm
Hi Andrea Thanks for the review. On 6/8/2018 7:38 AM, Andrea Arcangeli Wrote: > On Thu, Jun 07, 2018 at 03:13:44PM -0700, Andrew Morton wrote: >> This patch is quite urgent and is tagged for -stable backporting, yet >> it remains in an unreviewed state. Any takers? > > It looks a straightforward safe fix, on x86 hva_to_gfn_memslot would > zap those bits and hide the misalignment caused by the low metadata > bits being erroneously left set in the address, but the arm code > notices when that's the last page in the memslot and the hva_end is > getting aligned and the size is below one page. > >> [35380.933345] [] dump_backtrace+0x0/0x22c >> [35380.938723] [] show_stack+0x24/0x2c >> [35380.943759] [] dump_stack+0x8c/0xb0 >> [35380.948794] [] bad_page+0xf4/0x154 >> [35380.953740] [] free_pages_check_bad+0x90/0x9c >> [35380.959642] [] free_pcppages_bulk+0x464/0x518 >> [35380.965545] [] free_hot_cold_page+0x22c/0x300 >> [35380.971448] [] __put_page+0x54/0x60 >> [35380.976484] [] unmap_stage2_range+0x170/0x2b4 >> [35380.982385] [] kvm_unmap_hva_handler+0x30/0x40 >> [35380.988375] [] handle_hva_to_gpa+0xb0/0xec >> [35380.994016] [] kvm_unmap_hva_range+0x5c/0xd0 >> [35380.999833] [] >> >> I even injected a fault on purpose in kvm_unmap_hva_range by seting >> size=size-0x200, the call trace is similar as above. So I thought the >> panic is similarly caused by the root cause of WARN_ON. > > I think the problem triggers in the addr += PAGE_SIZE of > unmap_stage2_ptes that never matches end because end is aligned but > addr is not. > > } while (pte++, addr += PAGE_SIZE, addr != end); > > x86 again only works on hva_start/hva_end after converting it to > gfn_start/end and that being in pfn units the bits are zapped before > they risk to cause trouble. For this panic issue on arm64, I started another thread to discuss https://lkml.org/lkml/2018/5/2/61 -- Cheers, Jia > >> >> Link: >> http://lkml.kernel.org/r/1525403506-6750-1-git-send-email-hejia...@gmail.com >> Signed-off-by: Jia He >> Cc: Suzuki K Poulose >> Cc: Andrea Arcangeli >> Cc: Minchan Kim >> Cc: Claudio Imbrenda >> Cc: Arvind Yadav >> Cc: Mike Rapoport >> Cc: Jia He >> Cc: >> Signed-off-by: Andrew Morton >> --- >> > > Reviewed-by: Andrea Arcangeli >
Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm
Hi Andrea Thanks for the review. On 6/8/2018 7:38 AM, Andrea Arcangeli Wrote: > On Thu, Jun 07, 2018 at 03:13:44PM -0700, Andrew Morton wrote: >> This patch is quite urgent and is tagged for -stable backporting, yet >> it remains in an unreviewed state. Any takers? > > It looks a straightforward safe fix, on x86 hva_to_gfn_memslot would > zap those bits and hide the misalignment caused by the low metadata > bits being erroneously left set in the address, but the arm code > notices when that's the last page in the memslot and the hva_end is > getting aligned and the size is below one page. > >> [35380.933345] [] dump_backtrace+0x0/0x22c >> [35380.938723] [] show_stack+0x24/0x2c >> [35380.943759] [] dump_stack+0x8c/0xb0 >> [35380.948794] [] bad_page+0xf4/0x154 >> [35380.953740] [] free_pages_check_bad+0x90/0x9c >> [35380.959642] [] free_pcppages_bulk+0x464/0x518 >> [35380.965545] [] free_hot_cold_page+0x22c/0x300 >> [35380.971448] [] __put_page+0x54/0x60 >> [35380.976484] [] unmap_stage2_range+0x170/0x2b4 >> [35380.982385] [] kvm_unmap_hva_handler+0x30/0x40 >> [35380.988375] [] handle_hva_to_gpa+0xb0/0xec >> [35380.994016] [] kvm_unmap_hva_range+0x5c/0xd0 >> [35380.999833] [] >> >> I even injected a fault on purpose in kvm_unmap_hva_range by seting >> size=size-0x200, the call trace is similar as above. So I thought the >> panic is similarly caused by the root cause of WARN_ON. > > I think the problem triggers in the addr += PAGE_SIZE of > unmap_stage2_ptes that never matches end because end is aligned but > addr is not. > > } while (pte++, addr += PAGE_SIZE, addr != end); > > x86 again only works on hva_start/hva_end after converting it to > gfn_start/end and that being in pfn units the bits are zapped before > they risk to cause trouble. For this panic issue on arm64, I started another thread to discuss https://lkml.org/lkml/2018/5/2/61 -- Cheers, Jia > >> >> Link: >> http://lkml.kernel.org/r/1525403506-6750-1-git-send-email-hejia...@gmail.com >> Signed-off-by: Jia He >> Cc: Suzuki K Poulose >> Cc: Andrea Arcangeli >> Cc: Minchan Kim >> Cc: Claudio Imbrenda >> Cc: Arvind Yadav >> Cc: Mike Rapoport >> Cc: Jia He >> Cc: >> Signed-off-by: Andrew Morton >> --- >> > > Reviewed-by: Andrea Arcangeli >
Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm
Hi Andrew On 6/8/2018 6:13 AM, Andrew Morton Wrote: > On Thu, 24 May 2018 13:38:05 -0700 Andrew Morton > wrote: >>> >>> Jia, Andrew, >>> >>> What is the status of this patch ? >>> >> >> I have it scheduled for 4.18-rc1, with a cc:stable for backporting. >> >> I'd normally put such a fix into 4.17-rcX but I'd like to give Hugh >> time to review it and to generally give it a bit more time for review >> and test. >> >> Have you tested it yourself? > > I'll take your silence as a no. Sorry if you asked the previous question to me. I've tested by myself in arm64 server (QDF2400,46 cpus,96G mem) Without this patch, the WARN_ON is very easy for reproducing. After this patch, I have run the same benchmarch for a whole day without any WARN_ONs Hope it helpful. Cheers, Jia
Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm
Hi Andrew On 6/8/2018 6:13 AM, Andrew Morton Wrote: > On Thu, 24 May 2018 13:38:05 -0700 Andrew Morton > wrote: >>> >>> Jia, Andrew, >>> >>> What is the status of this patch ? >>> >> >> I have it scheduled for 4.18-rc1, with a cc:stable for backporting. >> >> I'd normally put such a fix into 4.17-rcX but I'd like to give Hugh >> time to review it and to generally give it a bit more time for review >> and test. >> >> Have you tested it yourself? > > I'll take your silence as a no. Sorry if you asked the previous question to me. I've tested by myself in arm64 server (QDF2400,46 cpus,96G mem) Without this patch, the WARN_ON is very easy for reproducing. After this patch, I have run the same benchmarch for a whole day without any WARN_ONs Hope it helpful. Cheers, Jia
Re: mmotm 2018-06-07-16-59 uploaded (scsi/ipr)
On 06/07/2018 04:59 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2018-06-07-16-59 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > on i386 (randconfig): ../drivers/scsi/ipr.c: In function 'ipr_mask_and_clear_interrupts': ../drivers/scsi/ipr.c:767:3: error: implicit declaration of function 'writeq_relaxed' [-Werror=implicit-function-declaration] writeq_relaxed(~0, ioa_cfg->regs.set_interrupt_mask_reg); ^ need config? -- ~Randy
Re: mmotm 2018-06-07-16-59 uploaded (scsi/ipr)
On 06/07/2018 04:59 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2018-06-07-16-59 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > on i386 (randconfig): ../drivers/scsi/ipr.c: In function 'ipr_mask_and_clear_interrupts': ../drivers/scsi/ipr.c:767:3: error: implicit declaration of function 'writeq_relaxed' [-Werror=implicit-function-declaration] writeq_relaxed(~0, ioa_cfg->regs.set_interrupt_mask_reg); ^ need config? -- ~Randy
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
Hi, On 06/06/2018 09:58 PM, Masahiro Yamada wrote: > Hi. > > > 2018-06-07 8:16 GMT+09:00 Jayant Chowdhary : >> In order for static analysis tools to analyze each of the uapi headers, >> we need to enable them to compile stand-alone. Some uapi headers were >> missing dependencies which would not make them compile stand-alone in >> user-land. This patch adds those dependencies. >> >> Test: make defconfig; make -j64 >> >> Test: make ARCH=arm64 defconfig; >> ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j64 all >> >> Test: ran header-abi-dumper[1] on all the affected headers with >> appropriate include paths[2] for arm64. eg: for drm_fourcc.h, >> >> $HEADER_ABI_DUMPER -o drm_fourcc.h.sdump \ >> include/uapi/drm/drm_fourcc.h -- -target aarch64-linux-android -std=gnu99 \ >> -isystem $CLANG_INCLUDE_PATH \ >> -I include/uapi/ -I arch/arm64/include/generated/uapi \ >> -I arch/arm64/include/uapi -I private-compiler-headers >> -I include/generated/uapi \ >> -I include/uapi/../../arch/arm/include/uapi > > > First of all, is this check sensible? > > scripts/headers_install.sh manipulates exported headers. > > So, shouldn't you do this check after "make headers_install"? > > Apologies, I was unaware of this. Now it is obvious that this check is not sensible :) The headers which should be checked are the ones 'make headers install' produces and not the ones being checked currently. I'll fix this in the next version of this patch. > > You are adding around to various UAPI headers. > Could you tell me why it was added? > > The tool rips off anyway when exporting UAPI headers: > https://github.com/torvalds/linux/blob/v4.17/scripts/headers_install.sh#L37 > > I had added these to satisfy the defines included from , however, since headers_install.sh removes the #includes and the defines themselves, these additions should not be needed. > > > Also, you are adding to several headers. > Please do not pull it in to the kernel space. > The kernel space defines fixed-width types in its headers. > > For example, you added to include/uapi/scsi/scsi_netlink.h > > In my opinion, the correct fix is to replace uint8_t with __u8 or __uint8_t. > > Sure, I will correct this. Thanks, Jayant > > > > >> where >> HEADER_ABI_DUMPER=\ >> $ANDROID_BUILD_TOP/prebuilts/clang-tools/linux-x86/bin/header-abi-dumper >> >> CLANG_INCLUDE_PATH=\ >> $ANDROID_BUILD_TOP/prebuilts/clang/host/linux-x86/clang-3289846/bin/../lib64/clang/3.8/include >> >> on a lunched aosp tree [3] >> >> [1] >> header-abi-dumper is a clang based static analysis tool, used by android's >> build >> system which parses a C/C++ source file and emits information about the data >> types included in the source. More information can be found at >> https://android.googlesource.com/platform/development/+/master/vndk/tools/header-checker/README.md >> >> [2] >> Some headers, eg: compiler_types.h, compiler.h, sys/socket.h are not in the >> set of uapi headers, even though they are included by uapi headers( >> include/uapi/linux/types.h, include/uapi/asm-generic/signal-defs.h etc). The >> 'private-compiler-headers' in the test clause was included with private >> copies >> of these headers. libc distributions (eg: bionic) often have their >> copies of these headers as well. >> >> [3] >> https://source.android.com/setup/build/downloading >> >> Cc: a...@linux-foundation.org >> Cc: kernel-t...@android.com >> Cc: linux-kbu...@vger.kernel.org >> Signed-off-by: Jayant Chowdhary >> --- >> include/uapi/asm-generic/ipcbuf.h | 2 ++ >> include/uapi/asm-generic/msgbuf.h | 3 +++ >> include/uapi/asm-generic/sembuf.h | 2 ++ >> include/uapi/asm-generic/shmbuf.h | 2 ++ >> include/uapi/asm-generic/ucontext.h| 5 + >> include/uapi/linux/agpgart.h | 1 - >> include/uapi/linux/android/binder.h| 1 + >> include/uapi/linux/chio.h | 6 ++ >> include/uapi/linux/coda_psdev.h| 1 + >> include/uapi/linux/dvb/dmx.h | 3 --- >> include/uapi/linux/dvb/video.h | 3 --- >> include/uapi/linux/errqueue.h | 1 + >> include/uapi/linux/kexec.h | 1 + >> include/uapi/linux/kfd_ioctl.h | 1 + >> include/uapi/linux/lightnvm.h | 1 - >> include/uapi/linux/ndctl.h | 1 + >> include/uapi/linux/netfilter_bridge/ebtables.h | 1 + >> include/uapi/linux/nfs4_mount.h| 3 +++ >> include/uapi/linux/psp-sev.h | 1 + >> include/uapi/linux/scc.h | 2 +- >> include/uapi/linux/sctp.h | 3 +++ >> include/uapi/linux/sdla.h | 2 ++ >> include/uapi/linux/socket.h| 4 >> include/uapi/linux/stddef.h| 5 + >> include/uapi/linux/sysctl.h| 1 + >> include/uapi/linux/types.h
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
Hi, On 06/06/2018 09:58 PM, Masahiro Yamada wrote: > Hi. > > > 2018-06-07 8:16 GMT+09:00 Jayant Chowdhary : >> In order for static analysis tools to analyze each of the uapi headers, >> we need to enable them to compile stand-alone. Some uapi headers were >> missing dependencies which would not make them compile stand-alone in >> user-land. This patch adds those dependencies. >> >> Test: make defconfig; make -j64 >> >> Test: make ARCH=arm64 defconfig; >> ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j64 all >> >> Test: ran header-abi-dumper[1] on all the affected headers with >> appropriate include paths[2] for arm64. eg: for drm_fourcc.h, >> >> $HEADER_ABI_DUMPER -o drm_fourcc.h.sdump \ >> include/uapi/drm/drm_fourcc.h -- -target aarch64-linux-android -std=gnu99 \ >> -isystem $CLANG_INCLUDE_PATH \ >> -I include/uapi/ -I arch/arm64/include/generated/uapi \ >> -I arch/arm64/include/uapi -I private-compiler-headers >> -I include/generated/uapi \ >> -I include/uapi/../../arch/arm/include/uapi > > > First of all, is this check sensible? > > scripts/headers_install.sh manipulates exported headers. > > So, shouldn't you do this check after "make headers_install"? > > Apologies, I was unaware of this. Now it is obvious that this check is not sensible :) The headers which should be checked are the ones 'make headers install' produces and not the ones being checked currently. I'll fix this in the next version of this patch. > > You are adding around to various UAPI headers. > Could you tell me why it was added? > > The tool rips off anyway when exporting UAPI headers: > https://github.com/torvalds/linux/blob/v4.17/scripts/headers_install.sh#L37 > > I had added these to satisfy the defines included from , however, since headers_install.sh removes the #includes and the defines themselves, these additions should not be needed. > > > Also, you are adding to several headers. > Please do not pull it in to the kernel space. > The kernel space defines fixed-width types in its headers. > > For example, you added to include/uapi/scsi/scsi_netlink.h > > In my opinion, the correct fix is to replace uint8_t with __u8 or __uint8_t. > > Sure, I will correct this. Thanks, Jayant > > > > >> where >> HEADER_ABI_DUMPER=\ >> $ANDROID_BUILD_TOP/prebuilts/clang-tools/linux-x86/bin/header-abi-dumper >> >> CLANG_INCLUDE_PATH=\ >> $ANDROID_BUILD_TOP/prebuilts/clang/host/linux-x86/clang-3289846/bin/../lib64/clang/3.8/include >> >> on a lunched aosp tree [3] >> >> [1] >> header-abi-dumper is a clang based static analysis tool, used by android's >> build >> system which parses a C/C++ source file and emits information about the data >> types included in the source. More information can be found at >> https://android.googlesource.com/platform/development/+/master/vndk/tools/header-checker/README.md >> >> [2] >> Some headers, eg: compiler_types.h, compiler.h, sys/socket.h are not in the >> set of uapi headers, even though they are included by uapi headers( >> include/uapi/linux/types.h, include/uapi/asm-generic/signal-defs.h etc). The >> 'private-compiler-headers' in the test clause was included with private >> copies >> of these headers. libc distributions (eg: bionic) often have their >> copies of these headers as well. >> >> [3] >> https://source.android.com/setup/build/downloading >> >> Cc: a...@linux-foundation.org >> Cc: kernel-t...@android.com >> Cc: linux-kbu...@vger.kernel.org >> Signed-off-by: Jayant Chowdhary >> --- >> include/uapi/asm-generic/ipcbuf.h | 2 ++ >> include/uapi/asm-generic/msgbuf.h | 3 +++ >> include/uapi/asm-generic/sembuf.h | 2 ++ >> include/uapi/asm-generic/shmbuf.h | 2 ++ >> include/uapi/asm-generic/ucontext.h| 5 + >> include/uapi/linux/agpgart.h | 1 - >> include/uapi/linux/android/binder.h| 1 + >> include/uapi/linux/chio.h | 6 ++ >> include/uapi/linux/coda_psdev.h| 1 + >> include/uapi/linux/dvb/dmx.h | 3 --- >> include/uapi/linux/dvb/video.h | 3 --- >> include/uapi/linux/errqueue.h | 1 + >> include/uapi/linux/kexec.h | 1 + >> include/uapi/linux/kfd_ioctl.h | 1 + >> include/uapi/linux/lightnvm.h | 1 - >> include/uapi/linux/ndctl.h | 1 + >> include/uapi/linux/netfilter_bridge/ebtables.h | 1 + >> include/uapi/linux/nfs4_mount.h| 3 +++ >> include/uapi/linux/psp-sev.h | 1 + >> include/uapi/linux/scc.h | 2 +- >> include/uapi/linux/sctp.h | 3 +++ >> include/uapi/linux/sdla.h | 2 ++ >> include/uapi/linux/socket.h| 4 >> include/uapi/linux/stddef.h| 5 + >> include/uapi/linux/sysctl.h| 1 + >> include/uapi/linux/types.h
Re: linux-next: build failure after merge of the thermal tree
Hi all,
On Fri, 8 Jun 2018 10:51:20 +1000 Stephen Rothwell
wrote:
>
> After merging the thermal tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/qcom/tsens.c: In function 'tsens_probe':
> drivers/thermal/qcom/tsens.c:144:31: error: 's' undeclared (first use in this
> function)
> num_sensors * sizeof(*s), GFP_KERNEL);
>^
>
> Caused by commit
>
> 6d7c70d1cd65 ("thermal: qcom: tsens: Allow number of sensors to come from
> DT")
>
> interacting with commit
>
> 0ed2dd03b94b ("treewide: Use struct_size() for devm_kmalloc() and friends")
>
> from Linus' tree. It looks like git somehow screwed up the automatic
> conflict resolution.
OK, this was caused by a bad rerere entry in my tree (from my recent import of
Andrew's mmotm patch series). Sorry about that, I have fixed it up.
--
Cheers,
Stephen Rothwell
pgprYtfHdeD9u.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the thermal tree
Hi all,
On Fri, 8 Jun 2018 10:51:20 +1000 Stephen Rothwell
wrote:
>
> After merging the thermal tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/qcom/tsens.c: In function 'tsens_probe':
> drivers/thermal/qcom/tsens.c:144:31: error: 's' undeclared (first use in this
> function)
> num_sensors * sizeof(*s), GFP_KERNEL);
>^
>
> Caused by commit
>
> 6d7c70d1cd65 ("thermal: qcom: tsens: Allow number of sensors to come from
> DT")
>
> interacting with commit
>
> 0ed2dd03b94b ("treewide: Use struct_size() for devm_kmalloc() and friends")
>
> from Linus' tree. It looks like git somehow screwed up the automatic
> conflict resolution.
OK, this was caused by a bad rerere entry in my tree (from my recent import of
Andrew's mmotm patch series). Sorry about that, I have fixed it up.
--
Cheers,
Stephen Rothwell
pgprYtfHdeD9u.pgp
Description: OpenPGP digital signature
[PATCH][v2] sched: cpufreq: Fix long idle judgement logic in load calculation
According to current code implementation, detecting the long
idle period is done by checking if the interval between two
adjacent utilization update handers is long enough. Although
this mechanism can detect if the idle period is long enough
(no utilization hooks invoked during idle period), it might
not contain a corner case: if the task has occupied the cpu
for too long which causes no context switch during that
period, then no utilization handler will be launched until this
high prio task is switched out. As a result, the idle_periods
field might be calculated incorrectly because it regards the
100% load as 0% and makes the conservative governor who uses
this field confusing.
Change the judgement to compare the idle_time with sampling_rate
directly.
Reported-by: Artem S. Tashkinov
Cc: Artem S Tashkinov
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Chen Yu
---
v2: Per Viresh's suggestion, ignore idle_time longer than 30mins and
simplify the code.
---
drivers/cpufreq/cpufreq_governor.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 871bf9c..1d50e97 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -165,7 +165,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
* calls, so the previous load value can be used then.
*/
load = j_cdbs->prev_load;
- } else if (unlikely(time_elapsed > 2 * sampling_rate &&
+ } else if (unlikely((int)idle_time > 2 * sampling_rate &&
j_cdbs->prev_load)) {
/*
* If the CPU had gone completely idle and a task has
@@ -185,10 +185,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
* clear prev_load to guarantee that the load will be
* computed again next time.
*
-* Detecting this situation is easy: the governor's
-* utilization update handler would not have run during
-* CPU-idle periods. Hence, an unusually large
-* 'time_elapsed' (as compared to the sampling rate)
+* Detecting this situation is easy: an unusually large
+* 'idle_time' (as compared to the sampling rate)
* indicates this scenario.
*/
load = j_cdbs->prev_load;
@@ -217,8 +215,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
j_cdbs->prev_load = load;
}
- if (time_elapsed > 2 * sampling_rate) {
- unsigned int periods = time_elapsed / sampling_rate;
+ if (unlikely((int)idle_time > 2 * sampling_rate)) {
+ unsigned int periods = idle_time / sampling_rate;
if (periods < idle_periods)
idle_periods = periods;
--
2.7.4
[PATCH][v2] sched: cpufreq: Fix long idle judgement logic in load calculation
According to current code implementation, detecting the long
idle period is done by checking if the interval between two
adjacent utilization update handers is long enough. Although
this mechanism can detect if the idle period is long enough
(no utilization hooks invoked during idle period), it might
not contain a corner case: if the task has occupied the cpu
for too long which causes no context switch during that
period, then no utilization handler will be launched until this
high prio task is switched out. As a result, the idle_periods
field might be calculated incorrectly because it regards the
100% load as 0% and makes the conservative governor who uses
this field confusing.
Change the judgement to compare the idle_time with sampling_rate
directly.
Reported-by: Artem S. Tashkinov
Cc: Artem S Tashkinov
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Chen Yu
---
v2: Per Viresh's suggestion, ignore idle_time longer than 30mins and
simplify the code.
---
drivers/cpufreq/cpufreq_governor.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 871bf9c..1d50e97 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -165,7 +165,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
* calls, so the previous load value can be used then.
*/
load = j_cdbs->prev_load;
- } else if (unlikely(time_elapsed > 2 * sampling_rate &&
+ } else if (unlikely((int)idle_time > 2 * sampling_rate &&
j_cdbs->prev_load)) {
/*
* If the CPU had gone completely idle and a task has
@@ -185,10 +185,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
* clear prev_load to guarantee that the load will be
* computed again next time.
*
-* Detecting this situation is easy: the governor's
-* utilization update handler would not have run during
-* CPU-idle periods. Hence, an unusually large
-* 'time_elapsed' (as compared to the sampling rate)
+* Detecting this situation is easy: an unusually large
+* 'idle_time' (as compared to the sampling rate)
* indicates this scenario.
*/
load = j_cdbs->prev_load;
@@ -217,8 +215,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
j_cdbs->prev_load = load;
}
- if (time_elapsed > 2 * sampling_rate) {
- unsigned int periods = time_elapsed / sampling_rate;
+ if (unlikely((int)idle_time > 2 * sampling_rate)) {
+ unsigned int periods = idle_time / sampling_rate;
if (periods < idle_periods)
idle_periods = periods;
--
2.7.4
Re: mmotm 2018-06-07-16-59 uploaded (fs/fat/ and fs/dax/)
On 06/07/2018 04:59 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2018-06-07-16-59 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > (on i386:) ../fs/fat/inode.c: In function '__fat_get_block': ../fs/fat/inode.c:162:3: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'sector_t' [-Wformat=] fat_fs_error(sb, ^ ../fs/dax.c: In function 'dax_load_hole': ../fs/dax.c:1031:2: error: 'entry2' undeclared (first use in this function) entry2 = dax_insert_mapping_entry(mapping, vmf, entry, pfn, ^ Easy fixes... :) -- ~Randy
Re: [PATCH 6/9] x86/mm: Introduce ptep_set_wrprotect_flush and related functions
On Thu, Jun 7, 2018 at 1:30 PM Dave Hansen wrote:
>
> On 06/07/2018 09:24 AM, Andy Lutomirski wrote:
>
> >> +static inline void ptep_set_wrprotect_flush(struct vm_area_struct *vma,
> >> + unsigned long addr, pte_t
> >> *ptep)
> >> +{
> >> + bool rw;
> >> +
> >> + rw = test_and_clear_bit(_PAGE_BIT_RW, (unsigned long *)>pte);
> >> + if (IS_ENABLED(CONFIG_X86_INTEL_SHADOW_STACK_USER)) {
> >> + struct mm_struct *mm = vma->vm_mm;
> >> + pte_t pte;
> >> +
> >> + if (rw && (atomic_read(>mm_users) > 1))
> >> + pte = ptep_clear_flush(vma, addr, ptep);
> > Why are you clearing the pte?
>
> I found my notes on the subject. :)
>
> Here's the sequence that causes the problem. This could happen any time
> we try to take a PTE from read-write to read-only. P==Present, W=Write,
> D=Dirty:
>
> CPU0 does a write, sees PTE with P=1,W=1,D=0
> CPU0 decides to set D=1
> CPU1 comes in and sets W=0
> CPU0 does locked operation to set D=1
> CPU0 sees P=1,W=0,D=0
> CPU0 sets back P=1,W=0,D=1
> CPU0 loads P=1,W=0,D=1 into the TLB
> CPU0 attempts to continue the write, but sees W=0 in the TLB and a #PF
> is generated because of the write fault.
>
> The problem with this is that we end up with a shadowstack-PTE
> (Write=0,Dirty=1) where we didn't want one. This, unfortunately,
> imposes extra TLB flushing overhead on the R/W->R/O transitions that
> does not exist before shadowstack enabling.
>
So what exactly do the architects want the OS to do? AFAICS the only
valid ways to clear the dirty bit are:
--- Choice 1 ---
a) Set P=0.
b) Flush using an IPI
c) Read D (so we know if the page was actually dirty)
d) Set P=1,W=0,D=0
and we need to handle spurious faults that happen between steps (a)
and (c). This isn't so easy because the straightforward "is the fault
spurious" check is going to think it's *not* spurious.
--- Choice 2 ---
a) Set W=0
b) flush
c) Test and clear D
and we need to handle the spurious fault between b and c. At least
this particular spurious fault is easier to handle since we can check
the error code.
But surely the right solution is to get the architecture team to see
if they can fix the dirty-bit-setting algorithm or, even better, to
look and see if the dirty-bit-setting algorithm is *already* better
and just document it. If the cpu does a locked set-bit on D in your
example, the CPU is just being silly. The CPU should make the whole
operation fully atomic: when trying to write to a page that's D=0 in
the TLB, it should re-walk the page tables and, atomically, load the
PTE and, if it's W=1,D=0, set D=1. I'd honestly be a bit surprised if
modern CPUs don't already do this.
(Hmm. If the CPUs were that smart, then we wouldn't need a flush at
all in some cases. If we lock cmpxchg to change W=1,D=0 to W=0,D=0,
then we know that no other CPU can subsequently write the page without
re-walking, and we don't need to flush.)
Can you ask the architecture folks to clarify the situation? And, if
your notes are indeed correct, don't we need code to handle spurious
faults?
--Andy
Re: mmotm 2018-06-07-16-59 uploaded (fs/fat/ and fs/dax/)
On 06/07/2018 04:59 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2018-06-07-16-59 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > (on i386:) ../fs/fat/inode.c: In function '__fat_get_block': ../fs/fat/inode.c:162:3: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'sector_t' [-Wformat=] fat_fs_error(sb, ^ ../fs/dax.c: In function 'dax_load_hole': ../fs/dax.c:1031:2: error: 'entry2' undeclared (first use in this function) entry2 = dax_insert_mapping_entry(mapping, vmf, entry, pfn, ^ Easy fixes... :) -- ~Randy
Re: [PATCH 6/9] x86/mm: Introduce ptep_set_wrprotect_flush and related functions
On Thu, Jun 7, 2018 at 1:30 PM Dave Hansen wrote:
>
> On 06/07/2018 09:24 AM, Andy Lutomirski wrote:
>
> >> +static inline void ptep_set_wrprotect_flush(struct vm_area_struct *vma,
> >> + unsigned long addr, pte_t
> >> *ptep)
> >> +{
> >> + bool rw;
> >> +
> >> + rw = test_and_clear_bit(_PAGE_BIT_RW, (unsigned long *)>pte);
> >> + if (IS_ENABLED(CONFIG_X86_INTEL_SHADOW_STACK_USER)) {
> >> + struct mm_struct *mm = vma->vm_mm;
> >> + pte_t pte;
> >> +
> >> + if (rw && (atomic_read(>mm_users) > 1))
> >> + pte = ptep_clear_flush(vma, addr, ptep);
> > Why are you clearing the pte?
>
> I found my notes on the subject. :)
>
> Here's the sequence that causes the problem. This could happen any time
> we try to take a PTE from read-write to read-only. P==Present, W=Write,
> D=Dirty:
>
> CPU0 does a write, sees PTE with P=1,W=1,D=0
> CPU0 decides to set D=1
> CPU1 comes in and sets W=0
> CPU0 does locked operation to set D=1
> CPU0 sees P=1,W=0,D=0
> CPU0 sets back P=1,W=0,D=1
> CPU0 loads P=1,W=0,D=1 into the TLB
> CPU0 attempts to continue the write, but sees W=0 in the TLB and a #PF
> is generated because of the write fault.
>
> The problem with this is that we end up with a shadowstack-PTE
> (Write=0,Dirty=1) where we didn't want one. This, unfortunately,
> imposes extra TLB flushing overhead on the R/W->R/O transitions that
> does not exist before shadowstack enabling.
>
So what exactly do the architects want the OS to do? AFAICS the only
valid ways to clear the dirty bit are:
--- Choice 1 ---
a) Set P=0.
b) Flush using an IPI
c) Read D (so we know if the page was actually dirty)
d) Set P=1,W=0,D=0
and we need to handle spurious faults that happen between steps (a)
and (c). This isn't so easy because the straightforward "is the fault
spurious" check is going to think it's *not* spurious.
--- Choice 2 ---
a) Set W=0
b) flush
c) Test and clear D
and we need to handle the spurious fault between b and c. At least
this particular spurious fault is easier to handle since we can check
the error code.
But surely the right solution is to get the architecture team to see
if they can fix the dirty-bit-setting algorithm or, even better, to
look and see if the dirty-bit-setting algorithm is *already* better
and just document it. If the cpu does a locked set-bit on D in your
example, the CPU is just being silly. The CPU should make the whole
operation fully atomic: when trying to write to a page that's D=0 in
the TLB, it should re-walk the page tables and, atomically, load the
PTE and, if it's W=1,D=0, set D=1. I'd honestly be a bit surprised if
modern CPUs don't already do this.
(Hmm. If the CPUs were that smart, then we wouldn't need a flush at
all in some cases. If we lock cmpxchg to change W=1,D=0 to W=0,D=0,
then we know that no other CPU can subsequently write the page without
re-walking, and we don't need to flush.)
Can you ask the architecture folks to clarify the situation? And, if
your notes are indeed correct, don't we need code to handle spurious
faults?
--Andy
[PATCH] md: Unify mddev destruction paths
Previously, mddev_put() had a couple different paths for freeing a
mddev, due to the fact that the kobject wasn't initialized when the
mddev was first allocated. If we move the kobject_init() to when it's
first allocated and just use kobject_add() later, we can clean all this
up.
This also removes a hack in mddev_put() to avoid freeing biosets under a
spinlock, which involved copying biosets on the stack after the reset
bioset_init() changes.
Signed-off-by: Kent Overstreet
---
drivers/md/md.c | 53 +
1 file changed, 18 insertions(+), 35 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index fc692b7128..22203eba1e 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -84,6 +84,8 @@ static void autostart_arrays(int part);
static LIST_HEAD(pers_list);
static DEFINE_SPINLOCK(pers_lock);
+static struct kobj_type md_ktype;
+
struct md_cluster_operations *md_cluster_ops;
EXPORT_SYMBOL(md_cluster_ops);
struct module *md_cluster_mod;
@@ -510,11 +512,6 @@ static void mddev_delayed_delete(struct work_struct *ws);
static void mddev_put(struct mddev *mddev)
{
- struct bio_set bs, sync_bs;
-
- memset(, 0, sizeof(bs));
- memset(_bs, 0, sizeof(sync_bs));
-
if (!atomic_dec_and_lock(>active, _mddevs_lock))
return;
if (!mddev->raid_disks && list_empty(>disks) &&
@@ -522,30 +519,23 @@ static void mddev_put(struct mddev *mddev)
/* Array is not configured at all, and not held active,
* so destroy it */
list_del_init(>all_mddevs);
- bs = mddev->bio_set;
- sync_bs = mddev->sync_set;
- memset(>bio_set, 0, sizeof(mddev->bio_set));
- memset(>sync_set, 0, sizeof(mddev->sync_set));
- if (mddev->gendisk) {
- /* We did a probe so need to clean up. Call
-* queue_work inside the spinlock so that
-* flush_workqueue() after mddev_find will
-* succeed in waiting for the work to be done.
-*/
- INIT_WORK(>del_work, mddev_delayed_delete);
- queue_work(md_misc_wq, >del_work);
- } else
- kfree(mddev);
+
+ /*
+* Call queue_work inside the spinlock so that
+* flush_workqueue() after mddev_find will succeed in waiting
+* for the work to be done.
+*/
+ INIT_WORK(>del_work, mddev_delayed_delete);
+ queue_work(md_misc_wq, >del_work);
}
spin_unlock(_mddevs_lock);
- bioset_exit();
- bioset_exit(_bs);
}
static void md_safemode_timeout(struct timer_list *t);
void mddev_init(struct mddev *mddev)
{
+ kobject_init(>kobj, _ktype);
mutex_init(>open_mutex);
mutex_init(>reconfig_mutex);
mutex_init(>bitmap_info.mutex);
@@ -5215,6 +5205,8 @@ static void md_free(struct kobject *ko)
put_disk(mddev->gendisk);
percpu_ref_exit(>writes_pending);
+ bioset_exit(>bio_set);
+ bioset_exit(>sync_set);
kfree(mddev);
}
@@ -5348,8 +5340,7 @@ static int md_alloc(dev_t dev, char *name)
mutex_lock(>open_mutex);
add_disk(disk);
- error = kobject_init_and_add(>kobj, _ktype,
-_to_dev(disk)->kobj, "%s", "md");
+ error = kobject_add(>kobj, _to_dev(disk)->kobj, "%s", "md");
if (error) {
/* This isn't possible, but as kobject_init_and_add is marked
* __must_check, we must do something with the result
@@ -5506,7 +5497,7 @@ int md_run(struct mddev *mddev)
if (!bioset_initialized(>sync_set)) {
err = bioset_init(>sync_set, BIO_POOL_SIZE, 0,
BIOSET_NEED_BVECS);
if (err)
- goto abort;
+ return err;
}
spin_lock(_lock);
@@ -5519,8 +5510,7 @@ int md_run(struct mddev *mddev)
else
pr_warn("md: personality for level %s is not loaded!\n",
mddev->clevel);
- err = -EINVAL;
- goto abort;
+ return -EINVAL;
}
spin_unlock(_lock);
if (mddev->level != pers->level) {
@@ -5533,8 +5523,7 @@ int md_run(struct mddev *mddev)
pers->start_reshape == NULL) {
/* This personality cannot handle reshaping... */
module_put(pers->owner);
- err = -EINVAL;
- goto abort;
+ return -EINVAL;
}
if (pers->sync_request) {
@@ -5603,7 +5592,7 @@ int md_run(struct mddev *mddev)
mddev->private = NULL;
module_put(pers->owner);
bitmap_destroy(mddev);
- goto abort;
+
[PATCH] md: Unify mddev destruction paths
Previously, mddev_put() had a couple different paths for freeing a
mddev, due to the fact that the kobject wasn't initialized when the
mddev was first allocated. If we move the kobject_init() to when it's
first allocated and just use kobject_add() later, we can clean all this
up.
This also removes a hack in mddev_put() to avoid freeing biosets under a
spinlock, which involved copying biosets on the stack after the reset
bioset_init() changes.
Signed-off-by: Kent Overstreet
---
drivers/md/md.c | 53 +
1 file changed, 18 insertions(+), 35 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index fc692b7128..22203eba1e 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -84,6 +84,8 @@ static void autostart_arrays(int part);
static LIST_HEAD(pers_list);
static DEFINE_SPINLOCK(pers_lock);
+static struct kobj_type md_ktype;
+
struct md_cluster_operations *md_cluster_ops;
EXPORT_SYMBOL(md_cluster_ops);
struct module *md_cluster_mod;
@@ -510,11 +512,6 @@ static void mddev_delayed_delete(struct work_struct *ws);
static void mddev_put(struct mddev *mddev)
{
- struct bio_set bs, sync_bs;
-
- memset(, 0, sizeof(bs));
- memset(_bs, 0, sizeof(sync_bs));
-
if (!atomic_dec_and_lock(>active, _mddevs_lock))
return;
if (!mddev->raid_disks && list_empty(>disks) &&
@@ -522,30 +519,23 @@ static void mddev_put(struct mddev *mddev)
/* Array is not configured at all, and not held active,
* so destroy it */
list_del_init(>all_mddevs);
- bs = mddev->bio_set;
- sync_bs = mddev->sync_set;
- memset(>bio_set, 0, sizeof(mddev->bio_set));
- memset(>sync_set, 0, sizeof(mddev->sync_set));
- if (mddev->gendisk) {
- /* We did a probe so need to clean up. Call
-* queue_work inside the spinlock so that
-* flush_workqueue() after mddev_find will
-* succeed in waiting for the work to be done.
-*/
- INIT_WORK(>del_work, mddev_delayed_delete);
- queue_work(md_misc_wq, >del_work);
- } else
- kfree(mddev);
+
+ /*
+* Call queue_work inside the spinlock so that
+* flush_workqueue() after mddev_find will succeed in waiting
+* for the work to be done.
+*/
+ INIT_WORK(>del_work, mddev_delayed_delete);
+ queue_work(md_misc_wq, >del_work);
}
spin_unlock(_mddevs_lock);
- bioset_exit();
- bioset_exit(_bs);
}
static void md_safemode_timeout(struct timer_list *t);
void mddev_init(struct mddev *mddev)
{
+ kobject_init(>kobj, _ktype);
mutex_init(>open_mutex);
mutex_init(>reconfig_mutex);
mutex_init(>bitmap_info.mutex);
@@ -5215,6 +5205,8 @@ static void md_free(struct kobject *ko)
put_disk(mddev->gendisk);
percpu_ref_exit(>writes_pending);
+ bioset_exit(>bio_set);
+ bioset_exit(>sync_set);
kfree(mddev);
}
@@ -5348,8 +5340,7 @@ static int md_alloc(dev_t dev, char *name)
mutex_lock(>open_mutex);
add_disk(disk);
- error = kobject_init_and_add(>kobj, _ktype,
-_to_dev(disk)->kobj, "%s", "md");
+ error = kobject_add(>kobj, _to_dev(disk)->kobj, "%s", "md");
if (error) {
/* This isn't possible, but as kobject_init_and_add is marked
* __must_check, we must do something with the result
@@ -5506,7 +5497,7 @@ int md_run(struct mddev *mddev)
if (!bioset_initialized(>sync_set)) {
err = bioset_init(>sync_set, BIO_POOL_SIZE, 0,
BIOSET_NEED_BVECS);
if (err)
- goto abort;
+ return err;
}
spin_lock(_lock);
@@ -5519,8 +5510,7 @@ int md_run(struct mddev *mddev)
else
pr_warn("md: personality for level %s is not loaded!\n",
mddev->clevel);
- err = -EINVAL;
- goto abort;
+ return -EINVAL;
}
spin_unlock(_lock);
if (mddev->level != pers->level) {
@@ -5533,8 +5523,7 @@ int md_run(struct mddev *mddev)
pers->start_reshape == NULL) {
/* This personality cannot handle reshaping... */
module_put(pers->owner);
- err = -EINVAL;
- goto abort;
+ return -EINVAL;
}
if (pers->sync_request) {
@@ -5603,7 +5592,7 @@ int md_run(struct mddev *mddev)
mddev->private = NULL;
module_put(pers->owner);
bitmap_destroy(mddev);
- goto abort;
+
linux-next: build failure after merge of the thermal tree
Hi Zhang,
After merging the thermal tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/thermal/qcom/tsens.c: In function 'tsens_probe':
drivers/thermal/qcom/tsens.c:144:31: error: 's' undeclared (first use in this
function)
num_sensors * sizeof(*s), GFP_KERNEL);
^
Caused by commit
6d7c70d1cd65 ("thermal: qcom: tsens: Allow number of sensors to come from DT")
interacting with commit
0ed2dd03b94b ("treewide: Use struct_size() for devm_kmalloc() and friends")
from Linus' tree. It looks like git somehow screwed up the automatic
conflict resolution.
I have added the following patch for today:
From: Stephen Rothwell
Date: Fri, 8 Jun 2018 10:46:46 +1000
Subject: [PATCH] thermal: gcom: fix up bad git conflict resolution
Signed-off-by: Stephen Rothwell
---
drivers/thermal/qcom/tsens.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index fb8c87f55240..6164fd36dda3 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -140,8 +140,8 @@ static int tsens_probe(struct platform_device *pdev)
return -EINVAL;
}
- tmdev = devm_kzalloc(dev, sizeof(*tmdev) +
-num_sensors * sizeof(*s), GFP_KERNEL);
+ tmdev = devm_kzalloc(dev, struct_size(tmdev, sensor, num_sensors),
+GFP_KERNEL);
if (!tmdev)
return -ENOMEM;
--
2.17.1
--
Cheers,
Stephen Rothwell
pgpoJtUFJ1A1z.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the thermal tree
Hi Zhang,
After merging the thermal tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/thermal/qcom/tsens.c: In function 'tsens_probe':
drivers/thermal/qcom/tsens.c:144:31: error: 's' undeclared (first use in this
function)
num_sensors * sizeof(*s), GFP_KERNEL);
^
Caused by commit
6d7c70d1cd65 ("thermal: qcom: tsens: Allow number of sensors to come from DT")
interacting with commit
0ed2dd03b94b ("treewide: Use struct_size() for devm_kmalloc() and friends")
from Linus' tree. It looks like git somehow screwed up the automatic
conflict resolution.
I have added the following patch for today:
From: Stephen Rothwell
Date: Fri, 8 Jun 2018 10:46:46 +1000
Subject: [PATCH] thermal: gcom: fix up bad git conflict resolution
Signed-off-by: Stephen Rothwell
---
drivers/thermal/qcom/tsens.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index fb8c87f55240..6164fd36dda3 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -140,8 +140,8 @@ static int tsens_probe(struct platform_device *pdev)
return -EINVAL;
}
- tmdev = devm_kzalloc(dev, sizeof(*tmdev) +
-num_sensors * sizeof(*s), GFP_KERNEL);
+ tmdev = devm_kzalloc(dev, struct_size(tmdev, sensor, num_sensors),
+GFP_KERNEL);
if (!tmdev)
return -ENOMEM;
--
2.17.1
--
Cheers,
Stephen Rothwell
pgpoJtUFJ1A1z.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the pm tree
Hi all,
After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
WARNING: vmlinux.o(.text+0xc5b83a): Section mismatch in reference from the
function __intel_pstate_cpu_init() to the variable
.init.rodata:intel_pstate_hwp_boost_ids
The function __intel_pstate_cpu_init() references
the variable __initconst intel_pstate_hwp_boost_ids.
This is often because __intel_pstate_cpu_init lacks a __initconst
annotation or the annotation of intel_pstate_hwp_boost_ids is wrong.
Introduced by commit
f50f70793d78 ("cpufreq: intel_pstate: enable boost for Skylake Xeon")
--
Cheers,
Stephen Rothwell
pgpSpUhoBYGpn.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the pm tree
Hi all,
After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
WARNING: vmlinux.o(.text+0xc5b83a): Section mismatch in reference from the
function __intel_pstate_cpu_init() to the variable
.init.rodata:intel_pstate_hwp_boost_ids
The function __intel_pstate_cpu_init() references
the variable __initconst intel_pstate_hwp_boost_ids.
This is often because __intel_pstate_cpu_init lacks a __initconst
annotation or the annotation of intel_pstate_hwp_boost_ids is wrong.
Introduced by commit
f50f70793d78 ("cpufreq: intel_pstate: enable boost for Skylake Xeon")
--
Cheers,
Stephen Rothwell
pgpSpUhoBYGpn.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 2/2] regulator: add QCOM RPMh regulator driver
Hi David,
On Mon, Jun 04, 2018 at 12:15:12PM -0700, David Collins wrote:
> Add the QCOM RPMh regulator driver to manage PMIC regulators
> which are controlled via RPMh on some Qualcomm Technologies, Inc.
> SoCs. RPMh is a hardware block which contains several
> accelerators which are used to manage various hardware resources
> that are shared between the processors of the SoC. The final
> hardware state of a regulator is determined within RPMh by
> performing max aggregation of the requests made by all of the
> processors.
>
> Add support for PMIC regulator control via the voltage regulator
> manager (VRM) and oscillator buffer (XOB) RPMh accelerators.
> VRM supports manipulation of enable state, voltage, and mode.
> XOB supports manipulation of enable state.
>
> Signed-off-by: David Collins
> ---
> drivers/regulator/Kconfig | 9 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/qcom-rpmh-regulator.c | 767
>
> 3 files changed, 777 insertions(+)
> create mode 100644 drivers/regulator/qcom-rpmh-regulator.c
>
> ...
>
> diff --git a/drivers/regulator/qcom-rpmh-regulator.c
> b/drivers/regulator/qcom-rpmh-regulator.c
> new file mode 100644
> index 000..a7fffb6
> --- /dev/null
> +++ b/drivers/regulator/qcom-rpmh-regulator.c
>
> ...
> static int rpmh_regulator_send_request(struct rpmh_vreg *vreg,
> + struct tcs_cmd *cmd, int count, bool wait_for_ack)
>
nit: as of now this is only called with a single command. If you
anticipate that this is unlikely to change consider removing 'count',
not having it in the calls slightly improves readability.
> ...
> +static int _rpmh_regulator_vrm_set_voltage_sel(struct regulator_dev *rdev,
> + unsigned int selector, bool wait_for_ack)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_VRM_VOLTAGE,
> + };
> + int ret;
> +
> + /* VRM voltage control register is set with voltage in millivolts. */
> + cmd.data = DIV_ROUND_UP(regulator_list_voltage_linear_range(rdev,
> + selector), 1000);
> +
> + ret = rpmh_regulator_send_request(vreg, , 1, wait_for_ack);
> + if (!ret)
> + vreg->voltage_selector = selector;
> +
> + return 0;
Shouldn't this return 'ret'?
> +static int rpmh_regulator_enable(struct regulator_dev *rdev)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE,
> + .data = 1,
> + };
> + int ret;
> +
> + if (vreg->enabled == -EINVAL &&
> + vreg->voltage_selector != -ENOTRECOVERABLE) {
> + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev,
> + vreg->voltage_selector, true);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = rpmh_regulator_send_request(vreg, , 1, true);
> + if (!ret)
> + vreg->enabled = true;
> +
> + return ret;
> +}
> +
> +static int rpmh_regulator_disable(struct regulator_dev *rdev)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE,
> + .data = 0,
> + };
> + int ret;
> +
> + if (vreg->enabled == -EINVAL &&
> + vreg->voltage_selector != -ENOTRECOVERABLE) {
> + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev,
> + vreg->voltage_selector, true);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = rpmh_regulator_send_request(vreg, , 1, false);
> + if (!ret)
> + vreg->enabled = false;
> +
> + return ret;
> +}
nit: rpmh_regulator_enable() and rpmh_regulator_disable() are
essentially the same code, consider introducing a helper like
_rpmh_regulator_enable(struct regulator_dev *rdev, bool enable).
> +/**
> + * rpmh_regulator_init_vreg() - initialize all attributes of an
> rpmh-regulator
> + * vreg: Pointer to the individual rpmh-regulator resource
> + * dev: Pointer to the top level rpmh-regulator PMIC
> device
> + * node: Pointer to the individual rpmh-regulator resource
> + * device node
> + * pmic_id: String used to identify the top level rpmh-regulator
> + * PMIC device on the board
> + * rpmh_data:Pointer to a null-terminated array of
> rpmh-regulator
> + * resources defined for the top level PMIC device
> + *
> + * Return: 0 on success, errno on failure
> + */
> +static int rpmh_regulator_init_vreg(struct rpmh_vreg *vreg, struct device
> *dev,
> + struct device_node *node, const char
Re: [PATCH v6 2/2] regulator: add QCOM RPMh regulator driver
Hi David,
On Mon, Jun 04, 2018 at 12:15:12PM -0700, David Collins wrote:
> Add the QCOM RPMh regulator driver to manage PMIC regulators
> which are controlled via RPMh on some Qualcomm Technologies, Inc.
> SoCs. RPMh is a hardware block which contains several
> accelerators which are used to manage various hardware resources
> that are shared between the processors of the SoC. The final
> hardware state of a regulator is determined within RPMh by
> performing max aggregation of the requests made by all of the
> processors.
>
> Add support for PMIC regulator control via the voltage regulator
> manager (VRM) and oscillator buffer (XOB) RPMh accelerators.
> VRM supports manipulation of enable state, voltage, and mode.
> XOB supports manipulation of enable state.
>
> Signed-off-by: David Collins
> ---
> drivers/regulator/Kconfig | 9 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/qcom-rpmh-regulator.c | 767
>
> 3 files changed, 777 insertions(+)
> create mode 100644 drivers/regulator/qcom-rpmh-regulator.c
>
> ...
>
> diff --git a/drivers/regulator/qcom-rpmh-regulator.c
> b/drivers/regulator/qcom-rpmh-regulator.c
> new file mode 100644
> index 000..a7fffb6
> --- /dev/null
> +++ b/drivers/regulator/qcom-rpmh-regulator.c
>
> ...
> static int rpmh_regulator_send_request(struct rpmh_vreg *vreg,
> + struct tcs_cmd *cmd, int count, bool wait_for_ack)
>
nit: as of now this is only called with a single command. If you
anticipate that this is unlikely to change consider removing 'count',
not having it in the calls slightly improves readability.
> ...
> +static int _rpmh_regulator_vrm_set_voltage_sel(struct regulator_dev *rdev,
> + unsigned int selector, bool wait_for_ack)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_VRM_VOLTAGE,
> + };
> + int ret;
> +
> + /* VRM voltage control register is set with voltage in millivolts. */
> + cmd.data = DIV_ROUND_UP(regulator_list_voltage_linear_range(rdev,
> + selector), 1000);
> +
> + ret = rpmh_regulator_send_request(vreg, , 1, wait_for_ack);
> + if (!ret)
> + vreg->voltage_selector = selector;
> +
> + return 0;
Shouldn't this return 'ret'?
> +static int rpmh_regulator_enable(struct regulator_dev *rdev)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE,
> + .data = 1,
> + };
> + int ret;
> +
> + if (vreg->enabled == -EINVAL &&
> + vreg->voltage_selector != -ENOTRECOVERABLE) {
> + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev,
> + vreg->voltage_selector, true);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = rpmh_regulator_send_request(vreg, , 1, true);
> + if (!ret)
> + vreg->enabled = true;
> +
> + return ret;
> +}
> +
> +static int rpmh_regulator_disable(struct regulator_dev *rdev)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE,
> + .data = 0,
> + };
> + int ret;
> +
> + if (vreg->enabled == -EINVAL &&
> + vreg->voltage_selector != -ENOTRECOVERABLE) {
> + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev,
> + vreg->voltage_selector, true);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = rpmh_regulator_send_request(vreg, , 1, false);
> + if (!ret)
> + vreg->enabled = false;
> +
> + return ret;
> +}
nit: rpmh_regulator_enable() and rpmh_regulator_disable() are
essentially the same code, consider introducing a helper like
_rpmh_regulator_enable(struct regulator_dev *rdev, bool enable).
> +/**
> + * rpmh_regulator_init_vreg() - initialize all attributes of an
> rpmh-regulator
> + * vreg: Pointer to the individual rpmh-regulator resource
> + * dev: Pointer to the top level rpmh-regulator PMIC
> device
> + * node: Pointer to the individual rpmh-regulator resource
> + * device node
> + * pmic_id: String used to identify the top level rpmh-regulator
> + * PMIC device on the board
> + * rpmh_data:Pointer to a null-terminated array of
> rpmh-regulator
> + * resources defined for the top level PMIC device
> + *
> + * Return: 0 on success, errno on failure
> + */
> +static int rpmh_regulator_init_vreg(struct rpmh_vreg *vreg, struct device
> *dev,
> + struct device_node *node, const char
[PATCH] kbuild: fix endless syncconfig in case arch Makefile sets CROSS_COMPILE
Commit 21c54b774744 ("kconfig: show compiler version text in the top
comment") was intended to detect the compiler upgrade, but Geert
reported a breakage on the m68k build.
The compiler upgrade is detected by the change of the environment
variable, CC_VERSION_TEXT, which contains the first line of the output
from $(CC) --version. Currently, this works well when CROSS_COMPILE
is given via the environment variable or the Make command line.
However, some architectures such as m68k can specify CROSS_COMPILE
from arch/$(SRCARCH)/Makefile as well. In this case, "make ARCH=m68k"
ends up with endless syncconfig loop.
$ make ARCH=m68k defconfig
*** Default configuration is based on 'multi_defconfig'
#
# configuration written to .config
#
$ make ARCH=m68k
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
Things are happening like this:
Because arch/$(SRCARCH)/Makefile is included after CC_VERSION_TEXT
is set, it contains the host compiler version in the defconfig phase.
To create or update auto.conf, the following line is triggered:
include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
This recurses the top Makefile after arch/$(SRCARCH)/Makefile is
included. CROSS_COMPILE is set to a m68k toolchain prefix and
exported to the recursed Make. Then, syncconfig is invoked with
the target compiler version in CC_VERSION_TEXT.
The Make will restart because auto.conf and auto.conf.cmd have been
updated. At this point, CROSS_COMPILE is reset, so CC_VERSION_TEXT
is set to the host compiler version again. Then, syncconfig is
triggered due to the change of CC_VERSION_TEXT. This loop continues
eternally.
To fix this problem, $(CC_VERSION_TEXT) must be evaluated only after
arch/$(SRCARCH)/Makefile. Setting it earlier is OK as long as it is
defined by using the '=' operator instead of ':='.
For the defconfig phase, $(CC_VERSION_TEXT) is evaluated when Kbuild
descends into scripts/kconfig/, so it contains the target compiler
version correctly.
include/config/auto.conf.cmd references $(CC_VERSION_TEXT) as well,
so it must be included after arch/$(SRCARCH)/Makefile.
Fixes: 21c54b774744 ("kconfig: show compiler version text in the top comment")
Reported-by: Geert Uytterhoeven
Signed-off-by: Masahiro Yamada
---
Makefile | 54 ++
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/Makefile b/Makefile
index 019a5a0..747edaf 100644
--- a/Makefile
+++ b/Makefile
@@ -442,8 +442,6 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE
KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
export KBUILD_ARFLAGS
-export CC_VERSION_TEXT := $(shell $(CC) --version | head -n 1)
-
# When compiling out-of-tree modules, put MODVERDIR in the module
# tree rather than in the kernel tree. The kernel tree might
# even be read-only.
@@ -514,6 +512,12 @@ ifeq ($(shell $(CONFIG_SHELL)
$(srctree)/scripts/cc-can-link.sh $(CC)), y)
export CC_CAN_LINK
endif
+# The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
+# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
+# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
+# and from include/config/auto.conf.cmd to detect the compiler upgrade.
+CC_VERSION_TEXT = $(shell $(CC) --version | head -n 1)
+
ifeq ($(config-targets),1)
# ===
# *config targets only - make sure prerequisites are updated, and descend
@@ -523,7 +527,7 @@ ifeq ($(config-targets),1)
# KBUILD_DEFCONFIG may point out an alternative default configuration
# used for 'make defconfig'
include arch/$(SRCARCH)/Makefile
-export KBUILD_DEFCONFIG KBUILD_KCONFIG
+export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT
config: scripts_basic outputmakefile FORCE
$(Q)$(MAKE) $(build)=scripts/kconfig $@
@@ -585,12 +589,32 @@ virt-y:= virt/
endif # KBUILD_EXTMOD
ifeq ($(dot-config),1)
-# Read in config
-include include/config/auto.conf
+endif
+
+# The all: target is the default when no target is given on the
+# command line.
+# This allow a user to issue only 'make' to build a kernel including modules
+# Defaults to vmlinux, but the arch makefile usually adds further targets
+all: vmlinux
+
+CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage \
+ $(call cc-option,-fno-tree-loop-im) \
+ $(call cc-disable-warning,maybe-uninitialized,)
+export CFLAGS_GCOV CFLAGS_KCOV
+
+# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
+# values of the respective KBUILD_* variables
+ARCH_CPPFLAGS :=
+ARCH_AFLAGS :=
+ARCH_CFLAGS :=
+include arch/$(SRCARCH)/Makefile
+ifeq ($(dot-config),1)
ifeq ($(KBUILD_EXTMOD),)
-# Read in dependencies to all Kconfig* files, make sure
[PATCH] kbuild: fix endless syncconfig in case arch Makefile sets CROSS_COMPILE
Commit 21c54b774744 ("kconfig: show compiler version text in the top
comment") was intended to detect the compiler upgrade, but Geert
reported a breakage on the m68k build.
The compiler upgrade is detected by the change of the environment
variable, CC_VERSION_TEXT, which contains the first line of the output
from $(CC) --version. Currently, this works well when CROSS_COMPILE
is given via the environment variable or the Make command line.
However, some architectures such as m68k can specify CROSS_COMPILE
from arch/$(SRCARCH)/Makefile as well. In this case, "make ARCH=m68k"
ends up with endless syncconfig loop.
$ make ARCH=m68k defconfig
*** Default configuration is based on 'multi_defconfig'
#
# configuration written to .config
#
$ make ARCH=m68k
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
Things are happening like this:
Because arch/$(SRCARCH)/Makefile is included after CC_VERSION_TEXT
is set, it contains the host compiler version in the defconfig phase.
To create or update auto.conf, the following line is triggered:
include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
This recurses the top Makefile after arch/$(SRCARCH)/Makefile is
included. CROSS_COMPILE is set to a m68k toolchain prefix and
exported to the recursed Make. Then, syncconfig is invoked with
the target compiler version in CC_VERSION_TEXT.
The Make will restart because auto.conf and auto.conf.cmd have been
updated. At this point, CROSS_COMPILE is reset, so CC_VERSION_TEXT
is set to the host compiler version again. Then, syncconfig is
triggered due to the change of CC_VERSION_TEXT. This loop continues
eternally.
To fix this problem, $(CC_VERSION_TEXT) must be evaluated only after
arch/$(SRCARCH)/Makefile. Setting it earlier is OK as long as it is
defined by using the '=' operator instead of ':='.
For the defconfig phase, $(CC_VERSION_TEXT) is evaluated when Kbuild
descends into scripts/kconfig/, so it contains the target compiler
version correctly.
include/config/auto.conf.cmd references $(CC_VERSION_TEXT) as well,
so it must be included after arch/$(SRCARCH)/Makefile.
Fixes: 21c54b774744 ("kconfig: show compiler version text in the top comment")
Reported-by: Geert Uytterhoeven
Signed-off-by: Masahiro Yamada
---
Makefile | 54 ++
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/Makefile b/Makefile
index 019a5a0..747edaf 100644
--- a/Makefile
+++ b/Makefile
@@ -442,8 +442,6 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE
KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
export KBUILD_ARFLAGS
-export CC_VERSION_TEXT := $(shell $(CC) --version | head -n 1)
-
# When compiling out-of-tree modules, put MODVERDIR in the module
# tree rather than in the kernel tree. The kernel tree might
# even be read-only.
@@ -514,6 +512,12 @@ ifeq ($(shell $(CONFIG_SHELL)
$(srctree)/scripts/cc-can-link.sh $(CC)), y)
export CC_CAN_LINK
endif
+# The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
+# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
+# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
+# and from include/config/auto.conf.cmd to detect the compiler upgrade.
+CC_VERSION_TEXT = $(shell $(CC) --version | head -n 1)
+
ifeq ($(config-targets),1)
# ===
# *config targets only - make sure prerequisites are updated, and descend
@@ -523,7 +527,7 @@ ifeq ($(config-targets),1)
# KBUILD_DEFCONFIG may point out an alternative default configuration
# used for 'make defconfig'
include arch/$(SRCARCH)/Makefile
-export KBUILD_DEFCONFIG KBUILD_KCONFIG
+export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT
config: scripts_basic outputmakefile FORCE
$(Q)$(MAKE) $(build)=scripts/kconfig $@
@@ -585,12 +589,32 @@ virt-y:= virt/
endif # KBUILD_EXTMOD
ifeq ($(dot-config),1)
-# Read in config
-include include/config/auto.conf
+endif
+
+# The all: target is the default when no target is given on the
+# command line.
+# This allow a user to issue only 'make' to build a kernel including modules
+# Defaults to vmlinux, but the arch makefile usually adds further targets
+all: vmlinux
+
+CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage \
+ $(call cc-option,-fno-tree-loop-im) \
+ $(call cc-disable-warning,maybe-uninitialized,)
+export CFLAGS_GCOV CFLAGS_KCOV
+
+# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
+# values of the respective KBUILD_* variables
+ARCH_CPPFLAGS :=
+ARCH_AFLAGS :=
+ARCH_CFLAGS :=
+include arch/$(SRCARCH)/Makefile
+ifeq ($(dot-config),1)
ifeq ($(KBUILD_EXTMOD),)
-# Read in dependencies to all Kconfig* files, make sure
Re: [PATCH v5 07/28] fpga: dfl: add chardev support for feature devices
On Thu, Jun 07, 2018 at 01:03:18PM -0500, Alan Tull wrote:
> On Wed, Jun 6, 2018 at 7:24 AM, Wu Hao wrote:
>
> Hi Hao,
>
> One more...
>
> >> > +static dev_t dfl_get_devt(enum dfl_fpga_devt_type type, int id)
> >> > +{
> >> > + WARN_ON(type >= DFL_FPGA_DEVT_MAX);
> >> > +
> >> > + return MKDEV(MAJOR(dfl_chrdevs[type].devt), id);
> >> > +}
> >> > +
> >> > +/**
> >> > + * dfl_fpga_register_dev_ops - register cdev ops for feature dev
> >> > + *
> >> > + * @pdev: feature dev.
> >> > + * @fops: file operations for feature dev's cdev.
> >> > + * @owner: owning module/driver.
> >> > + *
> >> > + * Return: 0 on success, negative error code otherwise.
> >> > + */
> >> > +int dfl_fpga_register_dev_ops(struct platform_device *pdev,
> >> > + const struct file_operations *fops,
> >> > + struct module *owner)
> >> > +{
> >> > + struct dfl_feature_platform_data *pdata =
> >> > dev_get_platdata(>dev);
> >> > +
> >> > + cdev_init(>cdev, fops);
> >> > + pdata->cdev.owner = owner;
> >> > +
> >> > + /*
> >> > +* set parent to the feature device so that its refcount is
> >> > +* decreased after the last refcount of cdev is gone, that
> >> > +* makes sure the feature device is valid during device
> >> > +* file's life-cycle.
> >> > +*/
> >> > + pdata->cdev.kobj.parent = >dev.kobj;
> >> > +
> >> > + return cdev_add(>cdev, pdev->dev.devt, 1);
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(dfl_fpga_register_dev_ops);
> >> > +
> >> > +/**
> >> > + * dfl_fpga_unregister_dev_ops - unregister cdev ops for feature dev
> >> > + * @pdev: feature dev.
> >> > + */
> >> > +void dfl_fpga_unregister_dev_ops(struct platform_device *pdev)
> >> > +{
> >> > + struct dfl_feature_platform_data *pdata =
> >> > dev_get_platdata(>dev);
> >> > +
> >> > + cdev_del(>cdev);
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(dfl_fpga_unregister_dev_ops);
>
> How about dfl_fpga_dev_ops_register/unregister?
Sure, will fix this in the v6. Thanks.
Hao
>
> Thanks,
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 07/28] fpga: dfl: add chardev support for feature devices
On Thu, Jun 07, 2018 at 01:03:18PM -0500, Alan Tull wrote:
> On Wed, Jun 6, 2018 at 7:24 AM, Wu Hao wrote:
>
> Hi Hao,
>
> One more...
>
> >> > +static dev_t dfl_get_devt(enum dfl_fpga_devt_type type, int id)
> >> > +{
> >> > + WARN_ON(type >= DFL_FPGA_DEVT_MAX);
> >> > +
> >> > + return MKDEV(MAJOR(dfl_chrdevs[type].devt), id);
> >> > +}
> >> > +
> >> > +/**
> >> > + * dfl_fpga_register_dev_ops - register cdev ops for feature dev
> >> > + *
> >> > + * @pdev: feature dev.
> >> > + * @fops: file operations for feature dev's cdev.
> >> > + * @owner: owning module/driver.
> >> > + *
> >> > + * Return: 0 on success, negative error code otherwise.
> >> > + */
> >> > +int dfl_fpga_register_dev_ops(struct platform_device *pdev,
> >> > + const struct file_operations *fops,
> >> > + struct module *owner)
> >> > +{
> >> > + struct dfl_feature_platform_data *pdata =
> >> > dev_get_platdata(>dev);
> >> > +
> >> > + cdev_init(>cdev, fops);
> >> > + pdata->cdev.owner = owner;
> >> > +
> >> > + /*
> >> > +* set parent to the feature device so that its refcount is
> >> > +* decreased after the last refcount of cdev is gone, that
> >> > +* makes sure the feature device is valid during device
> >> > +* file's life-cycle.
> >> > +*/
> >> > + pdata->cdev.kobj.parent = >dev.kobj;
> >> > +
> >> > + return cdev_add(>cdev, pdev->dev.devt, 1);
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(dfl_fpga_register_dev_ops);
> >> > +
> >> > +/**
> >> > + * dfl_fpga_unregister_dev_ops - unregister cdev ops for feature dev
> >> > + * @pdev: feature dev.
> >> > + */
> >> > +void dfl_fpga_unregister_dev_ops(struct platform_device *pdev)
> >> > +{
> >> > + struct dfl_feature_platform_data *pdata =
> >> > dev_get_platdata(>dev);
> >> > +
> >> > + cdev_del(>cdev);
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(dfl_fpga_unregister_dev_ops);
>
> How about dfl_fpga_dev_ops_register/unregister?
Sure, will fix this in the v6. Thanks.
Hao
>
> Thanks,
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] HID: google: Add support for whiskers
Another device in the hammer class, with USB id 0x5030.
Signed-off-by: Nicolas Boichat
---
drivers/hid/hid-google-hammer.c | 2 ++
drivers/hid/hid-ids.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 7b8e17b03cb86..6bf4da7ad63a5 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -124,6 +124,8 @@ static const struct hid_device_id hammer_devices[] = {
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },
+ { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
+USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WHISKERS) },
{ }
};
MODULE_DEVICE_TABLE(hid, hammer_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index a85634fe033f0..c7981ddd87763 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -452,6 +452,7 @@
#define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE0x5028
#define USB_DEVICE_ID_GOOGLE_STAFF 0x502b
#define USB_DEVICE_ID_GOOGLE_WAND 0x502d
+#define USB_DEVICE_ID_GOOGLE_WHISKERS 0x5030
#define USB_VENDOR_ID_GOTOP0x08f2
#define USB_DEVICE_ID_SUPER_Q2 0x007f
--
2.18.0.rc1.242.g61856ae69a-goog
[PATCH] HID: google: Add support for whiskers
Another device in the hammer class, with USB id 0x5030.
Signed-off-by: Nicolas Boichat
---
drivers/hid/hid-google-hammer.c | 2 ++
drivers/hid/hid-ids.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 7b8e17b03cb86..6bf4da7ad63a5 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -124,6 +124,8 @@ static const struct hid_device_id hammer_devices[] = {
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },
+ { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
+USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WHISKERS) },
{ }
};
MODULE_DEVICE_TABLE(hid, hammer_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index a85634fe033f0..c7981ddd87763 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -452,6 +452,7 @@
#define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE0x5028
#define USB_DEVICE_ID_GOOGLE_STAFF 0x502b
#define USB_DEVICE_ID_GOOGLE_WAND 0x502d
+#define USB_DEVICE_ID_GOOGLE_WHISKERS 0x5030
#define USB_VENDOR_ID_GOTOP0x08f2
#define USB_DEVICE_ID_SUPER_Q2 0x007f
--
2.18.0.rc1.242.g61856ae69a-goog
Re: [PATCH 09/10] perf/cputime: Don't stop idle tick if there's live cputime event
On Thu, Jun 07, 2018 at 09:01:30AM -0700, Stephane Eranian wrote: > Hi Jiri, > > On Thu, Jun 7, 2018 at 8:45 AM Andi Kleen wrote: > > > > On Thu, Jun 07, 2018 at 12:15:12AM +0200, Jiri Olsa wrote: > > > Disable stopping of the idle tick when having live cputime > > > event. When the tick is disabled, the idle counts are out > > > of date until next tick/update and perf cputime PMU provides > > > misleading counts. > > > > I really don't like this. This can totally change performance > > (e.g. less Turbo due to less idle) and performance tools shouldn't > > change the performance profile drastically. > > > You do not want to change the behavior of the kernel just because you > are monitoring. > This may introduce side effects on other events which may not otherwise exist. right.. I guess we can survive few seconds of misleading idle counts and perhaps we could detect nohz is enabled and warn about this thanks, jirka
Re: [PATCH 09/10] perf/cputime: Don't stop idle tick if there's live cputime event
On Thu, Jun 07, 2018 at 09:01:30AM -0700, Stephane Eranian wrote: > Hi Jiri, > > On Thu, Jun 7, 2018 at 8:45 AM Andi Kleen wrote: > > > > On Thu, Jun 07, 2018 at 12:15:12AM +0200, Jiri Olsa wrote: > > > Disable stopping of the idle tick when having live cputime > > > event. When the tick is disabled, the idle counts are out > > > of date until next tick/update and perf cputime PMU provides > > > misleading counts. > > > > I really don't like this. This can totally change performance > > (e.g. less Turbo due to less idle) and performance tools shouldn't > > change the performance profile drastically. > > > You do not want to change the behavior of the kernel just because you > are monitoring. > This may introduce side effects on other events which may not otherwise exist. right.. I guess we can survive few seconds of misleading idle counts and perhaps we could detect nohz is enabled and warn about this thanks, jirka
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
On 06/06/2018 04:16 PM, Jayant Chowdhary wrote:
> In order for static analysis tools to analyze each of the uapi headers,
> we need to enable them to compile stand-alone. Some uapi headers were
> missing dependencies which would not make them compile stand-alone in
> user-land. This patch adds those dependencies.
Hi,
Thanks for getting started on this. I see that the kbuild robot and I were
still not able to do successful builds even after this patch is applied.
We were building different targets though. robot was doing kernel builds
and I was doing a large "all-uapi" build.
I started on my all-uapi work about 1 week ago but haven't posted anything yet,
but it's posted (attached) below. It's not yet up to kernel quality yet (for a
Makefile), and I have made very little progress toward a successful userspace
build.
If anyone is interested, just put these 3 files in /tools/build
and then run:
make ARCH=$some_arch O=build_dir headers_check
so that the headers will be cleaned up and installed in build_dir/usr/.
Then run 'make -f all-uapi.mk'
and the userspace program with all header files found in build_dir/usr/include
will be built -- i.e., attempted (not successfully).
(note: chmod +x hdr-fix-lines.pl)
--
~Randy
# all-uapi.mk
# currently resides in tools/build/
#
# before running 'make -f all-uapi.mk',
# run (from top of kernel tree): make ARCH=arch O=dir headers_check
# so that the uapi headers will be installed.
srctree=../..
CC=gcc
all: all-uapi.h all-uapi.o
all-uapi.h: all-uapi.mk hdr-fix-lines.pl
rm -f all-uapi.h
touch all-uapi.h
# find $(srctree)/xx64/usr/include/uapi -type f | grep -v \\.orig |
find $(srctree)/xx64/usr/include -type f | grep -v \\.orig | \
./hdr-fix-lines.pl >>all-uapi.h
all-uapi.o: all-uapi.h
$(CC) -I../../xx64/usr/include all-uapi.c -o all-uapi.o
// SPDX GPL 2.0
// This userspace source file pulls in all #include header files
// to see what kinds of problems happen.
#include
#include
#include
#include
#include
#include "all-uapi.h"
int main(int argc, char *argv[])
{
}
hdr-fix-lines.pl
Description: Perl program
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
On 06/06/2018 04:16 PM, Jayant Chowdhary wrote:
> In order for static analysis tools to analyze each of the uapi headers,
> we need to enable them to compile stand-alone. Some uapi headers were
> missing dependencies which would not make them compile stand-alone in
> user-land. This patch adds those dependencies.
Hi,
Thanks for getting started on this. I see that the kbuild robot and I were
still not able to do successful builds even after this patch is applied.
We were building different targets though. robot was doing kernel builds
and I was doing a large "all-uapi" build.
I started on my all-uapi work about 1 week ago but haven't posted anything yet,
but it's posted (attached) below. It's not yet up to kernel quality yet (for a
Makefile), and I have made very little progress toward a successful userspace
build.
If anyone is interested, just put these 3 files in /tools/build
and then run:
make ARCH=$some_arch O=build_dir headers_check
so that the headers will be cleaned up and installed in build_dir/usr/.
Then run 'make -f all-uapi.mk'
and the userspace program with all header files found in build_dir/usr/include
will be built -- i.e., attempted (not successfully).
(note: chmod +x hdr-fix-lines.pl)
--
~Randy
# all-uapi.mk
# currently resides in tools/build/
#
# before running 'make -f all-uapi.mk',
# run (from top of kernel tree): make ARCH=arch O=dir headers_check
# so that the uapi headers will be installed.
srctree=../..
CC=gcc
all: all-uapi.h all-uapi.o
all-uapi.h: all-uapi.mk hdr-fix-lines.pl
rm -f all-uapi.h
touch all-uapi.h
# find $(srctree)/xx64/usr/include/uapi -type f | grep -v \\.orig |
find $(srctree)/xx64/usr/include -type f | grep -v \\.orig | \
./hdr-fix-lines.pl >>all-uapi.h
all-uapi.o: all-uapi.h
$(CC) -I../../xx64/usr/include all-uapi.c -o all-uapi.o
// SPDX GPL 2.0
// This userspace source file pulls in all #include header files
// to see what kinds of problems happen.
#include
#include
#include
#include
#include
#include "all-uapi.h"
int main(int argc, char *argv[])
{
}
hdr-fix-lines.pl
Description: Perl program
Re: [PATCH 01/10] perf tools: Uniquify the event name if there's no other matched event
On Thu, Jun 07, 2018 at 09:09:10AM -0700, Stephane Eranian wrote: > On Wed, Jun 6, 2018 at 11:22 PM Jiri Olsa wrote: > > > > On Wed, Jun 06, 2018 at 04:19:02PM -0700, Andi Kleen wrote: > > > On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote: > > > > Currently by default we try to match the user specified PMU > > > > name to all PMU units available and use them to aggregate > > > > all matched PMUs event counts into one 'pattern' event. > > > > > > > > While this is useful for uncore events, it screws up names > > > > for other events, where this is not desirable, like: > > > > > > > > Before: > > > > # perf stat -e cp/cpu-cycles/ kill > > > > > > I assume you mean cpU/cpu-cycles/ > > > > > > > >Performance counter stats for 'kill': > > > > > > > >1,573,757 cp/cpu-cycles/ > > > > > > > > Keeping the pattern matching logic, but making the name unique > > > > in case there's no other match found. That fixes the example > > > > above and hopefully does not screw up anything else. > > > > > And the problem I have with this approach, is that you do not really > know what you are measuring. > You have not way of knowing that the count comes from multiple PMU instances: > > perf stat -a -e uncore_cb/clockticks/ kill > 0 uncore_cb/clockticks/ > > I think you need to report that this is aggregated from uncore_cbox_0 > and uncore_cbox_1. > Otherwise it is not clear what I am monitoring. And you hope that what > you match in the regex > is related. > In my example should say: > 0 uncore_cbox[0-1]/clockticks/ ok, makes sense.. also shouldnt be that hard to do.. will repost thanks, jirka
Re: [PATCH 01/10] perf tools: Uniquify the event name if there's no other matched event
On Thu, Jun 07, 2018 at 09:09:10AM -0700, Stephane Eranian wrote: > On Wed, Jun 6, 2018 at 11:22 PM Jiri Olsa wrote: > > > > On Wed, Jun 06, 2018 at 04:19:02PM -0700, Andi Kleen wrote: > > > On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote: > > > > Currently by default we try to match the user specified PMU > > > > name to all PMU units available and use them to aggregate > > > > all matched PMUs event counts into one 'pattern' event. > > > > > > > > While this is useful for uncore events, it screws up names > > > > for other events, where this is not desirable, like: > > > > > > > > Before: > > > > # perf stat -e cp/cpu-cycles/ kill > > > > > > I assume you mean cpU/cpu-cycles/ > > > > > > > >Performance counter stats for 'kill': > > > > > > > >1,573,757 cp/cpu-cycles/ > > > > > > > > Keeping the pattern matching logic, but making the name unique > > > > in case there's no other match found. That fixes the example > > > > above and hopefully does not screw up anything else. > > > > > And the problem I have with this approach, is that you do not really > know what you are measuring. > You have not way of knowing that the count comes from multiple PMU instances: > > perf stat -a -e uncore_cb/clockticks/ kill > 0 uncore_cb/clockticks/ > > I think you need to report that this is aggregated from uncore_cbox_0 > and uncore_cbox_1. > Otherwise it is not clear what I am monitoring. And you hope that what > you match in the regex > is related. > In my example should say: > 0 uncore_cbox[0-1]/clockticks/ ok, makes sense.. also shouldnt be that hard to do.. will repost thanks, jirka
