* Re: [PATCH] pinctrl: pxa: pxa2xx: Remove 'pxa2xx_pinctrl_exit()' which is unused and broken
From: Dan Carpenter @ 2020-06-01 18:31 UTC (permalink / raw)
To: Christophe JAILLET
Cc: linus.walleij, kernel-janitors, linux-kernel, haojian.zhuang,
linux-gpio, daniel, Robert Jarzmik, linux-arm-kernel
In-Reply-To: <a2e34c9a-676f-d83f-f395-7428af038c16@wanadoo.fr>
On Mon, Jun 01, 2020 at 01:31:23PM +0200, Christophe JAILLET wrote:
> Le 01/06/2020 à 10:58, Robert Jarzmik a écrit :
> > Christophe JAILLET <christophe.jaillet@wanadoo.fr> writes:
> >
> > > Commit 6d33ee7a0534 ("pinctrl: pxa: Use devm_pinctrl_register() for pinctrl registration")
> > > has turned a 'pinctrl_register()' into 'devm_pinctrl_register()' in
> > > 'pxa2xx_pinctrl_init()'.
> > > However, the corresponding 'pinctrl_unregister()' call in
> > > 'pxa2xx_pinctrl_exit()' has not been removed.
> > >
> > > This is not an issue, because 'pxa2xx_pinctrl_exit()' is unused.
> > > Remove it now to avoid some wondering in the future and save a few LoC.
> > >
> > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
> >
> > Would be even a better patch with a :
> > Fixes: 6d33ee7a0534 ("pinctrl: pxa: Use devm_pinctrl_register() for pinctrl registration")
>
> I was wondering it was was needed in this case.
> The patch does not really fix anything, as the function is unused. Or it
> fixes things on a theoretical point of view.
There is no concensus... We should call a vote on this at Kernel
Summit. :P
regards,
dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/5] arm: decompressor: define a new zImage tag
From: Russell King - ARM Linux admin @ 2020-06-01 18:25 UTC (permalink / raw)
To: Lukasz Stelmach
Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <dleftjwo4qsqqf.fsf%l.stelmach@samsung.com>
On Mon, Jun 01, 2020 at 06:19:52PM +0200, Lukasz Stelmach wrote:
> It was <2020-06-01 pon 15:55>, when Russell King - ARM Linux admin wrote:
> > On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote:
> >> Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool)
> >> requirements of the decompressor code.
> >
> > Why do we need to know the stack and BSS size, when the userspace
> > kexec tool doesn't need to know this to perform the same function.
>
>
> kexec-tools load zImage as low in DRAM as possible and rely on two
> assumptions:
>
> + the zImage will copy itself to make enough room for the kernel,
> + sizeof(zImage+mem) < sizeof(kernel+mem), which is true because
> of compression.
>
> DRAM start
> + 0x8000
>
> zImage |-----------|-----|-------|
> text+data bss stack
>
> text+data bss
> kernel |---------------------|-------------------|
>
>
> initrd |-initrd-|-dtb-|
This is actually incorrect, because the decompressor will self-
relocate itself to avoid the area that it is going to decompress
into. So, while the decompressor runs, in the above situation it
ends up as:
ram |------------------------------------------------------...
text+data bss
kernel |---------------------|-------------------|
zImage |-----------|-----|-------|
text+data bss stack+malloc
Where "text+data" is actually smaller than the image size that
was loaded - the part of the image that performs the relocation
is discarded (the first chunk of code up to "restart" - 200
bytes.) The BSS is typically smaller than 200 bytes, so we've
been able to get away without knowing the actual BSS size so
far.
ram |--|-----------------------------------------|---------...
|<>| TEXT_OFFSET
kernel |---------------------|-------------------|
|<----edata_size----->|<-----bss_size---->|
|<---------------kernel_size------------->|
zImage |-----------|-----|-------|
|<-------len------->| (initial)
|<----------len------------>| (final)
The "final" len value is what the decompressor prints as the "zImage
requires" debugging value.
Hence, the size that the decompressed kernel requires is kernel_size.
The size that the decompressor requires is edata_size + len(final).
Now, if you intend to load the kernel to ram + TEXT_OFFSET + edata_size
then it isn't going to lose the first 200 bytes of code, so as you
correctly point out, we need to know the BSS size.
> >> +struct arm_zimage_tag_dc {
> >> + struct tag_header hdr;
> >> + union {
> >> +#define ZIMAGE_TAG_DECOMP_SIZE ARM_ZIMAGE_MAGIC4
> >> + struct zimage_decomp_size {
> >> + __le32 bss_size;
> >> + __le32 stack_size;
> >> + __le32 malloc_size;
> >> + } decomp_size;
You certainly don't need to know all this. All you need to know is
how much space the decompressor requires after the end of the image,
encompassing the BSS size, stack size and malloc size, which is one
value.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Tomasz Figa @ 2020-06-01 18:18 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Mark Rutland, Rob Herring, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男), Louis Kuo,
Bartosz Golaszewski, Sj Huang, Nicolas Boichat,
moderated list:ARM/Mediatek SoC support, Sakari Ailus,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <1590978816.8804.523.camel@mhfsdcap03>
On Mon, Jun 1, 2020 at 4:35 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> Hi Tomasz,
>
> On Fri, 2020-05-29 at 15:43 +0200, Tomasz Figa wrote:
> > On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > >
> > > Hi Sakari,
> > >
> > > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> > > > Hi Dongchun,
> > > >
> > > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > > > > Hi Sakari, Rob,
> > > > >
> > > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > > > > Hi Rob, Dongchun,
> > > > > >
> > > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > > > > + properties:
> > > > > > > > > > + endpoint:
> > > > > > > > > > + type: object
> > > > > > > > > > + additionalProperties: false
> > > > > > > > > > +
> > > > > > > > > > + properties:
> > > > > > > >
> > > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > > > > >
> > > > > > > Yes, if you are using it.
> > > > > >
> > > > > > Dongchun, can you confirm the chip has a single data and a single clock
> > > > > > lane and that it does not support lane reordering?
> > > > > >
> > > > >
> > > > > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > > > > uni-directional clock lane and one bi-directional data lane solution for
> > > > > communication links between components inside a mobile device.
> > > > > The data lane has full support for HS(uni-directional) and
> > > > > LP(bi-directional) data transfer mode.'
> > > > >
> > > > > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > > > > would not be added in next release.
> > > > >
> > > > > > So if there's nothing to convey to the driver, also the data-lanes should
> > > > > > be removed IMO.
> > > > > >
> > > > >
> > > > > However, 'data-lanes' property may still be required.
> > > > > It is known that either data-lanes or clock-lanes is an array of
> > > > > physical data lane indexes. Position of an entry determines the logical
> > > > > lane number, while the value of an entry indicates physical lane, e.g.,
> > > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > > > > the clock lane is on hardware lane 0.
> > > > >
> > > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > > > > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > > > > there is only a clock lane for OV02A10.
> > > > >
> > > > > Reminder:
> > > > > If 'data-lanes' property is not present, the driver would assume
> > > > > four-lane operation. This means for one-lane or two-lane operation, this
> > > > > property must be present and set to the right physical lane indexes.
> > > > > If the hardware does not support lane reordering, monotonically
> > > > > incremented values shall be used from 0 or 1 onwards, depending on
> > > > > whether or not there is also a clock lane.
> > > >
> > > > How can the driver use four lanes, considering the device only supports a
> > > > single lane??
> > > >
> > >
> > > I understood your meaning.
> > > If we omit the property 'data-lanes', the sensor should work still.
> > > But then what's the meaning of the existence of 'data-lanes'?
> > > If this property 'data-lanes' is always optional, then why dt-bindings
> > > provide the interface?
> > >
> > > In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
> > > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
> > > shall enable four-lane configuration, which may increase consumption of
> > > both power and resource in the process of IIC communication.
> >
> > Wouldn't the receiver still have the data-lanes property under its
> > endpoint node, telling it how many lanes and in which order should be
> > used?
> >
>
> The MIPI receiver(RX) shall use
> v4l2_async_notifier_add_fwnode_remote_subdev() API to parse the property
> "data-lanes" under sensor output port.
That's not true. The MIPI receiver driver parses its own port node
corresponding to the sensor. Also quoting the documentation [1]:
"An endpoint subnode of a device contains all properties needed for
_configuration of this device_ for data exchange with other device. In most
cases properties at the peer 'endpoint' nodes will be identical, however they
might need to be different when there is any signal modifications on the bus
between two devices, e.g. there are logic signal inverters on the lines."
In this case, there is such a signal modification if the sensor has a
1-lane bus and the receiver more lines, so the data-lanes properties
would be different on both sides.
[1] https://elixir.bootlin.com/linux/v5.7/source/Documentation/devicetree/bindings/media/video-interfaces.txt
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 11/11] remoteproc: stm32: Update M4 state in stm32_rproc_stop()
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Update the co-processor state in function stm32_rproc_stop() so that
it can be used in scenarios where the remoteproc core is attaching
to the M4.
Mainly based on the work published by Arnaud Pouliquen [1].
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
---
drivers/remoteproc/stm32_rproc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 77a20a638e0c..ad0307aaf3d5 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -503,6 +503,18 @@ static int stm32_rproc_stop(struct rproc *rproc)
}
}
+ /* update coprocessor state to OFF if available */
+ if (ddata->m4_state.map) {
+ err = regmap_update_bits(ddata->m4_state.map,
+ ddata->m4_state.reg,
+ ddata->m4_state.mask,
+ M4_STATE_OFF);
+ if (err) {
+ dev_err(&rproc->dev, "failed to set copro state\n");
+ return err;
+ }
+ }
+
return 0;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 09/11] remoteproc: stm32: Properly handle the resource table when attaching
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Properly set the remote processor's resource table based on where it was
loaded by the external entity when attaching to a remote processor.
Mainly based on the work published by Arnaud Pouliquen [1].
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/remoteproc/stm32_rproc.c | 75 ++++++++++++++++++++++++++++++++
1 file changed, 75 insertions(+)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 9316ce3b03c2..7c8789164af7 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -38,6 +38,8 @@
#define STM32_MBX_VQ1_ID 1
#define STM32_MBX_SHUTDOWN "shutdown"
+#define RSC_TBL_SIZE 1024
+
#define M4_STATE_OFF 0
#define M4_STATE_INI 1
#define M4_STATE_CRUN 2
@@ -85,6 +87,7 @@ struct stm32_rproc {
struct stm32_mbox mb[MBOX_NB_MBX];
struct workqueue_struct *workqueue;
bool secured_soc;
+ void __iomem *rsc_va;
};
static int stm32_rproc_pa_to_da(struct rproc *rproc, phys_addr_t pa, u64 *da)
@@ -668,6 +671,74 @@ static int stm32_rproc_get_m4_status(struct stm32_rproc *ddata,
return regmap_read(ddata->m4_state.map, ddata->m4_state.reg, state);
}
+static int stm32_rproc_da_to_pa(struct platform_device *pdev,
+ struct stm32_rproc *ddata,
+ u64 da, phys_addr_t *pa)
+{
+ struct device *dev = &pdev->dev;
+ struct stm32_rproc_mem *p_mem;
+ unsigned int i;
+
+ for (i = 0; i < ddata->nb_rmems; i++) {
+ p_mem = &ddata->rmems[i];
+
+ if (da < p_mem->dev_addr ||
+ da >= p_mem->dev_addr + p_mem->size)
+ continue;
+
+ *pa = da - p_mem->dev_addr + p_mem->bus_addr;
+ dev_dbg(dev, "da %llx to pa %#x\n", da, *pa);
+
+ return 0;
+ }
+
+ dev_err(dev, "can't translate da %llx\n", da);
+
+ return -EINVAL;
+}
+
+static int stm32_rproc_get_loaded_rsc_table(struct platform_device *pdev,
+ struct rproc *rproc,
+ struct stm32_rproc *ddata)
+{
+ struct device *dev = &pdev->dev;
+ phys_addr_t rsc_pa;
+ u32 rsc_da;
+ int err;
+
+ err = regmap_read(ddata->rsctbl.map, ddata->rsctbl.reg, &rsc_da);
+ if (err) {
+ dev_err(dev, "failed to read rsc tbl addr\n");
+ return err;
+ }
+
+ if (!rsc_da)
+ /* no rsc table */
+ return 0;
+
+ err = stm32_rproc_da_to_pa(pdev, ddata, rsc_da, &rsc_pa);
+ if (err)
+ return err;
+
+ ddata->rsc_va = devm_ioremap_wc(dev, rsc_pa, RSC_TBL_SIZE);
+ if (IS_ERR_OR_NULL(ddata->rsc_va)) {
+ dev_err(dev, "Unable to map memory region: %pa+%zx\n",
+ &rsc_pa, RSC_TBL_SIZE);
+ ddata->rsc_va = NULL;
+ return -ENOMEM;
+ }
+
+ /*
+ * The resource table is already loaded in device memory, no need
+ * to work with a cached table.
+ */
+ rproc->cached_table = NULL;
+ /* Assuming the resource table fits in 1kB is fair */
+ rproc->table_sz = RSC_TBL_SIZE;
+ rproc->table_ptr = (struct resource_table *)ddata->rsc_va;
+
+ return 0;
+}
static int stm32_rproc_probe(struct platform_device *pdev)
{
@@ -708,6 +779,10 @@ static int stm32_rproc_probe(struct platform_device *pdev)
ret = stm32_rproc_parse_memory_regions(rproc);
if (ret)
goto free_resources;
+
+ ret = stm32_rproc_get_loaded_rsc_table(pdev, rproc, ddata);
+ if (ret)
+ goto free_resources;
}
rproc->has_iommu = false;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 10/11] remoteproc: stm32: Introduce new attach() operation
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Introduce new attach function to be used when attaching to a
remote processor.
Mainly based on the work published by Arnaud Pouliquen [1].
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/remoteproc/stm32_rproc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 7c8789164af7..77a20a638e0c 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -459,6 +459,13 @@ static int stm32_rproc_start(struct rproc *rproc)
return stm32_rproc_set_hold_boot(rproc, true);
}
+static int stm32_rproc_attach(struct rproc *rproc)
+{
+ stm32_rproc_add_coredump_trace(rproc);
+
+ return stm32_rproc_set_hold_boot(rproc, true);
+}
+
static int stm32_rproc_stop(struct rproc *rproc)
{
struct stm32_rproc *ddata = rproc->priv;
@@ -524,6 +531,7 @@ static void stm32_rproc_kick(struct rproc *rproc, int vqid)
static struct rproc_ops st_rproc_ops = {
.start = stm32_rproc_start,
.stop = stm32_rproc_stop,
+ .attach = stm32_rproc_attach,
.kick = stm32_rproc_kick,
.load = rproc_elf_load_segments,
.parse_fw = stm32_rproc_parse_fw,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 08/11] remoteproc: stm32: Split function stm32_rproc_parse_fw()
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Split function stm32_rproc_parse_fw() in two parts, the first one
to parse the memory regions and the second one to load the
resource table. That way parsing of the memory regions can be
re-used when attaching to the remote processor.
Mainly based on the work published by Arnaud Pouliquen [1].
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Loic Pallardy <loic.pallardy@st.com>
---
drivers/remoteproc/stm32_rproc.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 2154c8b90a2a..9316ce3b03c2 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -212,7 +212,7 @@ static int stm32_rproc_elf_load_rsc_table(struct rproc *rproc,
return 0;
}
-static int stm32_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+static int stm32_rproc_parse_memory_regions(struct rproc *rproc)
{
struct device *dev = rproc->dev.parent;
struct device_node *np = dev->of_node;
@@ -265,6 +265,16 @@ static int stm32_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
index++;
}
+ return 0;
+}
+
+static int stm32_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ int ret = stm32_rproc_parse_memory_regions(rproc);
+
+ if (ret)
+ return ret;
+
return stm32_rproc_elf_load_rsc_table(rproc, fw);
}
@@ -692,15 +702,20 @@ static int stm32_rproc_probe(struct platform_device *pdev)
if (ret)
goto free_rproc;
- if (state == M4_STATE_CRUN)
+ if (state == M4_STATE_CRUN) {
rproc->state = RPROC_DETACHED;
+ ret = stm32_rproc_parse_memory_regions(rproc);
+ if (ret)
+ goto free_resources;
+ }
+
rproc->has_iommu = false;
ddata->workqueue = create_workqueue(dev_name(dev));
if (!ddata->workqueue) {
dev_err(dev, "cannot create workqueue\n");
ret = -ENOMEM;
- goto free_rproc;
+ goto free_resources;
}
platform_set_drvdata(pdev, rproc);
@@ -719,6 +734,8 @@ static int stm32_rproc_probe(struct platform_device *pdev)
stm32_rproc_free_mbox(rproc);
free_wkq:
destroy_workqueue(ddata->workqueue);
+free_resources:
+ rproc_resource_cleanup(rproc);
free_rproc:
if (device_may_wakeup(dev)) {
dev_pm_clear_wake_irq(dev);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 07/11] remoteproc: Make function rproc_resource_cleanup() public
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Make function rproc_resource_cleanup() public so that it can be
used by platform drivers when allocating resources to be used by
a detached remote processor.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/remoteproc/remoteproc_core.c | 3 ++-
include/linux/remoteproc.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index a8adc712e7f6..6b0ded714beb 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1272,7 +1272,7 @@ static void rproc_coredump_cleanup(struct rproc *rproc)
* This function will free all resources acquired for @rproc, and it
* is called whenever @rproc either shuts down or fails to boot.
*/
-static void rproc_resource_cleanup(struct rproc *rproc)
+void rproc_resource_cleanup(struct rproc *rproc)
{
struct rproc_mem_entry *entry, *tmp;
struct rproc_debug_trace *trace, *ttmp;
@@ -1316,6 +1316,7 @@ static void rproc_resource_cleanup(struct rproc *rproc)
rproc_coredump_cleanup(rproc);
}
+EXPORT_SYMBOL(rproc_resource_cleanup);
static int rproc_start(struct rproc *rproc, const struct firmware *fw)
{
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index cf5e31556780..7c0567029f7c 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -610,6 +610,7 @@ void rproc_put(struct rproc *rproc);
int rproc_add(struct rproc *rproc);
int rproc_del(struct rproc *rproc);
void rproc_free(struct rproc *rproc);
+void rproc_resource_cleanup(struct rproc *rproc);
struct rproc *devm_rproc_alloc(struct device *dev, const char *name,
const struct rproc_ops *ops,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 06/11] remoteproc: stm32: Properly set co-processor state when attaching
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Introduce the required mechanic to set the state of the M4 in order
to properly deal with scenarios where the co-processor has been
stated by another entity.
Mainly based on the work published by Arnaud Pouliquen [1].
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
drivers/remoteproc/stm32_rproc.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 80fd8fd831da..2154c8b90a2a 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -38,6 +38,13 @@
#define STM32_MBX_VQ1_ID 1
#define STM32_MBX_SHUTDOWN "shutdown"
+#define M4_STATE_OFF 0
+#define M4_STATE_INI 1
+#define M4_STATE_CRUN 2
+#define M4_STATE_CSTOP 3
+#define M4_STATE_STANDBY 4
+#define M4_STATE_CRASH 5
+
struct stm32_syscon {
struct regmap *map;
u32 reg;
@@ -635,12 +642,30 @@ static int stm32_rproc_parse_dt(struct platform_device *pdev,
return 0;
}
+static int stm32_rproc_get_m4_status(struct stm32_rproc *ddata,
+ unsigned int *state)
+{
+ /* See stm32_rproc_parse_dt() */
+ if (!ddata->m4_state.map) {
+ /*
+ * We couldn't get the coprocessor's state, assume
+ * it is not running.
+ */
+ state = M4_STATE_OFF;
+ return 0;
+ }
+
+ return regmap_read(ddata->m4_state.map, ddata->m4_state.reg, state);
+}
+
+
static int stm32_rproc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct stm32_rproc *ddata;
struct device_node *np = dev->of_node;
struct rproc *rproc;
+ unsigned int state;
int ret;
ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
@@ -663,6 +688,13 @@ static int stm32_rproc_probe(struct platform_device *pdev)
if (ret)
goto free_rproc;
+ ret = stm32_rproc_get_m4_status(ddata, &state);
+ if (ret)
+ goto free_rproc;
+
+ if (state == M4_STATE_CRUN)
+ rproc->state = RPROC_DETACHED;
+
rproc->has_iommu = false;
ddata->workqueue = create_workqueue(dev_name(dev));
if (!ddata->workqueue) {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 05/11] remoteproc: stm32: Parse syscon that will manage M4 synchronisation
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Get from the DT the syncon to probe the state of the remote processor
and the location of the resource table.
Mainly based on the work published by Arnaud Pouliquen [1].
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Loic Pallardy <loic.pallardy@st.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
drivers/remoteproc/stm32_rproc.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 3e3b199a02c1..80fd8fd831da 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -70,6 +70,8 @@ struct stm32_rproc {
struct reset_control *rst;
struct stm32_syscon hold_boot;
struct stm32_syscon pdds;
+ struct stm32_syscon m4_state;
+ struct stm32_syscon rsctbl;
int wdg_irq;
u32 nb_rmems;
struct stm32_rproc_mem *rmems;
@@ -606,6 +608,30 @@ static int stm32_rproc_parse_dt(struct platform_device *pdev,
*auto_boot = of_property_read_bool(np, "st,auto-boot");
+ /*
+ * See if we can check the M4 status, i.e if it was started
+ * from the boot loader or not.
+ */
+ err = stm32_rproc_get_syscon(np, "st,syscfg-m4-state",
+ &ddata->m4_state);
+ if (err) {
+ /* remember this */
+ ddata->m4_state.map = NULL;
+ /* no coprocessor state syscon (optional) */
+ dev_warn(dev, "m4 state not supported\n");
+
+ /* no need to go further */
+ return 0;
+ }
+
+ /* See if we can get the resource table */
+ err = stm32_rproc_get_syscon(np, "st,syscfg-rsc-tbl",
+ &ddata->rsctbl);
+ if (err) {
+ /* no rsc table syscon (optional) */
+ dev_warn(dev, "rsc tbl syscon not supported\n");
+ }
+
return 0;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 04/11] remoteproc: stm32: Remove memory translation from DT parsing
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Other than one has to be done after the other, there is no correlation
between memory translation and DT parsing. As such move function
stm32_rproc_of_memory_translations() to stm32_rproc_probe() so that
stm32_rproc_parse_dt() can be extended to look for attach bindings
in a clean way.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Loic Pallardy <loic.pallardy@st.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
drivers/remoteproc/stm32_rproc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 1e512ddf2591..3e3b199a02c1 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -606,7 +606,7 @@ static int stm32_rproc_parse_dt(struct platform_device *pdev,
*auto_boot = of_property_read_bool(np, "st,auto-boot");
- return stm32_rproc_of_memory_translations(pdev, ddata);
+ return 0;
}
static int stm32_rproc_probe(struct platform_device *pdev)
@@ -633,6 +633,10 @@ static int stm32_rproc_probe(struct platform_device *pdev)
if (ret)
goto free_rproc;
+ ret = stm32_rproc_of_memory_translations(pdev, ddata);
+ if (ret)
+ goto free_rproc;
+
rproc->has_iommu = false;
ddata->workqueue = create_workqueue(dev_name(dev));
if (!ddata->workqueue) {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 03/11] remoteproc: stm32: Decouple rproc from DT parsing
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Remove the remote processor from the process of parsing the device tree
since (1) there is no correlation between them and (2) to use the
information that was gathered to make a decision on whether to
synchronise with the M4 or not.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
drivers/remoteproc/stm32_rproc.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 94fd687fb5b2..1e512ddf2591 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -538,12 +538,11 @@ static int stm32_rproc_get_syscon(struct device_node *np, const char *prop,
return err;
}
-static int stm32_rproc_parse_dt(struct platform_device *pdev)
+static int stm32_rproc_parse_dt(struct platform_device *pdev,
+ struct stm32_rproc *ddata, bool *auto_boot)
{
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
- struct rproc *rproc = platform_get_drvdata(pdev);
- struct stm32_rproc *ddata = rproc->priv;
struct stm32_syscon tz;
unsigned int tzen;
int err, irq;
@@ -589,7 +588,7 @@ static int stm32_rproc_parse_dt(struct platform_device *pdev)
err = regmap_read(tz.map, tz.reg, &tzen);
if (err) {
- dev_err(&rproc->dev, "failed to read tzen\n");
+ dev_err(dev, "failed to read tzen\n");
return err;
}
ddata->secured_soc = tzen & tz.mask;
@@ -605,7 +604,7 @@ static int stm32_rproc_parse_dt(struct platform_device *pdev)
if (err)
dev_info(dev, "failed to get pdds\n");
- rproc->auto_boot = of_property_read_bool(np, "st,auto-boot");
+ *auto_boot = of_property_read_bool(np, "st,auto-boot");
return stm32_rproc_of_memory_translations(pdev, ddata);
}
@@ -626,9 +625,15 @@ static int stm32_rproc_probe(struct platform_device *pdev)
if (!rproc)
return -ENOMEM;
+ ddata = rproc->priv;
+
rproc_coredump_set_elf_info(rproc, ELFCLASS32, EM_NONE);
+
+ ret = stm32_rproc_parse_dt(pdev, ddata, &rproc->auto_boot);
+ if (ret)
+ goto free_rproc;
+
rproc->has_iommu = false;
- ddata = rproc->priv;
ddata->workqueue = create_workqueue(dev_name(dev));
if (!ddata->workqueue) {
dev_err(dev, "cannot create workqueue\n");
@@ -638,13 +643,9 @@ static int stm32_rproc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, rproc);
- ret = stm32_rproc_parse_dt(pdev);
- if (ret)
- goto free_wkq;
-
ret = stm32_rproc_request_mbox(rproc);
if (ret)
- goto free_rproc;
+ goto free_wkq;
ret = rproc_add(rproc);
if (ret)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 01/11] remoteproc: stm32: Decouple rproc from memory translation
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Remove the remote processor from the process of parsing the memory
ranges since there is no correlation between them.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Loic Pallardy <loic.pallardy@st.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
drivers/remoteproc/stm32_rproc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index f45b8d597da0..a80733fb08e7 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -127,10 +127,10 @@ static int stm32_rproc_mem_release(struct rproc *rproc,
return 0;
}
-static int stm32_rproc_of_memory_translations(struct rproc *rproc)
+static int stm32_rproc_of_memory_translations(struct platform_device *pdev,
+ struct stm32_rproc *ddata)
{
- struct device *parent, *dev = rproc->dev.parent;
- struct stm32_rproc *ddata = rproc->priv;
+ struct device *parent, *dev = &pdev->dev;
struct device_node *np;
struct stm32_rproc_mem *p_mems;
struct stm32_rproc_mem_ranges *mem_range;
@@ -606,7 +606,7 @@ static int stm32_rproc_parse_dt(struct platform_device *pdev)
rproc->auto_boot = of_property_read_bool(np, "st,auto-boot");
- return stm32_rproc_of_memory_translations(rproc);
+ return stm32_rproc_of_memory_translations(pdev, ddata);
}
static int stm32_rproc_probe(struct platform_device *pdev)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 02/11] remoteproc: stm32: Request IRQ with platform device
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200601175552.22286-1-mathieu.poirier@linaro.org>
Request IRQ with platform device rather than remote proc in order to
call stm32_rproc_parse_dt() before rproc_alloc(). That way we can
know whether we need to synchronise with the MCU or not.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Loic Pallardy <loic.pallardy@st.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
drivers/remoteproc/stm32_rproc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index a80733fb08e7..94fd687fb5b2 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -261,7 +261,8 @@ static int stm32_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
static irqreturn_t stm32_rproc_wdg(int irq, void *data)
{
- struct rproc *rproc = data;
+ struct platform_device *pdev = data;
+ struct rproc *rproc = platform_get_drvdata(pdev);
rproc_report_crash(rproc, RPROC_WATCHDOG);
@@ -553,7 +554,7 @@ static int stm32_rproc_parse_dt(struct platform_device *pdev)
if (irq > 0) {
err = devm_request_irq(dev, irq, stm32_rproc_wdg, 0,
- dev_name(dev), rproc);
+ dev_name(dev), pdev);
if (err) {
dev_err(dev, "failed to request wdg irq\n");
return err;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 00/11] remoteproc: stm32: Add support for attaching to M4
From: Mathieu Poirier @ 2020-06-01 17:55 UTC (permalink / raw)
To: bjorn.andersson, ohad, mcoquelin.stm32, alexandre.torgue
Cc: loic.pallardy, arnaud.pouliquen, linux-remoteproc, linux-kernel,
linux-stm32, linux-arm-kernel
This set applies on top of [1] and refactors the STM32 platform code in
order to attach to the M4 remote processor when it has been started by the
boot loader.
It carries the same functionatlity as the previeous revision but account
for changes in the remoteproc core to support attaching scenarios. More
specifically patches 6 to 10 should be given special consideration.
Note that I skipped over v3 and went directly to v4 in order to synchronise
with the remoterproc core patchset[1] that is set at v4.
Tested on ST's mp157c development board.
Thanks,
Mathieu
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=296713
Mathieu Poirier (11):
remoteproc: stm32: Decouple rproc from memory translation
remoteproc: stm32: Request IRQ with platform device
remoteproc: stm32: Decouple rproc from DT parsing
remoteproc: stm32: Remove memory translation from DT parsing
remoteproc: stm32: Parse syscon that will manage M4 synchronisation
remoteproc: stm32: Properly set co-processor state when attaching
remoteproc: Make function rproc_resource_cleanup() public
remoteproc: stm32: Split function stm32_rproc_parse_fw()
remoteproc: stm32: Properly handle the resource table when attaching
remoteproc: stm32: Introduce new attach() operation
remoteproc: stm32: Update M4 state in stm32_rproc_stop()
drivers/remoteproc/remoteproc_core.c | 3 +-
drivers/remoteproc/stm32_rproc.c | 214 ++++++++++++++++++++++++---
include/linux/remoteproc.h | 1 +
3 files changed, 198 insertions(+), 20 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pinctrl-single: fix pcs_parse_pinconf() return val
From: Drew Fustini @ 2020-06-01 17:48 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linus Walleij, linux-kernel, Robert Nelson, linux-gpio,
Jason Kridner, Haojian Zhuang, linux-omap, linux-arm-kernel
In-Reply-To: <20200601161851.GC37466@atomide.com>
On Mon, Jun 01, 2020 at 09:18:51AM -0700, Tony Lindgren wrote:
> * Drew Fustini <drew@beagleboard.org> [200531 20:42]:
> > This patch causes pcs_parse_pinconf() to return an error when no
> > pinctrl_map is added. The current behavior is to return 0 when
> > !PCS_HAS_PINCONF or !nconfs. Thus pcs_parse_one_pinctrl_entry()
> > incorrectly assumes that a map was added and sets num_maps = 2.
>
> Looks OK to me, would be good to wait for Haojian to test this one.
>
> Regards,
>
> Tony
Yes, I would like to get input as I don't have the other platforms using
"pinconf,single":
$ git grep 'compatible = "pinconf-single"' arch/
arch/arm/boot/dts/am33xx-l4.dtsi: compatible = "pinconf-single";
arch/arm/boot/dts/hi3620.dtsi: compatible = "pinconf-single";
arch/arm/boot/dts/pxa3xx.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hi6220.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hi6220.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hikey970-pinctrl.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hikey970-pinctrl.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hikey970-pinctrl.dtsi: compatible = "pinconf-single";
arch/arm64/boot/dts/hisilicon/hikey970-pinctrl.dtsi: compatible = "pinconf-single";
NOTE: the arch/arm/boot/dts/am33xx-l4.dtsi was patched by me from
"pinctrl-single" to "pinconf-single. But, I think for upstream
submission I would need to move that to one of the beaglebone specific
dts files like am335x-bone-common.dtsi.
I believe this pinctrl-single.c patch fixes a flaw in return logic and
is useful regardless of whether beaglebone adopts "pinconf,single".
However, I would very much like to get input from others in case my
analysis is too narrow.
Thanks,
Drew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
From: Bjorn Helgaas @ 2020-06-01 17:41 UTC (permalink / raw)
To: Joerg Roedel
Cc: jean-philippe, Lorenzo Pieralisi, Herbert Xu, Arnd Bergmann,
linux-pci, Greg Kroah-Hartman, Hanjun Guo, Rafael J. Wysocki,
linux-kernel, iommu, kenneth-lee-2012, linux-acpi, Wangzhou,
linux-crypto, Sudeep Holla, Bjorn Helgaas, Zhangfei Gao,
linux-arm-kernel, Len Brown
In-Reply-To: <20200528073344.GO5221@8bytes.org>
On Thu, May 28, 2020 at 09:33:44AM +0200, Joerg Roedel wrote:
> On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote:
> > Is this slowdown significant? We already iterate over every device
> > when applying PCI_FIXUP_FINAL quirks, so if we used the existing
> > PCI_FIXUP_FINAL, we wouldn't be adding a new loop. We would only be
> > adding two more iterations to the loop in pci_do_fixups() that tries
> > to match quirks against the current device. I doubt that would be a
> > measurable slowdown.
>
> I don't know how significant it is, but I remember people complaining
> about adding new PCI quirks because it takes too long for them to run
> them all. That was in the discussion about the quirk disabling ATS on
> AMD Stoney systems.
>
> So it probably depends on how many PCI devices are in the system whether
> it causes any measureable slowdown.
I found this [1] from Paul Menzel, which was a slowdown caused by
quirk_usb_early_handoff(). I think the real problem is individual
quirks that take a long time.
The PCI_FIXUP_IOMMU things we're talking about should be fast, and of
course, they're only run for matching devices anyway. So I'd rather
keep them as PCI_FIXUP_FINAL than add a whole new phase.
Bjorn
[1] https://lore.kernel.org/linux-pci/b1533fd5-1fae-7256-9597-36d3d5de9d2a@molgen.mpg.de/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] misc: atmel-ssc: lock with mutex instead of spinlock
From: Michał Mirosław @ 2020-06-01 17:31 UTC (permalink / raw)
To: Markus Elfring
Cc: Alexandre Belloni, Arnd Bergmann, Greg Kroah-Hartman,
kernel-janitors, linux-kernel, Ludovic Desroches,
linux-arm-kernel
In-Reply-To: <eb9b1cb3-5b3f-f387-da45-71427a4383ed@web.de>
On Mon, Jun 01, 2020 at 11:18:48AM +0200, Markus Elfring wrote:
> > Uninterruptible context is not needed in the driver and causes lockdep
> > warning because of mutex taken in of_alias_get_id().
>
> Was a spin lock taken?
> > Convert the lock to mutex to avoid the issue.
> Would you like to add the tag “Fixes” to the commit message?
I guess we can add:
Fixes: 099343c64e16 ("ARM: at91: atmel-ssc: add device tree support")
Best Regards
Michał Mirosław
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
From: Sai Prakash Ranjan @ 2020-06-01 17:24 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach
Cc: Sai Prakash Ranjan, linux-arm-msm, coresight, linux-kernel,
Stephen Boyd, linux-arm-kernel
Implement a shutdown callback to ensure ETR/ETF hardware is
properly shutdown in reboot/shutdown path. This is required
for ETR/ETF which has SMMU address translation enabled like
on SC7180 SoC and few others. If the hardware is still accessing
memory after SMMU translation is disabled as part of SMMU
shutdown callback in system reboot or shutdown path, then
IOVAs(I/O virtual address) which it was using will go on the bus
as the physical addresses which might result in unknown crashes
(NoC/interconnect errors). So we make sure from this shutdown
callback that the ETR/ETF is shutdown before SMMU translation is
disabled and device_link in SMMU driver will take care of ordering
of shutdown callbacks such that SMMU shutdown callback is not
called before any of its consumer shutdown callbacks.
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
Changes since v1:
* Use mode flag and drop enable flag as Mike suggested.
* Use spinlock before tmc hw disable as Mike suggested.
---
.../hwtracing/coresight/coresight-tmc-etf.c | 4 +--
.../hwtracing/coresight/coresight-tmc-etr.c | 2 +-
drivers/hwtracing/coresight/coresight-tmc.c | 33 +++++++++++++++++++
drivers/hwtracing/coresight/coresight-tmc.h | 3 ++
4 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 36cce2bfb744..cba3e7592820 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -85,7 +85,7 @@ static void __tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
CS_LOCK(drvdata->base);
}
-static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
+void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
{
__tmc_etb_disable_hw(drvdata);
coresight_disclaim_device(drvdata->base);
@@ -118,7 +118,7 @@ static int tmc_etf_enable_hw(struct tmc_drvdata *drvdata)
return 0;
}
-static void tmc_etf_disable_hw(struct tmc_drvdata *drvdata)
+void tmc_etf_disable_hw(struct tmc_drvdata *drvdata)
{
CS_UNLOCK(drvdata->base);
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 625882bc8b08..b29c2db94d96 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1110,7 +1110,7 @@ static void __tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
}
-static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
+void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
{
__tmc_etr_disable_hw(drvdata);
/* Disable CATU device if this ETR is connected to one */
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index 39fba1d16e6e..c7902ce0bd3b 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -538,6 +538,38 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
return ret;
}
+static void tmc_shutdown(struct amba_device *adev)
+{
+ unsigned long flags;
+ struct tmc_drvdata *drvdata = amba_get_drvdata(adev);
+
+ spin_lock_irqsave(&drvdata->spinlock, flags);
+
+ if (drvdata->mode == CS_MODE_DISABLED)
+ goto out;
+
+ /*
+ * We do not care about the active trace sessions here
+ * since the system is going down unlike remove callback,
+ * just make sure that the hardware is shutdown.
+ */
+ switch (drvdata->config_type) {
+ case TMC_CONFIG_TYPE_ETB:
+ tmc_etb_disable_hw(drvdata);
+ break;
+ case TMC_CONFIG_TYPE_ETF:
+ tmc_etf_disable_hw(drvdata);
+ break;
+ case TMC_CONFIG_TYPE_ETR:
+ tmc_etr_disable_hw(drvdata);
+ }
+
+out:
+ spin_unlock_irqrestore(&drvdata->spinlock, flags);
+ misc_deregister(&drvdata->miscdev);
+ coresight_unregister(drvdata->csdev);
+}
+
static const struct amba_id tmc_ids[] = {
CS_AMBA_ID(0x000bb961),
/* Coresight SoC 600 TMC-ETR/ETS */
@@ -556,6 +588,7 @@ static struct amba_driver tmc_driver = {
.suppress_bind_attrs = true,
},
.probe = tmc_probe,
+ .shutdown = tmc_shutdown,
.id_table = tmc_ids,
};
builtin_amba_driver(tmc_driver);
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index 71de978575f3..0a77f2f25090 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -260,6 +260,8 @@ u32 tmc_get_memwidth_mask(struct tmc_drvdata *drvdata);
/* ETB/ETF functions */
int tmc_read_prepare_etb(struct tmc_drvdata *drvdata);
int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata);
+void tmc_etb_disable_hw(struct tmc_drvdata *drvdata);
+void tmc_etf_disable_hw(struct tmc_drvdata *drvdata);
extern const struct coresight_ops tmc_etb_cs_ops;
extern const struct coresight_ops tmc_etf_cs_ops;
@@ -268,6 +270,7 @@ ssize_t tmc_etb_get_sysfs_trace(struct tmc_drvdata *drvdata,
/* ETR functions */
int tmc_read_prepare_etr(struct tmc_drvdata *drvdata);
int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata);
+void tmc_etr_disable_hw(struct tmc_drvdata *drvdata);
extern const struct coresight_ops tmc_etr_cs_ops;
ssize_t tmc_etr_get_sysfs_trace(struct tmc_drvdata *drvdata,
loff_t pos, size_t len, char **bufpp);
base-commit: 059e38815950dbec65beafe03757bce9436e89a4
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
From: Sai Prakash Ranjan @ 2020-06-01 17:15 UTC (permalink / raw)
To: Mike Leach
Cc: Mathieu Poirier, Suzuki K Poulose, linux-arm-msm, Coresight ML,
Linux Kernel Mailing List, Stephen Boyd, linux-arm-kernel
In-Reply-To: <CAJ9a7VgxDru8P_RXE2ewGkSA2mfCNvOp+hMuNLB4AszXBOUp1g@mail.gmail.com>
Hi Mike,
Thanks for the review.
On 2020-06-01 19:05, Mike Leach wrote:
> Hi,
>
> On Mon, 1 Jun 2020 at 09:02, Sai Prakash Ranjan
> <saiprakash.ranjan@codeaurora.org> wrote:
>>
>> Implement a shutdown callback to ensure ETR/ETF hardware is
>> properly shutdown in reboot/shutdown path. This is required
>> for ETR/ETF which has SMMU address translation enabled like
>> on SC7180 SoC and few others. If the hardware is still accessing
>> memory after SMMU translation is disabled as part of SMMU
>> shutdown callback in system reboot or shutdown path, then
>> IOVAs(I/O virtual address) which it was using will go on the bus
>> as the physical addresses which might result in unknown crashes
>> (NoC/interconnect errors). So we make sure from this shutdown
>> callback that the ETR/ETF is shutdown before SMMU translation is
>> disabled and device_link in SMMU driver will take care of ordering
>> of shutdown callbacks such that SMMU shutdown callback is not
>> called before any of its consumer shutdown callbacks.
>>
>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> ---
>> .../hwtracing/coresight/coresight-tmc-etf.c | 4 +--
>> .../hwtracing/coresight/coresight-tmc-etr.c | 2 +-
>> drivers/hwtracing/coresight/coresight-tmc.c | 29
>> +++++++++++++++++++
>> drivers/hwtracing/coresight/coresight-tmc.h | 3 ++
>> 4 files changed, 35 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c
>> b/drivers/hwtracing/coresight/coresight-tmc-etf.c
>> index 36cce2bfb744..cba3e7592820 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
>> @@ -85,7 +85,7 @@ static void __tmc_etb_disable_hw(struct tmc_drvdata
>> *drvdata)
>> CS_LOCK(drvdata->base);
>> }
>>
>> -static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
>> +void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
>> {
>> __tmc_etb_disable_hw(drvdata);
>> coresight_disclaim_device(drvdata->base);
>> @@ -118,7 +118,7 @@ static int tmc_etf_enable_hw(struct tmc_drvdata
>> *drvdata)
>> return 0;
>> }
>>
>> -static void tmc_etf_disable_hw(struct tmc_drvdata *drvdata)
>> +void tmc_etf_disable_hw(struct tmc_drvdata *drvdata)
>> {
>> CS_UNLOCK(drvdata->base);
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> index 625882bc8b08..b29c2db94d96 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> @@ -1110,7 +1110,7 @@ static void __tmc_etr_disable_hw(struct
>> tmc_drvdata *drvdata)
>>
>> }
>>
>> -static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>> +void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>> {
>> __tmc_etr_disable_hw(drvdata);
>> /* Disable CATU device if this ETR is connected to one */
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c
>> b/drivers/hwtracing/coresight/coresight-tmc.c
>> index 5a271ebc4585..7e687a356fe0 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
>> @@ -540,6 +540,34 @@ static int tmc_probe(struct amba_device *adev,
>> const struct amba_id *id)
>> return ret;
>> }
>>
>> +static void tmc_shutdown(struct amba_device *adev)
>> +{
>> + struct tmc_drvdata *drvdata = amba_get_drvdata(adev);
>> +
>
> Take drvdata->spinlock here? The tmc_xxx_disable_hw functions are
> normally called with the spinlock claimed.
>
Sure will take spinlock here.
>> + if (!drvdata->enable)
>
> As per previous patch drvdata->mode can be used here.
>
Yes, will use mode here and drop enable flag in the next version.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64 updates for 5.8
From: Will Deacon @ 2020-06-01 17:13 UTC (permalink / raw)
To: torvalds; +Cc: peterz, catalin.marinas, linux-kernel, bp, maz, linux-arm-kernel
Hi Linus,
Please pull this sizeable pile of arm64 updates for 5.8. Summary in the tag,
but the big two features are support for Branch Target Identification and
Clang's Shadow Call stack. The latter is currently arm64-only, but the
high-level parts are all in core code so it could easily be adopted by
other architectures pending toolchain support.
Please note that this includes the x86/asm branch from -tip due to a
dependency from the BTI code on the new 'CONFIG_ARCH_USE_SYM_ANNOTATIONS'
option. I've left that in the diffstat below because it's only two commits.
Cheers,
Will
--->8
The following changes since commit 6a8b55ed4056ea5559ebe4f6a4b247f627870d4c:
Linux 5.7-rc3 (2020-04-26 13:51:02 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-upstream
for you to fetch changes up to 082af5ec5080b028f7d0846a6c27cbb87f288205:
Merge branch 'for-next/scs' into for-next/core (2020-05-28 18:03:40 +0100)
----------------------------------------------------------------
arm64 updates for 5.8
- Branch Target Identification (BTI)
* Support for ARMv8.5-BTI in both user- and kernel-space. This
allows branch targets to limit the types of branch from which
they can be called and additionally prevents branching to
arbitrary code, although kernel support requires a very recent
toolchain.
* Function annotation via SYM_FUNC_START() so that assembly
functions are wrapped with the relevant "landing pad"
instructions.
* BPF and vDSO updates to use the new instructions.
* Addition of a new HWCAP and exposure of BTI capability to
userspace via ID register emulation, along with ELF loader
support for the BTI feature in .note.gnu.property.
* Non-critical fixes to CFI unwind annotations in the sigreturn
trampoline.
- Shadow Call Stack (SCS)
* Support for Clang's Shadow Call Stack feature, which reserves
platform register x18 to point at a separate stack for each
task that holds only return addresses. This protects function
return control flow from buffer overruns on the main stack.
* Save/restore of x18 across problematic boundaries (user-mode,
hypervisor, EFI, suspend, etc).
* Core support for SCS, should other architectures want to use it
too.
* SCS overflow checking on context-switch as part of the existing
stack limit check if CONFIG_SCHED_STACK_END_CHECK=y.
- CPU feature detection
* Removed numerous "SANITY CHECK" errors when running on a system
with mismatched AArch32 support at EL1. This is primarily a
concern for KVM, which disabled support for 32-bit guests on
such a system.
* Addition of new ID registers and fields as the architecture has
been extended.
- Perf and PMU drivers
* Minor fixes and cleanups to system PMU drivers.
- Hardware errata
* Unify KVM workarounds for VHE and nVHE configurations.
* Sort vendor errata entries in Kconfig.
- Secure Monitor Call Calling Convention (SMCCC)
* Update to the latest specification from Arm (v1.2).
* Allow PSCI code to query the SMCCC version.
- Software Delegated Exception Interface (SDEI)
* Unexport a bunch of unused symbols.
* Minor fixes to handling of firmware data.
- Pointer authentication
* Add support for dumping the kernel PAC mask in vmcoreinfo so
that the stack can be unwound by tools such as kdump.
* Simplification of key initialisation during CPU bringup.
- BPF backend
* Improve immediate generation for logical and add/sub
instructions.
- vDSO
- Minor fixes to the linker flags for consistency with other
architectures and support for LLVM's unwinder.
- Clean up logic to initialise and map the vDSO into userspace.
- ACPI
- Work around for an ambiguity in the IORT specification relating
to the "num_ids" field.
- Support _DMA method for all named components rather than only
PCIe root complexes.
- Minor other IORT-related fixes.
- Miscellaneous
* Initialise debug traps early for KGDB and fix KDB cacheflushing
deadlock.
* Minor tweaks to early boot state (documentation update, set
TEXT_OFFSET to 0x0, increase alignment of PE/COFF sections).
* Refactoring and cleanup
----------------------------------------------------------------
Amit Daniel Kachhap (2):
arm64/crash_core: Export KERNELPACMASK in vmcoreinfo
Documentation/vmcoreinfo: Add documentation for 'KERNELPACMASK'
Andrew Scull (1):
arm64: Unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}
Anshuman Khandual (16):
arm64/cpuinfo: Move device_initcall() near cpuinfo_regs_init()
arm64/cpufeature: Validate hypervisor capabilities during CPU hotplug
arm64/cpufeature: Drop open encodings while extracting parange
arm64/cpufeature: Add explicit ftr_id_isar0[] for ID_ISAR0 register
arm64/cpufeature: Drop TraceFilt feature exposure from ID_DFR0 register
arm64/cpufeature: Make doublelock a signed feature in ID_AA64DFR0
arm64/cpufeature: Introduce ID_PFR2 CPU register
arm64/cpufeature: Introduce ID_DFR1 CPU register
arm64/cpufeature: Introduce ID_MMFR5 CPU register
arm64/cpufeature: Add remaining feature bits in ID_PFR0 register
arm64/cpufeature: Add remaining feature bits in ID_MMFR4 register
arm64/cpufeature: Add remaining feature bits in ID_AA64ISAR0 register
arm64/cpufeature: Add remaining feature bits in ID_AA64PFR0 register
arm64/cpufeature: Add remaining feature bits in ID_AA64PFR1 register
arm64/cpuinfo: Add ID_MMFR4_EL1 into the cpuinfo_arm64 context
arm64/cpufeature: Add get_arm64_ftr_reg_nowarn()
Ard Biesheuvel (9):
arm64: rename stext to primary_entry
arm64: drop GZFLAGS definition and export
arm64/kernel: vmlinux.lds: drop redundant discard/keep macros
arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
arm64: drop duplicate definitions of ID_AA64MMFR0_TGRAN constants
efi/libstub/arm64: align PE/COFF sections to segment alignment
ACPI/IORT: take _DMA methods into account for named components
Revert "ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map()"
ACPI/IORT: work around num_ids ambiguity
Borislav Petkov (1):
x86/32: Remove CONFIG_DOUBLEFAULT
Catalin Marinas (1):
arm64: Reorder the macro arguments in the copy routines
Christoph Hellwig (1):
firmware: arm_sdei: remove unused interfaces
Daniel Kiss (1):
mm: smaps: Report arm64 guarded pages in smaps
Daniel Thompson (1):
arm64: cacheflush: Fix KGDB trap detection
Dave Martin (11):
ELF: UAPI and Kconfig additions for ELF program properties
ELF: Add ELF program property parsing support
arm64: Basic Branch Target Identification support
elf: Allow arch to tweak initial mmap prot flags
arm64: elf: Enable BTI at exec based on ELF program properties
arm64: BTI: Decode BYTPE bits when printing PSTATE
arm64: unify native/compat instruction skipping
arm64: traps: Shuffle code to eliminate forward declarations
arm64: BTI: Reset BTYPE when skipping emulated instructions
KVM: arm64: BTI: Reset BTYPE when skipping emulated instructions
arm64: BTI: Add Kconfig entry for userspace BTI
Douglas Anderson (1):
arm64: Call debug_traps_init() from trap_init() to help early kgdb
Gavin Shan (2):
arm64/mm: Use phys_to_page() to access pgtable memory
arm64/kernel: Fix range on invalidating dcache for boot page tables
Geert Uytterhoeven (2):
arm64: Sort vendor-specific errata
arm64: cpufeature: Add "or" to mitigations for multiple errata
George Spelvin (1):
arm64: kexec_file: Avoid temp buffer for RNG seed
Guixiong Wei (1):
arm: mm: use __pfn_to_section() to get mem_section
Hanjun Guo (4):
ACPI: IORT: Add extra message "applying workaround" for off-by-1 issue
ACPI: GTDT: Put GTDT table after parsing
ACPI: IORT: Add comments for not calling acpi_put_table()
firmware: arm_sdei: Put the SDEI table after using it
James Morse (1):
firmware: arm_sdei: Document the motivation behind these set_fs() calls
Jason Yan (1):
arm64: entry: remove unneeded semicolon in el1_sync_handler()
Jean-Philippe Brucker (2):
pmu/smmuv3: Clear IRQ affinity hint on device removal
arm64: mm: Add asid_gen_match() helper
Luke Nelson (3):
arm64: insn: Fix two bugs in encoding 32-bit logical immediates
bpf, arm64: Optimize AND,OR,XOR,JSET BPF_K using arm64 logical immediates
bpf, arm64: Optimize ADD,SUB,JMP BPF_K using arm64 add/sub immediates
Marc Zyngier (2):
KVM: arm64: Check advertised Stage-2 page size capability
KVM: arm64: Move __load_guest_stage2 to kvm_mmu.h
Mark Brown (23):
arm64: mm: Display guarded pages in ptdump
arm64: bti: Document behaviour for dynamically linked binaries
x86/asm: Provide a Kconfig symbol for disabling old assembly annotations
arm64: lib: Consistently enable crc32 extension
arm64: entry: Refactor and modernise annotation for ret_to_user
arm64: kernel: Convert to modern annotations for assembly functions
arm64: Disable old style assembly annotations
arm64: insn: Add constants for new HINT instruction decode
arm64: insn: Provide a better name for aarch64_insn_is_nop()
arm64: insn: Don't assume unrecognized HINTs are skippable
arm64: insn: Report PAC and BTI instructions as skippable
arm64: Document why we enable PAC support for leaf functions
arm64: bti: Support building kernel C code using BTI
arm64: asm: Override SYM_FUNC_START when building the kernel with BTI
arm64: Set GP bit in kernel page tables to enable BTI for the kernel
arm64: bpf: Annotate JITed code for BTI
arm64: mm: Mark executable text as guarded pages
arm64: bti: Provide Kconfig for kernel mode BTI
arm64: asm: Provide a mechanism for generating ELF note for BTI
arm64: vdso: Annotate for BTI
arm64: vdso: Force the vDSO to be linked as BTI when built for BTI
arm64: vdso: Map the vDSO text with guarded pages when built for BTI
arm64: bti: Fix support for userspace only BTI
Mark Rutland (6):
arm64: remove ptrauth_keys_install_kernel sync arg
arm64: simplify ptrauth initialization
arm64: vdso: remove aarch32_vdso_pages[]
arm64: vdso: simplify arch_vdso_type ifdeffery
arm64: vdso: use consistent 'abi' nomenclature
arm64: vdso: use consistent 'map' nomenclature
Rob Herring (1):
arm64: silicon-errata.rst: Sort the Cortex-A55 entries
Sai Prakash Ranjan (1):
arm64: cpufeature: Relax check for IESB support
Sami Tolvanen (12):
scs: Add support for Clang's Shadow Call Stack (SCS)
scs: Add page accounting for shadow call stack allocations
scs: Add support for stack usage debugging
scs: Disable when function graph tracing is enabled
arm64: Reserve register x18 from general allocation with SCS
arm64: Preserve register x18 when CPU is suspended
arm64: efi: Restore register x18 if it was corrupted
arm64: vdso: Disable Shadow Call Stack
arm64: Disable SCS for hypervisor code
arm64: Implement Shadow Call Stack
arm64: scs: Add shadow stacks for SDEI
efi/libstub: Disable Shadow Call Stack
Shaokun Zhang (1):
drivers/perf: hisi: Fix typo in events attribute array
Sudeep Holla (8):
firmware: arm_sdei: Drop check for /firmware/ node and always register driver
firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and above
firmware: smccc: Update link to latest SMCCC specification
firmware: smccc: Add the definition for SMCCCv1.2 version/error codes
firmware: smccc: Drop smccc_version enum and use ARM_SMCCC_VERSION_1_x instead
firmware: smccc: Refactor SMCCC specific bits into separate file
firmware: smccc: Add function to fetch SMCCC version
firmware: smccc: Fix missing prototype warning for arm_smccc_version_init
Tang Bin (2):
drivers/perf: arm_dsu_pmu: Avoid duplicate printouts
drivers/perf: arm_spe_pmu: Avoid duplicate printouts
Tuan Phan (1):
ACPI/IORT: Fix PMCG node single ID mapping handling
Vincenzo Frascino (2):
arm64: vdso: Add '-Bsymbolic' to ldflags
arm64: vdso: Add --eh-frame-hdr to ldflags
Will Deacon (28):
arm64: elf: Fix allnoconfig kernel build with !ARCH_USE_GNU_PROPERTY
arm64: cpufeature: Spell out register fields for ID_ISAR4 and ID_PFR1
arm64: cpufeature: Add CPU capability for AArch32 EL1 support
arm64: cpufeature: Remove redundant call to id_aa64pfr0_32bit_el0()
arm64: cpufeature: Factor out checking of AArch32 features
arm64: cpufeature: Relax AArch32 system checks if EL1 is 64-bit only
arm64: cpufeature: Relax checks for AArch32 support at EL[0-2]
arm64: cpufeature: Add an overview comment for the cpufeature framework
arm64: docs: Mandate that the I-cache doesn't hold stale kernel text
Merge branch 'x86/asm' of git://git.kernel.org/.../tip/tip into for-next/asm
arm64: cpufeature: Extend comment to describe absence of field info
arm64: cpufeature: Group indexed system register definitions by name
Merge branch 'for-next/bti-user' into for-next/bti
Merge branches 'for-next/asm' and 'for-next/insn' into for-next/bti
arm64: kconfig: Update and comment GCC version check for kernel BTI
arm64: scs: Store absolute SCS stack pointer value in thread_info
scs: Move accounting into alloc/free functions
arm64: scs: Use 'scs_sp' register alias for x18
scs: Move scs_overflow_check() out of architecture code
scs: Remove references to asm/scs.h from core code
scs: Move DEFINE_SCS macro into core code
arm64: entry-ftrace.S: Update comment to indicate that x18 is live
arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction
arm64: vdso: Fix CFI directives in sigreturn trampoline
Merge branches 'for-next/acpi', 'for-next/bpf', 'for-next/cpufeature', 'for-next/docs', 'for-next/kconfig', 'for-next/misc', 'for-next/perf', 'for-next/ptr-auth', 'for-next/sdei', 'for-next/smccc' and 'for-next/vdso' into for-next/core
Merge branch 'for-next/bti' into for-next/core
Merge branch 'for-next/kvm/errata' into for-next/core
Merge branch 'for-next/scs' into for-next/core
Yunfeng Ye (1):
arm64: stacktrace: Factor out some common code into on_stack()
Zenghui Yu (2):
KVM: arm64: Drop PTE_S2_MEMATTR_MASK
ACPI/IORT: Remove the unused __get_pci_rid()
Zhou Wang (1):
drivers/perf: hisi: Permit modular builds of HiSilicon uncore drivers
Zou Wei (1):
arm64: smp: Make cpus_stuck_in_kernel static
Łukasz Stelmach (1):
arm64: kexec_file: print appropriate variable
Documentation/admin-guide/kdump/vmcoreinfo.rst | 6 +
Documentation/arm64/booting.rst | 3 +-
Documentation/arm64/cpu-feature-registers.rst | 2 +
Documentation/arm64/elf_hwcaps.rst | 5 +
Documentation/arm64/silicon-errata.rst | 8 +-
Documentation/filesystems/proc.rst | 1 +
MAINTAINERS | 9 +
Makefile | 6 +
arch/Kconfig | 25 ++
arch/arm64/Kconfig | 162 +++++---
arch/arm64/Makefile | 16 +-
arch/arm64/include/asm/asm_pointer_auth.h | 43 +-
arch/arm64/include/asm/assembler.h | 50 +++
arch/arm64/include/asm/cacheflush.h | 6 +-
arch/arm64/include/asm/compiler.h | 4 -
arch/arm64/include/asm/cpu.h | 4 +
arch/arm64/include/asm/cpucaps.h | 17 +-
arch/arm64/include/asm/cpufeature.h | 30 ++
arch/arm64/include/asm/debug-monitors.h | 2 +
arch/arm64/include/asm/elf.h | 50 +++
arch/arm64/include/asm/esr.h | 2 +-
arch/arm64/include/asm/exception.h | 1 +
arch/arm64/include/asm/hwcap.h | 1 +
arch/arm64/include/asm/insn.h | 30 +-
arch/arm64/include/asm/kvm_emulate.h | 6 +-
arch/arm64/include/asm/kvm_host.h | 6 +-
arch/arm64/include/asm/kvm_hyp.h | 20 +-
arch/arm64/include/asm/kvm_mmu.h | 19 +-
arch/arm64/include/asm/linkage.h | 46 +++
arch/arm64/include/asm/mman.h | 37 ++
arch/arm64/include/asm/pgtable-hwdef.h | 2 +-
arch/arm64/include/asm/pgtable-prot.h | 11 +
arch/arm64/include/asm/pgtable.h | 9 +-
arch/arm64/include/asm/ptrace.h | 1 +
arch/arm64/include/asm/scs.h | 29 ++
arch/arm64/include/asm/smp.h | 11 -
arch/arm64/include/asm/stacktrace.h | 40 +-
arch/arm64/include/asm/suspend.h | 2 +-
arch/arm64/include/asm/sysreg.h | 77 +++-
arch/arm64/include/asm/thread_info.h | 13 +
arch/arm64/include/uapi/asm/hwcap.h | 1 +
arch/arm64/include/uapi/asm/mman.h | 9 +
arch/arm64/include/uapi/asm/ptrace.h | 9 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/asm-offsets.c | 7 +-
arch/arm64/kernel/cpu-reset.S | 4 +-
arch/arm64/kernel/cpu_errata.c | 29 +-
arch/arm64/kernel/cpufeature.c | 455 +++++++++++++++++----
arch/arm64/kernel/cpuinfo.c | 9 +-
arch/arm64/kernel/crash_core.c | 4 +
arch/arm64/kernel/debug-monitors.c | 4 +-
arch/arm64/kernel/efi-entry.S | 2 +-
arch/arm64/kernel/efi-header.S | 2 +-
arch/arm64/kernel/efi-rt-wrapper.S | 15 +-
arch/arm64/kernel/entry-common.c | 13 +-
arch/arm64/kernel/entry-fpsimd.S | 20 +-
arch/arm64/kernel/entry-ftrace.S | 5 +-
arch/arm64/kernel/entry.S | 69 +++-
arch/arm64/kernel/head.S | 49 ++-
arch/arm64/kernel/hibernate-asm.S | 16 +-
arch/arm64/kernel/hyp-stub.S | 20 +-
arch/arm64/kernel/image-vars.h | 2 +-
arch/arm64/kernel/insn.c | 46 ++-
arch/arm64/kernel/machine_kexec_file.c | 14 +-
arch/arm64/kernel/paravirt.c | 2 +-
arch/arm64/kernel/probes/decode-insn.c | 2 +-
arch/arm64/kernel/probes/kprobes_trampoline.S | 4 +-
arch/arm64/kernel/process.c | 41 +-
arch/arm64/kernel/ptrace.c | 2 +-
arch/arm64/kernel/reloc_test_syms.S | 44 +-
arch/arm64/kernel/relocate_kernel.S | 4 +-
arch/arm64/kernel/scs.c | 16 +
arch/arm64/kernel/sdei.c | 28 +-
arch/arm64/kernel/signal.c | 16 +
arch/arm64/kernel/sleep.S | 13 +-
arch/arm64/kernel/smccc-call.S | 8 +-
arch/arm64/kernel/smp.c | 10 +-
arch/arm64/kernel/syscall.c | 18 +
arch/arm64/kernel/traps.c | 133 +++---
arch/arm64/kernel/vdso.c | 155 ++++---
arch/arm64/kernel/vdso/Makefile | 12 +-
arch/arm64/kernel/vdso/note.S | 3 +
arch/arm64/kernel/vdso/sigreturn.S | 54 ++-
arch/arm64/kernel/vdso/vdso.S | 3 +
arch/arm64/kernel/vdso32/sigreturn.S | 19 +-
arch/arm64/kernel/vmlinux.lds.S | 18 +-
arch/arm64/kvm/hyp/switch.c | 6 +-
arch/arm64/kvm/hyp/sysreg-sr.c | 6 +-
arch/arm64/kvm/hyp/tlb.c | 11 +-
arch/arm64/kvm/reset.c | 65 ++-
arch/arm64/kvm/sys_regs.c | 6 +-
arch/arm64/lib/copy_from_user.S | 32 +-
arch/arm64/lib/copy_in_user.S | 32 +-
arch/arm64/lib/copy_to_user.S | 32 +-
arch/arm64/lib/crc32.S | 2 +-
arch/arm64/lib/memcpy.S | 32 +-
arch/arm64/mm/context.c | 8 +-
arch/arm64/mm/dump.c | 5 +
arch/arm64/mm/init.c | 2 +-
arch/arm64/mm/mmu.c | 24 ++
arch/arm64/mm/pageattr.c | 4 +-
arch/arm64/mm/proc.S | 60 +--
arch/arm64/net/bpf_jit.h | 30 ++
arch/arm64/net/bpf_jit_comp.c | 85 +++-
arch/x86/Kconfig | 1 +
arch/x86/Kconfig.debug | 9 -
arch/x86/entry/entry_32.S | 2 -
arch/x86/include/asm/doublefault.h | 2 +-
arch/x86/include/asm/traps.h | 2 -
arch/x86/kernel/Makefile | 4 +-
arch/x86/kernel/dumpstack_32.c | 4 -
arch/x86/kernel/traps.c | 2 -
arch/x86/mm/cpu_entry_area.c | 4 +-
drivers/acpi/arm64/gtdt.c | 4 +-
drivers/acpi/arm64/iort.c | 126 +++---
drivers/base/node.c | 6 +
drivers/firmware/Kconfig | 6 +-
drivers/firmware/Makefile | 3 +-
drivers/firmware/arm_sdei.c | 49 +--
drivers/firmware/efi/libstub/Makefile | 3 +
drivers/firmware/psci/psci.c | 21 +-
drivers/firmware/smccc/Kconfig | 16 +
drivers/firmware/smccc/Makefile | 3 +
drivers/firmware/smccc/smccc.c | 31 ++
drivers/perf/Kconfig | 9 +-
drivers/perf/arm_dsu_pmu.c | 4 +-
drivers/perf/arm_smmuv3_pmu.c | 5 +-
drivers/perf/arm_spe_pmu.c | 4 +-
drivers/perf/hisilicon/Kconfig | 7 +
drivers/perf/hisilicon/Makefile | 3 +-
drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 10 +-
drivers/perf/hisilicon/hisi_uncore_hha_pmu.c | 12 +-
drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c | 10 +-
drivers/perf/hisilicon/hisi_uncore_pmu.c | 23 +-
fs/Kconfig.binfmt | 6 +
fs/binfmt_elf.c | 145 ++++++-
fs/compat_binfmt_elf.c | 4 +
fs/proc/meminfo.c | 4 +
fs/proc/task_mmu.c | 3 +
include/linux/arm-smccc.h | 25 +-
include/linux/compiler-clang.h | 4 +
include/linux/compiler_types.h | 4 +
include/linux/elf.h | 43 ++
include/linux/linkage.h | 8 +-
include/linux/mm.h | 3 +
include/linux/mmzone.h | 3 +
include/linux/psci.h | 7 -
include/linux/scs.h | 72 ++++
include/uapi/linux/elf.h | 11 +
init/init_task.c | 8 +
kernel/Makefile | 1 +
kernel/fork.c | 9 +
kernel/sched/core.c | 5 +
kernel/scs.c | 104 +++++
lib/Kconfig | 3 +
mm/page_alloc.c | 6 +
mm/vmstat.c | 3 +
.../testing/selftests/wireguard/qemu/debug.config | 1 -
virt/kvm/arm/arm.c | 4 +-
159 files changed, 2559 insertions(+), 976 deletions(-)
create mode 100644 arch/arm64/include/asm/mman.h
create mode 100644 arch/arm64/include/asm/scs.h
create mode 100644 arch/arm64/include/uapi/asm/mman.h
create mode 100644 arch/arm64/kernel/scs.c
create mode 100644 drivers/firmware/smccc/Kconfig
create mode 100644 drivers/firmware/smccc/Makefile
create mode 100644 drivers/firmware/smccc/smccc.c
create mode 100644 drivers/perf/hisilicon/Kconfig
create mode 100644 include/linux/scs.h
create mode 100644 kernel/scs.c
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] coresight: tmc: Add enable flag to indicate the status of ETR/ETF
From: Sai Prakash Ranjan @ 2020-06-01 17:13 UTC (permalink / raw)
To: Mike Leach
Cc: Mathieu Poirier, Suzuki K Poulose, linux-arm-msm, Coresight ML,
Linux Kernel Mailing List, Stephen Boyd, linux-arm-kernel
In-Reply-To: <CAJ9a7Vh=GPKdYcX3aiJfaAVQ3j8rEmoSvP0CDeF-mfPpV4DMaw@mail.gmail.com>
Hi Mike,
Thanks for the review.
On 2020-06-01 18:57, Mike Leach wrote:
> Hi,
>
> On Mon, 1 Jun 2020 at 09:02, Sai Prakash Ranjan
> <saiprakash.ranjan@codeaurora.org> wrote:
>>
>> Add a flag to check whether TMC ETR/ETF is enabled or not.
>> This is later used in shutdown callback to determine if
>> we require to disable ETR/ETF.
>>
>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> ---
>> drivers/hwtracing/coresight/coresight-tmc.c | 2 ++
>> drivers/hwtracing/coresight/coresight-tmc.h | 2 ++
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c
>> b/drivers/hwtracing/coresight/coresight-tmc.c
>> index 39fba1d16e6e..5a271ebc4585 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
>> @@ -62,11 +62,13 @@ void tmc_flush_and_stop(struct tmc_drvdata
>> *drvdata)
>>
>> void tmc_enable_hw(struct tmc_drvdata *drvdata)
>> {
>> + drvdata->enable = true;
>> writel_relaxed(TMC_CTL_CAPT_EN, drvdata->base + TMC_CTL);
>> }
>>
>> void tmc_disable_hw(struct tmc_drvdata *drvdata)
>> {
>> + drvdata->enable = false;
>> writel_relaxed(0x0, drvdata->base + TMC_CTL);
>> }
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h
>> b/drivers/hwtracing/coresight/coresight-tmc.h
>> index 71de978575f3..d156860495c7 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc.h
>> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
>> @@ -184,6 +184,7 @@ struct etr_buf {
>> * @idr_mutex: Access serialisation for idr.
>> * @sysfs_buf: SYSFS buffer for ETR.
>> * @perf_buf: PERF buffer for ETR.
>> + * @enable: Indicates whether ETR/ETF is enabled.
>> */
>> struct tmc_drvdata {
>> void __iomem *base;
>> @@ -207,6 +208,7 @@ struct tmc_drvdata {
>> struct mutex idr_mutex;
>> struct etr_buf *sysfs_buf;
>> struct etr_buf *perf_buf;
>> + bool enable;
>
> Is this flag needed?
> For TMC, drvdata->mode indicates if the device is in use.
>
Yes we can use mode flag, will make this change in the next version.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] arm: decompressor: set malloc pool size for the decompressor
From: Lukasz Stelmach @ 2020-06-01 16:54 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20200601151031.GM1551@shell.armlinux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 2817 bytes --]
It was <2020-06-01 pon 16:10>, when Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 04:56:40PM +0200, Lukasz Stelmach wrote:
>> It was <2020-06-01 pon 15:46>, when Russell King - ARM Linux admin wrote:
>> > On Mon, Jun 01, 2020 at 04:27:50PM +0200, Łukasz Stelmach wrote:
>> >> Move the definition of malloc pool size of the decompressor to
>> >> a single place. This value will be exposed later for kexec_file loader.
>> >>
>> >> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>> >> ---
>> >> arch/arm/boot/compressed/Makefile | 2 ++
>> >> arch/arm/boot/compressed/head.S | 6 ++++--
>> >> 2 files changed, 6 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
>> >> index 9c11e7490292..b3594cd1588c 100644
>> >> --- a/arch/arm/boot/compressed/Makefile
>> >> +++ b/arch/arm/boot/compressed/Makefile
>> >> @@ -125,6 +125,8 @@ KBSS_SZ = $(shell echo $$(($$($(NM) $(obj)/../../../../vmlinux | \
>> >> sed -n -e 's/^\([^ ]*\) [AB] __bss_start$$/-0x\1/p' \
>> >> -e 's/^\([^ ]*\) [AB] __bss_stop$$/+0x\1/p') )) )
>> >> LDFLAGS_vmlinux = --defsym _kernel_bss_size=$(KBSS_SZ)
>> >> +# malloc pool size
>> >> +LDFLAGS_vmlinux += --defsym _malloc_size=0x10000
>> >> # Supply ZRELADDR to the decompressor via a linker symbol.
>> >> ifneq ($(CONFIG_AUTO_ZRELADDR),y)
>> >> LDFLAGS_vmlinux += --defsym zreladdr=$(ZRELADDR)
>> >> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> >> index e8e1c866e413..dcc1afa60fb9 100644
>> >> --- a/arch/arm/boot/compressed/head.S
>> >> +++ b/arch/arm/boot/compressed/head.S
>> >> @@ -309,7 +309,8 @@ restart: adr r0, LC0
>> >> #ifndef CONFIG_ZBOOT_ROM
>> >> /* malloc space is above the relocated stack (64k max) */
>> >> add sp, sp, r0
>> >> - add r10, sp, #0x10000
>> >> + ldr r10, =_malloc_size
>> >> + add r10, r10, sp
>> >
>> > This says "locate _malloc_size in a literal pool somewhere, and load it
>> > using a PC-relative offset". Are you sure that the literal pool is
>> > sensibly located?
>> >
>> > Would it be better to use a definition for this?
>>
>> I've followed ZRELADDR way. I think both values should be handled the
>> same way (it makes it easier to comprehend IMHO). Is there any reason
>> not to? Should I change ZRELADDR for v2 too?
>
> There's a good reason. ZRELADDR can be a constant that does not fit
> into the ARMs immediate constants (8 bits of significant data plus
> a multiple of a 2-bit shift), whereas the size of the malloc space
> is guaranteed to fit. So, ZRELADDR has to use a literal load.
> This doesn't.
Indeed this is how TEXT_OFFSET works. Done.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5 v2] KASan for ARM
From: Florian Fainelli @ 2020-06-01 16:51 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Abbott Liu, Linus Walleij, Russell King, Linux ARM,
Andrey Ryabinin
In-Reply-To: <CAMj1kXGNSogYOBxZfoTq2uMtY-piZ3PePFVCs3-R5nBEvnx-Rg@mail.gmail.com>
On 6/1/2020 9:40 AM, Ard Biesheuvel wrote:
> On Mon, 1 Jun 2020 at 18:37, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>>
>>
>> On 6/1/2020 1:55 AM, Linus Walleij wrote:
>>> On Mon, Jun 1, 2020 at 6:00 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>
>>>> Since this patch series has had many people trying to push it forward,
>>>> how about we try to get it merged as-is (minus bugs, see below) with the
>>>> caveat that TTRB0-less CPUs are not going to be supported for now and
>>>> later on, this gets lifted if we find a champion who can get that working?
>>>
>>> Oh I fixed most issues in the v9 patch set, we ironed out the actual problem
>>> with ARMv4 and ARMv5 with some help from Ard, Catalin and then Russell
>>> suggested how to also improve the way we get taskinfo from sp in the
>>> assembly.
>>>
>>>> I tested this on an ARMv8 system (Brahma-B53 CPU) and an ARMv7-A system
>>>> (Brahma-B15 CPU) with and without ARM_LPAE enabled and neither were able
>>>> to boot unless KASAN was turned off (outline instrumentation), I don't
>>>> even get to the point where earlyprintk is giving me anything which is
>>>> odd. Have not looked at the differences between this version and the one
>>>> I had sent before and have not hooked a debugger to find out where we
>>>> are hung.
>>>>
>>>> If you have a Raspberry Pi 4 you could use it as a test system for ARM_LPAE.
>>>
>>> Did you try to use the v9 patch set on top of v5.7:
>>> https://lore.kernel.org/linux-arm-kernel/20200515114028.135674-1-linus.walleij@linaro.org/
>>>
>>> I need to rebase this on v5.8-rc1 once it is out but it is working on all my
>>> targets now, there is also this git branch:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
>>
>> This branch got me a bit further, but still failed to fully initialize
>> (see attached kasan.log), on another platform with a slightly different
>> memory map, I ended up getting a different error (kasan2.log).
>
> How can you be sure kasan2.log did not detect an actual bug?
I should have been clearer, my email was just sent out unfiltered to
report the status on Linus' branch, kasan2.log may be showing up a
genuine bug indeed.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/5] arm: kexec_file: load zImage or uImage, initrd and dtb
From: Lukasz Stelmach @ 2020-06-01 16:46 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20200601151431.GN1551@shell.armlinux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1089 bytes --]
It was <2020-06-01 pon 16:14>, when Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 04:07:45PM +0100, Russell King - ARM Linux admin wrote:
>> On Mon, Jun 01, 2020 at 04:27:54PM +0200, Łukasz Stelmach wrote:
>> > diff --git a/arch/arm/kernel/kexec_zimage.c b/arch/arm/kernel/kexec_zimage.c
>> > new file mode 100644
>> > index 000000000000..d09795fc9072
>> > --- /dev/null
>> > +++ b/arch/arm/kernel/kexec_zimage.c
>> > @@ -0,0 +1,199 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/*
>> > + * Kexec zImage loader
>> > + *
>> > + * Copyright (C) 2020 Samsung Electronics
>> > + * Author: Łukasz Stelmach <l.stelmach@samsung.com>
>>
>> Please credit me as part author of this - you have taken some of my
>> code from the userspace kexec tool (such as the contents of
>> find_extension_tag()) and copied it in here, so this is not all your
>> own work.
>
> It would also be a very good idea to indicate _where_ you copied some
> of this code from.
Sure thing. Done.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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