* [PATCH] net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode
From: Vadim Lomovtsev @ 2018-06-13 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612.152540.1304714747425091865.davem@davemloft.net>
Sorry for delay.
On Tue, Jun 12, 2018 at 03:25:40PM -0700, David Miller wrote:
> From: Dean Nelson <dnelson@redhat.com>
> Date: Mon, 11 Jun 2018 06:22:14 -0500
>
> > On 06/10/2018 02:35 PM, David Miller wrote:
> >> From: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> >> Date: Fri, 8 Jun 2018 02:27:59 -0700
> >>
> >>> + /* Save message data locally to prevent them from
> >>> + * being overwritten by next ndo_set_rx_mode call().
> >>> + */
> >>> + spin_lock(&nic->rx_mode_wq_lock);
> >>> + mode = vf_work->mode;
> >>> + mc = vf_work->mc;
> >>> + vf_work->mc = NULL;
> >
> > If I'm reading this code correctly, I believe nic->rx_mode_work.mc
> > will
> > have been set to NULL before the lock is dropped by
> > nicvf_set_rx_mode_task() and acquired by nicvf_set_rx_mode().
> >
> >
> >>> + spin_unlock(&nic->rx_mode_wq_lock);
> >> At the moment you drop this lock, the memory behind 'mc' can be
> >> freed up by:
> >>
> >>> + spin_lock(&nic->rx_mode_wq_lock);
> >>> + kfree(nic->rx_mode_work.mc);
> >
> > So the kfree() will be called with a NULL pointer and quickly return.
> >
> >
> >> And you'll crash when you dereference it above via
> >> __nicvf_set_rx_mode_task().
> >>
> >
> > I believe the call to kfree() in nicvf_set_rx_mode() is there to free
> > up a mc_list that has been allocated by nicvf_set_rx_mode() during a
> > previous callback to the function, one that has not yet been processed
> > by nicvf_set_rx_mode_task().
> >
> > In this way only the last 'unprocessed' callback to
> > nicvf_set_rx_mode()
> > gets processed should there be multiple callbacks occurring between
> > the
> > times the nicvf_set_rx_mode_task() runs.
> >
> > In my testing with this patch, this is what I see happening.
>
> You're right, my bad.
>
> Patch applied.
Thank you for your time.
WBR,
Vadim
^ permalink raw reply
* [PATCH v3 3/3] arm64/mm: migrate swapper_pg_dir and tramp_pg_dir
From: James Morse @ 2018-06-13 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606043921.19851-4-yaojun8558363@gmail.com>
Hi Jun,
On 06/06/18 05:39, Jun Yao wrote:
> Migrate swapper_pg_dir and tramp_pg_dir. And their virtual addresses
> do not correlate with kernel's address.
This is all to make 'KSMA' harder, where an single arbitrary write is used to
add a block mapping to the page-tables, giving the attacker full access to
physical memory.
This series is pretty complicated, and would still be overcome by arbitrary-read
of __pa_swapper_pg_dir. Any attacker already has to defeat KASLR, but I guess
that can be done without having read-access.
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 94056e064c6f..ba0b55158971 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -637,10 +647,29 @@ static void __init map_kernel(pgd_t *pgdp)
> */
> void __init paging_init(void)
> {
> - phys_addr_t pgd_phys = early_pgtable_alloc();
> - pgd_t *pgdp = pgd_set_fixmap(pgd_phys);
> + phys_addr_t pgd_phys;
> + pgd_t *pgdp;
> + phys_addr_t mem_size;
>
> - __pa_swapper_pg_dir = __pa_symbol(swapper_pg_dir);
> + mem_size = __pa_symbol(swapper_pg_dir) + PAGE_SIZE
> + - (__pa_symbol(idmap_pg_dir) + IDMAP_DIR_SIZE);
> +
> + if (mem_size == PAGE_SIZE) {
> + pgd_phys = early_pgtable_alloc();
This is where we migrated swapper_pg_dir to, its the first memblock_alloc()
call, and is guaranteed to be at the top of memory. Moving this allocation later
will still cause a predictable page to be allocated as this setup code is the
only thing running. I don't think we are in a better position after this series.
Ideally we would put these pgd entries in the read-only section. We only modify
swapper_pg_dir for vmalloc()/vmap() once its generated, which we could do
through a fixmap entry.
Like this, an attacker can find where swapper_pg_dir is, but can't write to it.
(the tricky bit will be breaking swapper_pg_dir up, as we free parts of it)
Thanks,
James
^ permalink raw reply
* [PATCH 3/3] rtc: ftrtc010: let the core handle range
From: Alexandre Belloni @ 2018-06-13 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdabaH2yiYNnQHBru=-Snb3Eeni2eDAa9mjsa-3DqMC72g@mail.gmail.com>
On 13/06/2018 11:10:35+0200, Linus Walleij wrote:
> On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > The current range handling is highly suspicious. Anyway, let the core
> > handle it.
>
> Hmmm. I have datasheets, do you need some input about the hardware?
> Something I should patch?
>
Nothing to do as you seemed to confirm what I did was OK. I could find
why it was set to 2148 in the first place. Maybe it correspond to the
default days, hours minutes, second values on the SoC.
> > The RTC has a 32 bit counter on top of days + hh:mm:ss registers.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yours,
> Linus Walleij
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: kbuild test robot @ 2018-06-13 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613161314.14894-3-yixun.lan@amlogic.com>
Hi Liang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mtd/nand/next]
[also build test ERROR on v4.17 next-20180613]
[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/Yixun-Lan/mtd-rawnand-meson-add-Amlogic-NAND-driver-support/20180613-161917
base: git://git.infradead.org/linux-mtd.git nand/next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> drivers/mtd/nand/raw/meson_nand.c:21:10: fatal error: clk-regmap.h: No such file or directory
#include "clk-regmap.h"
^~~~~~~~~~~~~~
compilation terminated.
vim +21 drivers/mtd/nand/raw/meson_nand.c
> 21 #include "clk-regmap.h"
22
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 62787 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/043f3907/attachment-0001.gz>
^ permalink raw reply
* [PATCH v1 0/4] add mailbox support for i.MX7D
From: A.s. Dong @ 2018-06-13 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601083411.s35c2floqdas6qni@pengutronix.de>
Hi Robert,
Thanks for the forwarding.
> -----Original Message-----
> From: Robert Schwebel [mailto:r.schwebel at pengutronix.de]
> Sent: Friday, June 1, 2018 4:34 PM
> To: Oleksij Rempel <o.rempel@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>; Fabio Estevam
> <fabio.estevam@nxp.com>; Rob Herring <robh+dt@kernel.org>; Mark
> Rutland <mark.rutland@arm.com>; linux-clk at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; kernel at pengutronix.de;
> devicetree at vger.kernel.org; A.s. Dong <aisheng.dong@nxp.com>; dl-linux-
> imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v1 0/4] add mailbox support for i.MX7D
>
> On Fri, Jun 01, 2018 at 08:58:17AM +0200, Oleksij Rempel wrote:
> > This patches are providing support for mailbox (Messaging Unit) for
> > i.MX7D. Functionality was tested on PHYTEC phyBOARD-Zeta i.MX7D with
> > Linux running on all cores: ARM Cortex-A7 and ARM Cortex-M4.
> >
Thanks for the patch.
> > Both parts of i.MX messaging Unit are visible for all CPUs available
> > on i.MX7D. Communication worked independent of MU side in
> combination
> > with CPU. For example MU-A used on ARM Cortex-A7 and MU-B used on
> ARM
> > Cortex-M4 or other ways around.
> >
> > The question to NXP developers: are there are limitations or
> > recommendations about MU vs CPU combination? The i.MX7D
> documentation
> > talks about "Processor A" and "Processor B". It is not quite clear
> > what processor it actually is (A7 or M4).
The MU vs CPU combination usually are defined by HW design.
It, MU Side A/B, can either be used by both CPU (A core and M core)
or fixed to one side.
For MX7D case, both side memory map can be accessed by both CPU
Including Interrupt signals. But the recommendation is A core using
MU side A and M core using MU side B.
Regards
Dong Aisheng
>
> Adding Dong Aisheng and NXP linux team to Cc:.
>
> rsc
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> w.pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7Cf53
> d9c9cdd744878740f08d5c79a7a1e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0%7C636634388645464924&sdata=2ehh92tNbfwf3fJTp%2Fx7IUOgGSU
> h6pyrc2XsdRJkTw4%3D&reserved=0 |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Suzuki K Poulose @ 2018-06-13 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612204802.GA15817@rob-hp-laptop>
Hi Rob,
On 12/06/18 21:48, Rob Herring wrote:
> On Fri, Jun 01, 2018 at 02:16:05PM +0100, Suzuki K Poulose wrote:
>> The coresight drivers relied on default bindings for graph
>> in DT, while reusing the "reg" field of the "ports" to indicate
>> the actual hardware port number for the connections. However,
>> with the rules getting stricter w.r.t to the address mismatch
>> with the label, it is no longer possible to use the port address
>> field for the hardware port number. Hence, we add an explicit
>> property to denote the hardware port number, "coresight,hwid"
>> which must be specified for each "endpoint".
>>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Rob Herring <robh@kernel.org>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> .../devicetree/bindings/arm/coresight.txt | 26 +++++++++---
>> drivers/hwtracing/coresight/of_coresight.c | 46 ++++++++++++++++------
>> 2 files changed, 54 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
>> index bd36e40..385581a 100644
>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>> @@ -104,7 +104,11 @@ properties to uniquely identify the connection details.
>> "slave-mode"
>>
>> * Hardware Port number at the component:
>> - - The hardware port number is assumed to be the address of the "port" component.
>> + - (Obsolete) The hardware port number is assumed to be the address of the "port" component.
>> + - Each "endpoint" must define the hardware port of the local end of the
>> + connection using the following property:
>> + "coresight,hwid" - 32bit integer, hardware port number at the local end.
>
> "coresight" is not a vendor and properties are in the form
> [<vendor>,]<prop-name>.
OK. The issue here is that a coresight component could be an Arm IP or
a custom partner IP. So, the vendor could be either arm or the partner id.
However, this property is kind of a generic one for the Coresight family,
which is why we opted for "coresight". What is the guideline for such
cases ?
Or in other words I see the following possible options :
1) coresight,hwid - coresight generic
2) arm,coresight-hwid - arm vendor, however the device could be from any vendor.
3) hwid - Generic
4) none of the above, something completely different.
What do you recommend from the above ?
>> +
>>
>>
>> Example:
>> @@ -120,6 +124,7 @@ Example:
>> etb_in_port: endpoint at 0 {
>
> There shouldn't be a unit address here because there is no reg property.
>
>> slave-mode;
>> remote-endpoint = <&replicator_out_port0>;
>> + coresight,hwid = <0>;
>
> It doesn't make sense for these to be in the endpoint. If you had
> multiple endpoints, then you would have to duplicate it. "ports" are
> a single data stream. "endpoints" are connections to that stream. So if
> you have a muxed (input) or fanout/1-to-many (output) connection, then
> you have multiple endpoints.
We do have many-to-1 input (e.g, funnels) and 1-to-many outputs
(e.g replicators). However, we have (so far) used only one endpoint per
port.
Also we could potentially have multiple data streams flowing through
the ports, which gets filtered to different ports in 1-to-many components
(read programmable-replicator).
So the point is we have a shared path which carries different data
streams with mux/demux components. I am open for suggestions based on
the above facts.
>
> The same applied to the slave-mode property, but that ship has sailed.
> No reason to continue that though.
>
>> };
>> };
>> };
>> @@ -134,6 +139,7 @@ Example:
>> tpiu_in_port: endpoint at 0 {
>> slave-mode;
>> remote-endpoint = <&replicator_out_port1>;
>> + coresight,hwid = <0>;
>> };
>> };
>> };
>> @@ -154,6 +160,7 @@ Example:
>> reg = <0>;
>> replicator_out_port0: endpoint {
>> remote-endpoint = <&etb_in_port>;
>> + coresight,hwid = <0>;
>> };
>> };
>>
>> @@ -161,15 +168,17 @@ Example:
>> reg = <1>;
>> replicator_out_port1: endpoint {
>> remote-endpoint = <&tpiu_in_port>;
>> + coresight,hwid = <1>;
>> };
>> };
>>
>> /* replicator input port */
>> port at 2 {
>> - reg = <0>;
>> + reg = <1>;
>
> This will still get flagged as an error. reg must be 2 here.
Sorry, thats a mistake. I will fix it.
Cheers
Suzuki
^ permalink raw reply
* [PATCH v3 4/6] dmaengine: imx-sdma: remove usless lock
From: Sascha Hauer @ 2018-06-13 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528729173-28684-5-git-send-email-yibin.gong@nxp.com>
On Mon, Jun 11, 2018 at 10:59:31PM +0800, Robin Gong wrote:
> No need anymore for 'lock' now since virtual dma will provide
> the common lock instead.
This can be merged into the last patch, maybe rephrasing the commit
message from "revert..." to what is being done. To me "revert" sounds
like the commit was wrong, but it wasn't at that time.
Sascha
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> 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 e0af8ee..f150b38 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;
> struct imx_dma_data data;
> };
> @@ -1907,7 +1906,6 @@ static int sdma_probe(struct platform_device *pdev)
> struct sdma_channel *sdmac = &sdma->channel[i];
>
> sdmac->sdma = sdma;
> - spin_lock_init(&sdmac->lock);
>
> sdmac->channel = i;
> sdmac->vc.desc_free = sdma_desc_free;
> --
> 2.7.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2] arm: sun4i: Add support for Pengpod 1000 tablet
From: Bob Ham @ 2018-06-13 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4d041794-ba90-a9a6-0886-0ca18dab62b9@redhat.com>
On 13/06/18 08:28, Hans de Goede wrote:
> On 05-06-18 20:18, Bob Ham wrote:
>> It's a fine point but it makes me nervous.? I originally based my .dts
>> on sun4i-a10-inet1.dts.? I've CC'd the original copyright holder, Hans
>> de Goede.? Hans, are you willing to give permission for the license
>> notice to be replaced with just an SPDX header indicating the dual
>> licensing?
>
> Yes that is fine by me and you've my permission to switch to using
> just the SPDX header.
Excellent, thanks! :-)
--
Bob Ham <rah@settrans.net>
for (;;) { ++pancakes; }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2913 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/b4d4d5c8/attachment.sig>
^ permalink raw reply
* [PATCH v3 5/6] dmaengine: imx-sdma: remove the maximum limation for bd numbers
From: Sascha Hauer @ 2018-06-13 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528729173-28684-6-git-send-email-yibin.gong@nxp.com>
In the subject: s/limation/limitation/
Sascha
On Mon, Jun 11, 2018 at 10:59:32PM +0800, Robin Gong wrote:
> No this limitation now after virtual dma used since bd is allocated
> dynamically instead of static.
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> 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 f150b38..0b0588d2 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;
>
> @@ -1296,13 +1295,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 = &desc->bd[i];
> @@ -1412,12 +1404,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 > 0xffff) {
> dev_err(sdma->dev, "SDMA channel %d: maximum period size exceeded: %zu > %d\n",
> channel, period_len, 0xffff);
> --
> 2.7.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2] media: stm32-dcmi: add power saving support
From: Hugues Fruchet @ 2018-06-13 9:59 UTC (permalink / raw)
To: linux-arm-kernel
Implements runtime & system sleep power management ops.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
version 2:
- Fix missing include file detected by kbuild on i386 & sparc64 arch:
- https://www.mail-archive.com/linux-media at vger.kernel.org/msg132766.html
- https://www.mail-archive.com/linux-media at vger.kernel.org/msg132771.html
drivers/media/platform/stm32/stm32-dcmi.c | 81 +++++++++++++++++++++++++------
1 file changed, 65 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index 2e1933d..2ecf00e 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -22,7 +22,9 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_graph.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/reset.h>
#include <linux/videodev2.h>
@@ -578,9 +580,9 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
u32 val = 0;
int ret;
- ret = clk_enable(dcmi->mclk);
+ ret = pm_runtime_get_sync(dcmi->dev);
if (ret) {
- dev_err(dcmi->dev, "%s: Failed to start streaming, cannot enable clock\n",
+ dev_err(dcmi->dev, "%s: Failed to start streaming, cannot get sync\n",
__func__);
goto err_release_buffers;
}
@@ -590,7 +592,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
if (ret && ret != -ENOIOCTLCMD) {
dev_err(dcmi->dev, "%s: Failed to start streaming, subdev streamon error",
__func__);
- goto err_disable_clock;
+ goto err_pm_put;
}
spin_lock_irq(&dcmi->irqlock);
@@ -675,8 +677,8 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
err_subdev_streamoff:
v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 0);
-err_disable_clock:
- clk_disable(dcmi->mclk);
+err_pm_put:
+ pm_runtime_put(dcmi->dev);
err_release_buffers:
spin_lock_irq(&dcmi->irqlock);
@@ -749,7 +751,7 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
/* Stop all pending DMA operations */
dmaengine_terminate_all(dcmi->dma_chan);
- clk_disable(dcmi->mclk);
+ pm_runtime_put(dcmi->dev);
if (dcmi->errors_count)
dev_warn(dcmi->dev, "Some errors found while streaming: errors=%d (overrun=%d), buffers=%d\n",
@@ -1751,12 +1753,6 @@ static int dcmi_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
- ret = clk_prepare(mclk);
- if (ret) {
- dev_err(&pdev->dev, "Unable to prepare mclk %p\n", mclk);
- goto err_dma_release;
- }
-
spin_lock_init(&dcmi->irqlock);
mutex_init(&dcmi->lock);
init_completion(&dcmi->complete);
@@ -1772,7 +1768,7 @@ static int dcmi_probe(struct platform_device *pdev)
/* Initialize the top-level structure */
ret = v4l2_device_register(&pdev->dev, &dcmi->v4l2_dev);
if (ret)
- goto err_clk_unprepare;
+ goto err_dma_release;
dcmi->vdev = video_device_alloc();
if (!dcmi->vdev) {
@@ -1832,14 +1828,15 @@ static int dcmi_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Probe done\n");
platform_set_drvdata(pdev, dcmi);
+
+ pm_runtime_enable(&pdev->dev);
+
return 0;
err_device_release:
video_device_release(dcmi->vdev);
err_device_unregister:
v4l2_device_unregister(&dcmi->v4l2_dev);
-err_clk_unprepare:
- clk_unprepare(dcmi->mclk);
err_dma_release:
dma_release_channel(dcmi->dma_chan);
@@ -1850,20 +1847,72 @@ static int dcmi_remove(struct platform_device *pdev)
{
struct stm32_dcmi *dcmi = platform_get_drvdata(pdev);
+ pm_runtime_disable(&pdev->dev);
+
v4l2_async_notifier_unregister(&dcmi->notifier);
v4l2_device_unregister(&dcmi->v4l2_dev);
- clk_unprepare(dcmi->mclk);
+
dma_release_channel(dcmi->dma_chan);
return 0;
}
+static __maybe_unused int dcmi_runtime_suspend(struct device *dev)
+{
+ struct stm32_dcmi *dcmi = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(dcmi->mclk);
+
+ return 0;
+}
+
+static __maybe_unused int dcmi_runtime_resume(struct device *dev)
+{
+ struct stm32_dcmi *dcmi = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(dcmi->mclk);
+ if (ret)
+ dev_err(dev, "%s: Failed to prepare_enable clock\n", __func__);
+
+ return ret;
+}
+
+static __maybe_unused int dcmi_suspend(struct device *dev)
+{
+ /* disable clock */
+ pm_runtime_force_suspend(dev);
+
+ /* change pinctrl state */
+ pinctrl_pm_select_sleep_state(dev);
+
+ return 0;
+}
+
+static __maybe_unused int dcmi_resume(struct device *dev)
+{
+ /* restore pinctl default state */
+ pinctrl_pm_select_default_state(dev);
+
+ /* clock enable */
+ pm_runtime_force_resume(dev);
+
+ return 0;
+}
+
+static const struct dev_pm_ops dcmi_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(dcmi_suspend, dcmi_resume)
+ SET_RUNTIME_PM_OPS(dcmi_runtime_suspend,
+ dcmi_runtime_resume, NULL)
+};
+
static struct platform_driver stm32_dcmi_driver = {
.probe = dcmi_probe,
.remove = dcmi_remove,
.driver = {
.name = DRV_NAME,
.of_match_table = of_match_ptr(stm32_dcmi_of_match),
+ .pm = &dcmi_pm_ops,
},
};
--
1.9.1
^ permalink raw reply related
* [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
From: Russell King - ARM Linux @ 2018-06-13 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612215834.wrnfrb57ed3uxexa@kahuna>
On Tue, Jun 12, 2018 at 04:58:34PM -0500, Nishanth Menon wrote:
> On 21:40-20180612, Russell King - ARM Linux wrote:
> [...]
> > > I started respinning the series, while there is definitely a use of
> > > implementing in u-boot,
> > > I am starting to wonder if we should also be doing this in kernel.
> >
> > How does the kernel set the bit when the kernel is running in non-secure
> > mode, when the ACTLR is read-only in that mode?
>
> For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
> it:
> https://patchwork.kernel.org/patch/10461273/
>
> This'd be similar in implementation to ARM erratum 801819 workaround
> that needs two pieces (u-boot + kernel). I am not really worried about
> OMAP5/DRA7 since they should'nt loose context in Low power modes.
> Other SoCs need to be aware of the constraints.
>
> /me wishes PSCI was a standard during ARMv7, but it was'nt... So
> legacy v7 SoCs have implementations that are kind of different (even
> smc calling conventions vary).
It may seem to be an easy way out (do everything in the kernel) but
have you considered that the secure world is also vulnerable?
If the IBE bit is not set in the secure world, then the secure world
is not implementing the workarounds, and therefore the non-secure
world has the possibility to use the Spectre vulnerabilities to
exploit the secure world with enough effort and knowledge.
You really need to _also_ fix these vulnerabilities in the secure
world, which includes setting the IBE bit there.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Will Deacon @ 2018-06-13 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpOJ7Q7nbo9m_HGqr44+n_iEtreZt+Uxtf2PzcHSzTdKuA@mail.gmail.com>
On Wed, Jun 13, 2018 at 10:46:56AM +0530, Bhupesh Sharma wrote:
> On Tue, Jun 12, 2018 at 3:42 PM, James Morse <james.morse@arm.com> wrote:
> > On 12/06/18 09:25, Bhupesh Sharma wrote:
> >> On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel
> >> <ard.biesheuvel@linaro.org> wrote:
> >>> On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> >>>> The start of the linear region map on a KASLR enabled ARM64 machine -
> >>>> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
> >>>> support), is no longer correctly represented by the PAGE_OFFSET macro,
> >>>> since it is defined as:
> >>>>
> >>>> (UL(1) << (VA_BITS - 1)) + 1)
> >
> >>> PAGE_OFFSET is the VA of the start of the linear map. The linear map
> >>> can be sparsely populated with actual memory, regardless of whether
> >>> KASLR is in effect or not. The only difference in the presence of
> >>> KASLR is that there may be such a hole at the beginning, but that does
> >>> not mean the linear map has moved, or that the value of PAGE_OFFSET is
> >>> now wrong.
> >
> >>>> So taking an example of a platform with VA_BITS=48, this gives a static
> >>>> value of:
> >>>> PAGE_OFFSET = 0xffff800000000000
> >>>>
> >>>> However, for the KASLR case, we use the 'memstart_offset_seed'
> >>>> to randomize the linear region - since 'memstart_addr' indicates the
> >>>> start of physical RAM, we randomize the same on basis
> >>>> of 'memstart_offset_seed' value.
> >>>>
> >>>> As the PAGE_OFFSET value is used presently by several user space
> >>>> tools (for e.g. makedumpfile and crash tools) to determine the start
> >>>> of linear region and hence to read addresses (like PT_NOTE fields) from
> >>>> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
> >>>> use 'memblock_start_of_DRAM()' value (converted to virtual) as
> >>>> the start of linear region for the KASLR cases and default to
> >>>> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
> >>>> linear region.
> >
> >>> Userland code that assumes that the linear map cannot have a hole at
> >>> the beginning should be fixed.
> >
> >> That is a separate case (although that needs fixing as well via a
> >> kernel patch probably as the user-space tools rely on '/proc/iomem'
> >> contents to determine the first System RAM/reserved range).
> >
> > This is for kexec-tools generating the kdump vmcore ELF headers in user-space?
>
> Yes, but again, I would like to reiterate that the case where I see a
> hole at the start of the System RAM range (as I listed above) is just
> a specific case, which probably deserves a separate patch. The current
> patch though is for a generic issue (please see more details below).
>
> >> 1. In that particular case (see [1]) the EFI firmware sets the first
> >> EFI block as EfiReservedMemType:
> >>
> >> Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
> >> Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
> >>
> >> Since EFI firmware won't return the "EfiReservedMemType" memory to
> >> Linux kernel,
> >
> > (Its linux that makes this choice in
> > drivers/firmware/efi/arm-init.c::is_usable_memory())
> >
> >
> >> so the kernel can't get any info about the first mem
> >> block, and kernel can only see region2 as below:
> >>
> >> efi: Processing EFI memory map:
> >> efi: 0x000000200000-0x00000021ffff [Runtime Data |RUN| | |
> >> | | | | |WB|WT|WC|UC]
> >>
> >> # head -1 /proc/iomem
> >> 00200000-0021ffff : reserved
> >>
> >> 2a. If we add debug prints to 'arch/arm64/mm/init.c' to print the
> >> kernel Virtual map we can see that the memory node is set to:
> >>
> >> # dmesg | grep memory
> >> ..........
> >> memory : 0xffff800000200000 - 0xffff801800000000
> >>
> >> 2b. Now if we use kexec-tools to obtain a crash vmcore we can see that
> >> if we use 'readelf' to get the last program Header from vmcore (logs
> >> below are for the non-kaslr case):
> >>
> >> # readelf -l vmcore
> >>
> >> ELF Header:
> >> ........................
> >>
> >> Program Headers:
> >> Type Offset VirtAddr PhysAddr
> >> FileSiz MemSiz Flags Align
> >> ..............................................................................................................................................................
> >> LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
> >> 0x0000001680000000 0x0000001680000000 RWE 0
> >>
> >> 3. So if we do a simple calculation:
> >>
> >> (VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
> >> 0xFFFF8017FFE00000 != 0xffff801800000000.
> >>
> >> which indicates that the end virtual memory nodes are not the same
> >> between vmlinux and vmcore.
> >
> > If I've followed this properly: the problem is that to generate the ELF headers
> > in the post-kdump vmcore, at kdump-load-time kexec-tools has to guess the
> > virtual addresses of the 'System RAM' regions it can see in /proc/iomem.
> >
> > The problem you are hitting is an invisible hole at the beginning of RAM,
> > meaning user-space's guess_phys_to_virt() is off by the size of this hole.
> >
> > Isn't KASLR a special case for this? You must have to correct for that after
> > kdump has happened, based on an elf-note in the vmcore. Can't we always do this?
>
> No, I hit this issue both for the KASLR and non-KASLR boot cases. We
> can fix this either in kernel or user-space.
>
> Fixing this in kernel space seems better to me as the definition of
> 'memstart_addr' is that it indicates the start of the physical ram,
> but since in this case there is a hole at the start of the system ram
> visible in Linux (and thus to user-space), but 'memstart_addr' is
> still 0 which seems contradictory at the least. This causes PHY_OFFSET
> to be 0 as well, which is again contradictory.
Contradictory to who? Userspace has no business messing around with this
stuff and I'm reluctant to make this an ABI by adding a symbol with a
special name. Why can't the various constants needed by these tools be
exported in the ELF headers for kcore/vmcore, or as a NOTE as James
suggests? That sounds a lot less fragile to me.
Will
^ permalink raw reply
* [PATCH] ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for secondary cores
From: Russell King - ARM Linux @ 2018-06-13 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612213611.2484-1-nm@ti.com>
On Tue, Jun 12, 2018 at 04:36:11PM -0500, Nishanth Menon wrote:
> Call secure services to enable ACTLR[0] (Enable invalidates of BTB with
> ICIALLU) when branch hardening is enabled for kernel.
As mentioned elsewhere, I don't think this is a good idea - if the secure
world is not implementing the Spectre workarounds, then the _system_ is
exploitable.
If the secure world is implementing the spectre workarounds, it will
already have enabled the IBE bit (which is r/w from secure, read only
from non-secure.)
So, basically, lack of the IBE bit being set is basically telling the
kernel that it's running on a vulnerable platform _even if the kernel
were to set it through some means_.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>
> Based on: next-20180612 +
> Uboot series posted: https://marc.info/?l=u-boot&m=152883522011042&w=2
>
> With Just u-boot changes alone: OMAP5-uevm: https://pastebin.ubuntu.com/p/9yDM22bJ6n/
> with kernel changes added on: https://pastebin.ubuntu.com/p/gXPBGGYRPX/
>
> arch/arm/mach-omap2/omap-smp.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index 69df3620eca5..28fc80ea675b 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -109,6 +109,32 @@ void omap5_erratum_workaround_801819(void)
> static inline void omap5_erratum_workaround_801819(void) { }
> #endif
>
> +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> +static void omap5_harden_predictor(void)
> +{
> + u32 acr, acr_mask;
> +
> + asm volatile ("mrc p15, 0, %0, c1, c0, 1" : "=r" (acr));
> +
> + /*
> + * BIT(0) - Disables streaming. All write-allocate lines allocate in
> + */
> + acr_mask = BIT(0);
> +
> + /* do we already have it done.. if yes, skip expensive smc */
> + if ((acr & acr_mask) == acr_mask)
> + return;
> +
> + acr |= acr_mask;
> + omap_smc1(OMAP5_DRA7_MON_SET_ACR_INDEX, acr);
> +
> + pr_debug("%s: ARM ACR setup for CVE_2017_5715 applied on CPU%d\n",
> + __func__, smp_processor_id());
> +}
> +#else
> +static inline void omap5_harden_predictor(void) { }
> +#endif
> +
> static void omap4_secondary_init(unsigned int cpu)
> {
> /*
> @@ -131,6 +157,8 @@ static void omap4_secondary_init(unsigned int cpu)
> set_cntfreq();
> /* Configure ACR to disable streaming WA for 801819 */
> omap5_erratum_workaround_801819();
> + /* Enable ACR to allow for ICUALLU workaround */
> + omap5_harden_predictor();
> }
>
> /*
> --
> 2.15.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: James Morse @ 2018-06-13 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpOJ7Q7nbo9m_HGqr44+n_iEtreZt+Uxtf2PzcHSzTdKuA@mail.gmail.com>
Hi Bhupesh,
On 13/06/18 06:16, Bhupesh Sharma wrote:
> On Tue, Jun 12, 2018 at 3:42 PM, James Morse <james.morse@arm.com> wrote:
>> On 12/06/18 09:25, Bhupesh Sharma wrote:
>>> On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel wrote:
>>>> Userland code that assumes that the linear map cannot have a hole at
>>>> the beginning should be fixed.
>>> That is a separate case (although that needs fixing as well via a
>>> kernel patch probably as the user-space tools rely on '/proc/iomem'
>>> contents to determine the first System RAM/reserved range).
>>
>> This is for kexec-tools generating the kdump vmcore ELF headers in user-space?
>
> Yes, but again, I would like to reiterate that the case where I see a
> hole at the start of the System RAM range (as I listed above) is just
> a specific case, which probably deserves a separate patch. The current
> patch though is for a generic issue (please see more details below).
>>> # readelf -l vmcore
>>>
>>> ELF Header:
>>> ........................
>>>
>>> Program Headers:
>>> Type Offset VirtAddr PhysAddr
>>> FileSiz MemSiz Flags Align
>>> ..............................................................................................................................................................
>>> LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
>>> 0x0000001680000000 0x0000001680000000 RWE 0
>>>
>>> 3. So if we do a simple calculation:
>>>
>>> (VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
>>> 0xFFFF8017FFE00000 != 0xffff801800000000.
>>>
>>> which indicates that the end virtual memory nodes are not the same
>>> between vmlinux and vmcore.
>>
>> If I've followed this properly: the problem is that to generate the ELF headers
>> in the post-kdump vmcore, at kdump-load-time kexec-tools has to guess the
>> virtual addresses of the 'System RAM' regions it can see in /proc/iomem.
>>
>> The problem you are hitting is an invisible hole at the beginning of RAM,
>> meaning user-space's guess_phys_to_virt() is off by the size of this hole.
>>
>> Isn't KASLR a special case for this? You must have to correct for that after
>> kdump has happened, based on an elf-note in the vmcore. Can't we always do this?
>
> No, I hit this issue both for the KASLR and non-KASLR boot cases.
Because in both cases there is a hole at the beginning of the linear-map. KASLR
is a special-case of this as the kernel adds a variable sized hole to do the
randomization.
Surely treating this as one case makes your user-space code simpler.
> Fixing this in kernel space seems better to me as the definition of
Is there a kernel bug? Changing the definitions of internal kernel variables for
the benefit of code digging in /proc/kcore|/dev/mem isn't going to fly.
> 'memstart_addr' is that it indicates the start of the physical ram,
> but since in this case there is a hole at the start of the system ram
> visible in Linux (and thus to user-space), but 'memstart_addr' is
> still 0 which seems contradictory at the least. This causes PHY_OFFSET
> to be 0 as well, which is again contradictory.
>>> This happens because the kexec-tools rely on 'proc/iomem' contents
>>> while 'memstart_addr' is computed as 0 by kernel (as value of
>>> memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN).
>>
>>> Returning back to this patch, this is a generic requirement where we
>>> need the linear region start/base addresses in user-space applications
>>> which is used to read addresses which lie in the linear region (for
>>> e.g. when we read /proc/kcore contents).
[...]
>> This patch adds a variable that nothing uses, its going to be removed. You can't
>> depend on reading this via /dev/mem.
>>
>> Could you add the information you need as an elf-note to the vmcore instead? You
>> must already pick these up to handle kaslr. (from memory, this is where the
>> kaslr-offset is described to user-space after we kdump).
> No you are mixing up the two cases (please see above), the issue which
> this patch fixes is for use cases where we don't have the vmcore
> available in case of 'live' debugging via makedumpfile and crash tools
> (we only have '/proc/kcore' or 'vmlinux' available in such cases). I
> detailed the use case in [1] better (in a reply to Ard), I will detail
> the use-case again below:
Okay, so not kdump...
> One specific use case that I am working on at the moment is the
> makedumpfile '--mem-usage', which allows one to see the page numbers
> of current system (1st kernel) in different use (please see
> MAKEDUMPFILE(8) for more details).
https://linux.die.net/man/8/makedumpfile :
| Name: makedumpfile - make a small dumpfile of kdump
... but now we are talking about kdump again ...
> Using this we can know how many pages are dumpable when different
> dump_level is specified when invoking the makedumpfile.
>
> Normally, makedumpfile analyses the contents of '/proc/kcore' (while
> excluding the crashkernel range), and then calculates the page number
> of different kind per vmcoreinfo.
$ apt-get source makedumpfile
$ cd makedumpfile-1.5.3
$ grep -r "kcore" .
$
I suspect there are two pieces of software with the same name here.
> This use case requires directly reading the '/proc/kcore' and the
> hence the PAGE_OFFSET value is used to determine the base address of
> the linear region, whose value is not static in case of KASLR boot.
Eh? I thought PAGE_OFFSET was a compile-time constant, and it was PHYS_OFFSET
has a value other the aligned base of memory for KASLR.
> Another use-case is where the crash-utility uses the PAGE_OFFSET value
> to perform a virtual-to-physical conversion for the address lying in
> the linear region:
In all cases the problem you have is assuming the first 'System RAM' value in
/proc/iomem is the base of DRAM, which you can use a PHYS_OFFSET in your
user-space phys2virt() calculation.
What information do you need to make this work?
You can evidently read kernel variables, why can't you read memstart_addr and do:
| #define __phys_to_virt(x) \
| ((unsigned long)((x) - memstart_addr) | PAGE_OFFSET)
based on the physical addresses in /proc/iomem, and PAGE_OFFSET pulled out of
the vmlinux.
Reading memstart_addr is fragile, we might need to rename it
wednesday_memstart_addr. If user-space needs this value to work with
/proc/{kcore,vmcore} we should expose something like 'p2v_offset' as an elf-note
on those files. (looks like they both have elf-headers).
Thanks,
James
^ permalink raw reply
* [PATCH v2] regulator: core: Enable voltage balancing
From: Maciej Purski @ 2018-06-13 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605044554.GC5738@atomide.com>
Call regulator_balance_voltage() instead of set_voltage_rdev()
in set_voltage_unlocked() and in enabling and disabling functions,
but only if the regulator is coupled.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
Changes in v2:
- fix compile errors
- make debug messages more informative
---
drivers/regulator/core.c | 38 ++++++++++++++++++++++++++++----------
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2a7ffb7..266f4eb 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1605,7 +1605,6 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
struct device *dev = rdev->dev.parent;
int ret;
- pr_err("%s: %d\n", __func__, __LINE__);
/* No supply to resovle? */
if (!rdev->supply_name)
return 0;
@@ -2246,7 +2245,7 @@ static int _regulator_enable(struct regulator_dev *rdev)
{
int ret;
- pr_err("%s: %d\n", __func__, __LINE__);
+ rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
lockdep_assert_held_once(&rdev->mutex);
/* check voltage and requested load before enabling */
@@ -2295,7 +2294,12 @@ int regulator_enable(struct regulator *regulator)
struct regulator_dev *rdev = regulator->rdev;
int ret = 0;
- pr_err("%s: %d\n", __func__, __LINE__);
+ rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
+ if (rdev->coupling_desc.n_resolved != rdev->coupling_desc.n_coupled) {
+ rdev_err(rdev, "not all coupled regulators registered\n");
+ return -EPERM;
+ }
+
if (regulator->always_on)
return 0;
@@ -2307,12 +2311,15 @@ int regulator_enable(struct regulator *regulator)
regulator_lock_dependent(rdev);
ret = _regulator_enable(rdev);
+ /* balance only if there are regulators coupled */
+ if (rdev->coupling_desc.n_coupled > 1)
+ regulator_balance_voltage(rdev, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
if (ret != 0 && rdev->supply)
regulator_disable(rdev->supply);
- pr_err("%s: %d\n", __func__, __LINE__);
+ rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
return ret;
}
EXPORT_SYMBOL_GPL(regulator_enable);
@@ -2411,18 +2418,20 @@ int regulator_disable(struct regulator *regulator)
struct regulator_dev *rdev = regulator->rdev;
int ret = 0;
- pr_err("%s: %d\n", __func__, __LINE__);
+ rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
if (regulator->always_on)
return 0;
regulator_lock_dependent(rdev);
ret = _regulator_disable(rdev);
+ if (rdev->coupling_desc.n_coupled > 1)
+ regulator_balance_voltage(rdev, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
if (ret == 0 && rdev->supply)
regulator_disable(rdev->supply);
- pr_err("%s: %d\n", __func__, __LINE__);
+ rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
return ret;
}
EXPORT_SYMBOL_GPL(regulator_disable);
@@ -2470,6 +2479,8 @@ int regulator_force_disable(struct regulator *regulator)
regulator_lock_dependent(rdev);
regulator->uA_load = 0;
ret = _regulator_force_disable(regulator->rdev);
+ if (rdev->coupling_desc.n_coupled > 1)
+ regulator_balance_voltage(rdev, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
if (rdev->supply)
@@ -2898,7 +2909,7 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
const struct regulator_ops *ops = rdev->desc->ops;
int old_uV = _regulator_get_voltage(rdev);
- pr_err("%s: %d\n", __func__, __LINE__);
+ rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
trace_regulator_set_voltage(rdev_get_name(rdev), min_uV, max_uV);
min_uV += rdev->constraints->uV_offset;
@@ -3031,7 +3042,13 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
int old_min_uV, old_max_uV;
int current_uV;
- pr_err("%s: %d\n", __func__, __LINE__);
+ rdev_err(rdev, "%s: %d\n", __func__, __LINE__);
+ if (rdev->coupling_desc.n_resolved != rdev->coupling_desc.n_coupled) {
+ rdev_err(rdev, "not all coupled regulators registered\n");
+ ret = -EPERM;
+ goto out;
+ }
+
/* If we're setting the same range as last time the change
* should be a noop (some cpufreq implementations use the same
* voltage for multiple frequencies, for example).
@@ -3074,7 +3091,8 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
if (ret < 0)
goto out2;
- ret = regulator_set_voltage_rdev(rdev, min_uV, max_uV, state);
+ /* for not coupled regulators this will just set the voltage */
+ ret = regulator_balance_voltage(rdev, state);
if (ret < 0)
goto out2;
@@ -3360,7 +3378,7 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV)
{
int ret = 0;
- pr_err("%s: %d\n", __func__, __LINE__);
+ rdev_err(regulator->rdev, "%s: %d\n", __func__, __LINE__);
regulator_lock_dependent(regulator->rdev);
ret = regulator_set_voltage_unlocked(regulator, min_uV, max_uV,
--
2.7.4
^ permalink raw reply related
* [RFC V2 3/3] perf: qcom: Add Falkor CPU PMU IMPLEMENTATION DEFINED event support
From: Will Deacon @ 2018-06-13 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9957219b64252d3b2e19724db04a1179@codeaurora.org>
On Tue, Jun 12, 2018 at 04:41:32PM -0400, Agustin Vega-Frias wrote:
> Hi Mark,
>
> On 2018-06-12 10:40, Mark Rutland wrote:
> >Hi,
> >
> >On Thu, Jun 07, 2018 at 09:56:48AM -0400, Agustin Vega-Frias wrote:
> >>Selection of these events can be envisioned as indexing them from
> >>a 3D matrix:
> >>- the first index selects a Region Event Selection Register
> >>(PMRESRx_EL0)
> >>- the second index selects a group from which only one event at a time
> >> can be selected
> >>- the third index selects the event
> >>
> >>The event is encoded into perf_event_attr.config as 0xPRCCG, where:
> >> P [config:16 ] = prefix (flag that indicates a matrix-based
> >>event)
> >> R [config:12-15] = register (specifies the PMRESRx_EL0 instance)
> >> G [config:0-3 ] = group (specifies the event group)
> >> CC [config:4-11 ] = code (specifies the event)
> >>
> >>Events with the P flag set to zero are treated as common PMUv3 events
> >>and are directly programmed into PMXEVTYPERx_EL0.
> >>
> >>The first two indexes are set combining the RESR and group number with
> >>a base number and writing it into the architected PMXEVTYPER_EL0
> >>register.
> >>The third index is set by writing the code into the bits corresponding
> >>with the group into the appropriate IMPLEMENTATION DEFINED PMRESRx_EL0
> >>register.
> >
> >When are the IMP DEF registers accessible at EL0? Are those goverend by
> >the same controls as the architected registers?
>
> No, there is a separate IMP DEF register to control access.
Great :( We need to make sure we disable EL0 access during boot then, but
that means we need to prove for the existence of this thing in head.S
(since the PMU driver might not get loaded).
Also, what's the kvm story here so that we don't accidentally open up a
VM-VM side-channel via these registers? How do the EL1 trapping controls
work?
Will
^ permalink raw reply
* [PATCH v1 1/4] clk: imx7d: add IMX7D_MU_ROOT_CLK
From: Dong Aisheng @ 2018-06-13 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601065821.28234-2-o.rempel@pengutronix.de>
On Fri, Jun 1, 2018 at 2:58 PM, Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> This clock is needed for iMX mailbox driver
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> drivers/clk/imx/clk-imx7d.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
> index 975a20d3cc94..1c2541dc40e7 100644
> --- a/drivers/clk/imx/clk-imx7d.c
> +++ b/drivers/clk/imx/clk-imx7d.c
> @@ -793,6 +793,7 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
> clks[IMX7D_DRAM_PHYM_ROOT_CLK] = imx_clk_gate4("dram_phym_root_clk", "dram_phym_cg", base + 0x4130, 0);
> clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] = imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div", base + 0x4130, 0);
> clks[IMX7D_DRAM_ALT_ROOT_CLK] = imx_clk_gate4("dram_alt_root_clk", "dram_alt_post_div", base + 0x4130, 0);
> + clks[IMX7D_MU_ROOT_CLK] = imx_clk_gate2("mu_root_clk", "ipg_root_clk", base + 0x4270, 0);
The clock slice on MX7D needs to operate while its parent clock is on.
So this seems ought to be imx_clk_gate4?
Besides that, a nitpick:
although the address is already out of order, but we are still better to keep
in increasing order as long as we can.
Regards
Dong Aisheng
> clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk", "ipg_root_clk", base + 0x4230, 0);
> clks[IMX7D_SNVS_CLK] = imx_clk_gate4("snvs_clk", "ipg_root_clk", base + 0x4250, 0);
> clks[IMX7D_CAAM_CLK] = imx_clk_gate4("caam_clk", "ipg_root_clk", base + 0x4240, 0);
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/4] ARM: dts: Modernize the Vexpress PL111 integration
From: Sudeep Holla @ 2018-06-13 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528122658.3241-3-linus.walleij@linaro.org>
Hi Linus,
I was planning to apply this and observed few things.
On 28/05/18 13:26, Linus Walleij wrote:
> The Versatile Express was submitted with the actual display
> bridges unconnected (but defined in the device tree) and
> mock "panels" encoded in the device tree node of the PL111
> controller.
>
> This doesn't even remotely describe the actual Versatile
> Express hardware. Exploit the SiI9022 bridge by connecting
> the PL111 pads to it, making it use EDID or fallback values
> to drive the monitor.
>
> The also has to use the reserved memory through the
> CMA pool rather than by open coding a memory region and
> remapping it explicitly in the driver. To achieve this,
> a reserved-memory node must exist in the root of the
> device tree, so we need to pull that out of the
> motherboard .dtsi include files, and push it into each
> top-level device tree instead.
>
> We do the same manouver for all the Versatile Express
> boards, taking into account the different location of the
> video RAM depending on which chip select is used on
> each platform.
>
> This plays nicely with the new PL111 DRM driver and
> follows the standard ways of assigning bridges and
> memory pools for graphics.
>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Mali DP Maintainers <malidp@foss.arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Fix up the memory address for the -rs1 tiles to 0x18000000
> - Drop a bunch of extraneous reg props from the DVI adapter
> ---
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 44 ++++++------------
> arch/arm/boot/dts/vexpress-v2m.dtsi | 45 ++++++-------------
> arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 14 ++++++
> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 14 ++++++
> arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 14 ++++++
> arch/arm/boot/dts/vexpress-v2p-ca9.dts | 41 +++++++----------
> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 14 ++++++
> .../boot/dts/arm/rtsm_ve-motherboard.dtsi | 37 +++------------
> 8 files changed, 105 insertions(+), 118 deletions(-)
>
> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> index 7b8ff5b3b912..69f6a9436325 100644
> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> @@ -43,11 +43,6 @@
> bank-width = <4>;
> };
>
> - v2m_video_ram: vram at 2,00000000 {
> - compatible = "arm,vexpress-vram";
> - reg = <2 0x00000000 0x00800000>;
> - };
> -
> ethernet at 2,02000000 {
> compatible = "smsc,lan9118", "smsc,lan9115";
> reg = <2 0x02000000 0x10000>;
> @@ -224,6 +219,14 @@
> dvi-transmitter at 39 {
> compatible = "sil,sii9022-tpi", "sil,sii9022";
> reg = <0x39>;
> +
> + ports {
> + port at 0 {
May need reg=<0> here, otherwise DTC might complain ?
[...]
> diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
> index 9cd5e146abd5..067d84bc61c0 100644
> --- a/arch/arm/boot/dts/vexpress-v2m.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
> @@ -43,11 +43,6 @@
> bank-width = <4>;
> };
>
> - v2m_video_ram: vram at 3,00000000 {
> - compatible = "arm,vexpress-vram";
> - reg = <3 0x00000000 0x00800000>;
> - };
> -
> ethernet at 3,02000000 {
> compatible = "smsc,lan9118", "smsc,lan9115";
> reg = <3 0x02000000 0x10000>;
> @@ -224,6 +219,14 @@
> dvi-transmitter at 39 {
> compatible = "sil,sii9022-tpi", "sil,sii9022";
> reg = <0x39>;
> +
> + ports {
> + port at 0 {
Ditto
> + dvi_bridge_in: endpoint {
> + remote-endpoint = <&clcd_pads>;
> + };
> + };
> + };
> };
>
> dvi-transmitter at 60 {
[...]
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> index 3971427a105b..0dc4277d5f8b 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> @@ -53,6 +53,20 @@
> reg = <0 0x80000000 0 0x40000000>;
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* Chipselect 2 is physically at 0x18000000 */
> + vram: vram at 18000000 {
> + /* 8 MB of designated video RAM */
> + compatible = "shared-dma-pool";
> + reg = <0 0x18000000 0 0x00800000>;
> + no-map;
> + };
> + };
> +
I need to think hard yet, but was hoping to keep these in the
motherboard files itself if possible. I don't like the way we need
to specify the absolute address here.
> hdlcd at 2b000000 {
> compatible = "arm,hdlcd";
> reg = <0 0x2b000000 0 0x1000>;
[...]
> diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> index 1134e5d8df18..737d0a0c0854 100644
> --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> @@ -23,11 +23,6 @@
> bank-width = <4>;
> };
>
> - v2m_video_ram: vram at 2,00000000 {
> - compatible = "arm,vexpress-vram";
> - reg = <2 0x00000000 0x00800000>;
> - };
> -
> ethernet at 2,02000000 {
> compatible = "smsc,lan91c111";
> reg = <2 0x02000000 0x10000>;
> @@ -186,38 +181,16 @@
> interrupts = <14>;
> clocks = <&v2m_oscclk1>, <&v2m_clk24mhz>;
> clock-names = "clcdclk", "apb_pclk";
> - arm,pl11x,framebuffer = <0x18000000 0x00180000>;
> - memory-region = <&v2m_video_ram>;
> - max-memory-bandwidth = <130000000>; /* 16bpp @ 63.5MHz */
> + /* 800x600 16bpp @36MHz works fine */
> + max-memory-bandwidth = <54000000>;
> + memory-region = <&vram>;
>
> port {
> - v2m_clcd_pads: endpoint {
> - remote-endpoint = <&v2m_clcd_panel>;
> + clcd_pads: endpoint {
> + remote-endpoint = <&dvi_bridge_in>;
I can't find dvi_bridge_in for this RTSM/FVP model, also not sure if I2C
or DVI transmitter is supported on them.
Liviu, any idea ?
Also you my need to fix arm64 express-v2f-1xv7-ca53x2.dts as it includes
vexpress-v2m-rs1.dtsi
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH/RFT 2/2] arm64: dts: renesas: r8a77965: Add PCIe device nodes
From: Simon Horman @ 2018-06-13 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611082819.rnoiou2t7l6dynju@verge.net.au>
On Mon, Jun 11, 2018 at 10:28:22AM +0200, Simon Horman wrote:
> On Thu, Jun 07, 2018 at 09:11:34PM +0900, Yoshihiro Kaneko wrote:
> > From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> >
> > This patch adds PCIe{0,1} device nodes to R8A77965 SoC.
> >
> > Based on a similar patches of the R8A7796 device tree
> > by Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>.
> >
> > Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> > Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>
> Hi,
>
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Thanks Kaneko-san, applied.
^ permalink raw reply
* [PATCH v1 2/4] dt-bindings: mailbox: provide imx-mailbox documentation
From: Dong Aisheng @ 2018-06-13 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601065821.28234-3-o.rempel@pengutronix.de>
Hi Oleksij,
Some more comments besides Rob's:
On Fri, Jun 1, 2018 at 2:58 PM, Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> .../bindings/mailbox/imx-mailbox.txt | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt b/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
> new file mode 100644
> index 000000000000..a45604b33039
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
> @@ -0,0 +1,35 @@
> +i.MX Messaging Unit
> +===================
> +
> +The i.MX Messaging Unit (MU) contains two register sets: "A" and "B". In most cases
> +they are accessible from all Processor Units. On one hand, at least for mailbox functionality,
> +it makes no difference which application or processor is using which set of the MU. On
> +other hand, the register sets for each of the MU parts are not identical.
> +
> +Required properties:
> +- compatible : Shell be one of:
> + "fsl,imx7s-mu-a" and "fsl,imx7s-mu-b" for i.MX7S or i.MX7D
What's current requirement to distinguish Side A and B?
I see current code, side A only does extra clear of xCR register but none for B.
Is this a generic approach or something customized?
BTW can we name it more generically?e.g. fsl,imx7s-mu.
And using a property to indicate whether it's side A or B if really required.
Furthermore, AFAIK MX7 MU is derived from MX6SX.
Should we add and use fsl,imx6sx-mu instead?
e.g.
- compatible : Shell be one of:
"fsl,imx6sx-mu" and "fsl,imx7s-mu".
Regards
Dong Aisheng
> +- reg : physical base address of the mailbox and length of
> + memory mapped region.
> +- #mbox-cells: Common mailbox binding property to identify the number
> + of cells required for the mailbox specifier. Should be 1.
> +- interrupts : interrupt number. The interrupt specifier format
> + depends on the interrupt controller parent.
> +- clocks : phandle to the input clock.
> +
> +Example:
> + mu0a: mu at 30aa0000 {
> + compatible = "fsl,imx7s-mu-a";
> + reg = <0x30aa0000 0x28>;
> + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> + #mbox-cells = <1>;
> + };
> +
> + mu0b: mu at 30ab0000 {
> + compatible = "fsl,imx7s-mu-b";
> + reg = <0x30ab0000 0x28>;
> + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> + #mbox-cells = <1>;
> + };
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V5] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Simon Horman @ 2018-06-13 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611121513.9673-1-marek.vasut+renesas@gmail.com>
On Mon, Jun 11, 2018 at 02:15:13PM +0200, Marek Vasut wrote:
> Rather than hard-coding the quirk topology, which stopped scaling,
> parse the information from DT. The code looks for all compatible
> PMICs -- da9063 and da9210 -- and checks if their IRQ line is tied
> to the same pin. If so, the code sends a matching sequence to the
> PMIC to deassert the IRQ.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc at vger.kernel.org
> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> (on Koelsch)
Hi,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH v4 26/26] irqchip/gic-v3: Allow interrupts to be set as pseudo-NMI
From: Julien Thierry @ 2018-06-13 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527241772-48007-27-git-send-email-julien.thierry@arm.com>
On 25/05/18 10:49, Julien Thierry wrote:
> Provide a way to set a GICv3 interrupt as pseudo-NMI. The interrupt
> must not be enabled when setting/clearing the NMI status of the interrupt.
>
> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> drivers/irqchip/irq-gic-v3.c | 54 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/interrupt.h | 1 +
> 2 files changed, 55 insertions(+)
>
[...]
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 5426627..02c794f 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -419,6 +419,7 @@ enum irqchip_irq_state {
> IRQCHIP_STATE_ACTIVE, /* Is interrupt in progress? */
> IRQCHIP_STATE_MASKED, /* Is interrupt masked? */
> IRQCHIP_STATE_LINE_LEVEL, /* Is IRQ line high? */
> + IRQCHIP_STATE_NMI, /* Is IRQ an NMI? */
> };
After discussing with Thomas, NMI setting should not be exposed/managed
through the generic irq interface.
--
Julien Thierry
^ permalink raw reply
* [PATCH v4 24/26] irqchip/gic-v3: Add base support for pseudo-NMI
From: Julien Thierry @ 2018-06-13 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527241772-48007-25-git-send-email-julien.thierry@arm.com>
On 25/05/18 10:49, Julien Thierry wrote:
> Provide a higher priority to be used for pseudo-NMIs. When such an
> interrupt is received, enter the NMI state and prevent other NMIs to
> be raised.
>
> When returning from a pseudo-NMI, skip preemption and tracing if the
> interrupted context has interrupts disabled.
>
> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/include/asm/arch_gicv3.h | 6 ++++++
> arch/arm64/include/asm/arch_gicv3.h | 6 ++++++
> arch/arm64/kernel/entry.S | 43 +++++++++++++++++++++++++++++++++++++
> drivers/irqchip/irq-gic-v3.c | 41 +++++++++++++++++++++++++++++++++++
> 4 files changed, 96 insertions(+)
>
[...]
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index b144f73..4be5996 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -371,6 +379,20 @@ static u64 gic_mpidr_to_affinity(unsigned long mpidr)
> return aff;
> }
>
> +static void do_handle_nmi(unsigned int hwirq, struct pt_regs *regs)
> +{
> + struct pt_regs *old_regs = set_irq_regs(regs);
> + unsigned int irq;
> +
> + nmi_enter();
RAS/SEA also enters NMI state and things will break if asynchronous
error occurs during a pseudo-NMI.
I'll have this fixed in the next version.
--
Julien Thierry
^ permalink raw reply
* [PATCH V5] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Geert Uytterhoeven @ 2018-06-13 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613110647.ygg66nu36pcf6kpn@verge.net.au>
Hi Simon,
On Wed, Jun 13, 2018 at 1:06 PM Simon Horman <horms@verge.net.au> wrote:
> On Mon, Jun 11, 2018 at 02:15:13PM +0200, Marek Vasut wrote:
> > Rather than hard-coding the quirk topology, which stopped scaling,
> > parse the information from DT. The code looks for all compatible
> > PMICs -- da9063 and da9210 -- and checks if their IRQ line is tied
> > to the same pin. If so, the code sends a matching sequence to the
> > PMIC to deassert the IRQ.
> >
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> > Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> > Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > Cc: Simon Horman <horms+renesas@verge.net.au>
> > Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Cc: linux-renesas-soc at vger.kernel.org
> > Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> (on Koelsch)
>
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Note that applying it now will break gose, as its DTS doesn't describe all
regulators yet.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH V3] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Geert Uytterhoeven @ 2018-06-13 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3eda9da7-e26e-3e77-1040-9febe3b18abb@gmail.com>
Hi Marek,
On Mon, Jun 11, 2018 at 5:26 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 06/11/2018 04:30 PM, Geert Uytterhoeven wrote:
> > On Mon, Jun 11, 2018 at 4:19 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >> On 06/11/2018 04:10 PM, Geert Uytterhoeven wrote:
> >>> On Mon, Jun 11, 2018 at 4:04 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>> On 06/11/2018 03:49 PM, Geert Uytterhoeven wrote:
> >>>>> On Mon, Jun 11, 2018 at 3:39 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>> On 06/11/2018 03:03 PM, Geert Uytterhoeven wrote:
> >>>>>>> On Mon, Jun 11, 2018 at 2:15 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>>>> On 06/11/2018 11:56 AM, Geert Uytterhoeven wrote:
> >>>>>>>>> On Mon, Jun 4, 2018 at 7:59 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>>>>>> Rather than hard-coding the quirk topology, which stopped scaling,
> >>>>>>>>>> parse the information from DT. The code looks for all compatible
> >>>>>>>>>> PMICs -- da9036 and da9210 -- and checks if their IRQ line is tied
> >>>>>>>>>> to the same pin. If so, the code sends a matching sequence to the
> >>>>>>>>>> PMIC to deassert the IRQ.
> >>>>>
> >>>>>>>>>> + ret = of_property_read_u32(np, "reg", &addr);
> >>>>>>>>>> + if (ret)
> >>>>>>>>>> + return ret;
> >>>>>>>>>
> >>>>>>>>> I think it's safer to skip this entry and continue, after calling
> >>>>>>>>> kfree(quirk), of course.
> >>>>>>>>>
> >>>>>>>>>> +
> >>>>>>>>>> + quirk->id = id;
> >>>>>>>>>> + quirk->i2c_msg.addr = addr;
> >>>>>>>>>> + quirk->shared = false;
> >>>>>>>>>> +
> >>>>>>>>>> + ret = of_irq_parse_one(np, 0, &quirk->irq_args);
> >>>>>>>>>> + if (ret)
> >>>>>>>>>> + return ret;
> >>>>>>>>>
> >>>>>>>>> kfree(quirk) and continue...
> >>>>>>>>
> >>>>>>>> I wonder if it shouldn't rather free the entire list and abort ?
> >>>>>>>
> >>>>>>> "Be strict when sending, be liberal when receiving."
> >>>>>>
> >>>>>> Meaning ? I think "the language barrier is protecting me" (TM)
> >>>>>
> >>>>> Do the best you can, given the buggy DT you received.
> >>>>> I.e. don't fail completely, just ignore the bad device node, and continue.
> >>>>
> >>>> But if you ignore node, you might as well ignore one which is shared and
> >>>> then the system crashes due to IRQ storm anyway. So hum, what can we do ?
> >>>
> >>> Correct. If it's a critical node, it will crash regardless.
> >>> If it's a non-critical node, you have the choice between aborting and crashing,
> >>> or ignoring and keeping the system alive. Your call.
> >>
> >> But wait, since we control which machines this code runs on , can't we
> >> assure they have valid DTs ? This situation with invalid DT starts to
> >> look a bit hypothetical to me.
> >
> > That assumes you keep the list of machines to check, and don't want to fix the
> > issue automatically when detected (on any R-Car Gen2 or RZ/G1 platform, so
> > you still need to check for r8a779[0-4] and r8a774[23457]).
>
> Yes, I want to keep a list of machines to check, to be _sure_ some
> machine doesn't randomly blow up.
Just checking for the presence of a "renesas,irqc" node should be sufficient.
Using that node would also get rid of the hardcoded IRQC_BASE address.
Note that the code assumes IRQ2. If another IRQ is used, that won't harm
much though (as in: if it didn't blow up before, it won't blow up now).
> > Anyway, as we care about booting old DTBs on new kernels (for a while), we
> > have a few more release cycles to bikeshed ;-)
>
> I was about to ask if this patch then makes any sense or not.
Sure. Less hard-coding is always better.
Especially if it means we can make it work on more machines automatically :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox