* Re: next/master boot: 265 boots: 17 failed, 184 passed with 64 offline (next-20190730)
From: Timur Tabi @ 2019-08-01 3:49 UTC (permalink / raw)
To: Jeffrey Hugo, Stephen Boyd, Lee Jones, Linus Walleij, Mark Brown
Cc: Bjorn Andersson, Lina Iyer, Linux ARM,
Kernel Build Reports Mailman List
In-Reply-To: <cbbe381e-a154-ced1-fbcb-9db2135e4e5b@codeaurora.org>
On 7/31/19 12:58 PM, Jeffrey Hugo wrote:
>>>
>>> Timur/Stephen: any ideas?
>
> Timur's CAF account is no longer valid, I added his @kernel one.
Delete everything specific to the QDF2400.
Qualcomm has made it very clear that they have no interest in developing
ARM server chips. No QDF2400 system ever made it to official production.
_______________________________________________
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 net-next v2 2/4] net: phy: Add mdio-aspeed
From: Andrew Lunn @ 2019-08-01 3:53 UTC (permalink / raw)
To: Andrew Jeffery
Cc: mark.rutland, devicetree, f.fainelli, linux-aspeed, netdev,
linux-kernel, robh+dt, joel, davem, linux-arm-kernel, hkallweit1
In-Reply-To: <20190731053959.16293-3-andrew@aj.id.au>
On Wed, Jul 31, 2019 at 03:09:57PM +0930, Andrew Jeffery wrote:
> The AST2600 design separates the MDIO controllers from the MAC, which is
> where they were placed in the AST2400 and AST2500. Further, the register
> interface is reworked again, so now we have three possible different
> interface implementations, however this driver only supports the
> interface provided by the AST2600. The AST2400 and AST2500 will continue
> to be supported by the MDIO support embedded in the FTGMAC100 driver.
>
> The hardware supports both C22 and C45 mode, but for the moment only C22
> support is implemented.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
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 net-next v2 3/4] net: ftgmac100: Add support for DT phy-handle property
From: Andrew Lunn @ 2019-08-01 3:55 UTC (permalink / raw)
To: Andrew Jeffery
Cc: mark.rutland, devicetree, f.fainelli, linux-aspeed, netdev,
linux-kernel, robh+dt, joel, davem, linux-arm-kernel, hkallweit1
In-Reply-To: <20190731053959.16293-4-andrew@aj.id.au>
On Wed, Jul 31, 2019 at 03:09:58PM +0930, Andrew Jeffery wrote:
> phy-handle is necessary for the AST2600 which separates the MDIO
> controllers from the MAC.
>
> I've tried to minimise the intrusion of supporting the AST2600 to the
> FTGMAC100 by leaving in place the existing MDIO support for the embedded
> MDIO interface. The AST2400 and AST2500 continue to be supported this
> way, as it avoids breaking/reworking existing devicetrees.
>
> The AST2600 support by contrast requires the presence of the phy-handle
> property in the MAC devicetree node to specify the appropriate PHY to
> associate with the MAC. In the event that someone wants to specify the
> MDIO bus topology under the MAC node on an AST2400 or AST2500, the
> current auto-probe approach is done conditional on the absence of an
> "mdio" child node of the MAC.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
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 net-next v2 4/4] net: ftgmac100: Select ASPEED MDIO driver for the AST2600
From: Andrew Lunn @ 2019-08-01 3:56 UTC (permalink / raw)
To: Andrew Jeffery
Cc: mark.rutland, devicetree, f.fainelli, linux-aspeed, netdev,
linux-kernel, robh+dt, joel, davem, linux-arm-kernel, hkallweit1
In-Reply-To: <20190731053959.16293-5-andrew@aj.id.au>
On Wed, Jul 31, 2019 at 03:09:59PM +0930, Andrew Jeffery wrote:
> Ensures we can talk to a PHY via MDIO on the AST2600, as the MDIO
> controller is now separate from the MAC.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
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 2/2] net: gmii2rgmii: Switch priv field in mdio device structure
From: Andrew Lunn @ 2019-08-01 4:06 UTC (permalink / raw)
To: Harini Katakam
Cc: f.fainelli, netdev, radhey.shyam.pandey, michal.simek,
harinikatakamlinux, linux-kernel, davem, linux-arm-kernel,
hkallweit1
In-Reply-To: <1564565779-29537-3-git-send-email-harini.katakam@xilinx.com>
On Wed, Jul 31, 2019 at 03:06:19PM +0530, Harini Katakam wrote:
> Use the priv field in mdio device structure instead of the one in
> phy device structure. The phy device priv field may be used by the
> external phy driver and should not be overwritten.
Hi Harini
I _think_ you could use dev_set_drvdata(&mdiodev->dev) in xgmiitorgmii_probe() and
dev_get_drvdata(&phydev->mdiomdio.dev) in _read_status()
Andrew
_______________________________________________
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 v4.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context
From: Viresh Kumar @ 2019-08-01 5:09 UTC (permalink / raw)
To: Julien Thierry
Cc: Mark Rutland, Marc Zyngier, Catalin Marinas, Will Deacon, stable,
mark.brown, julien.thierry.kdev, Russell King, linux-arm-kernel
In-Reply-To: <59b252cf-9cb7-128b-4887-c21a8b9b92a9@arm.com>
On 31-07-19, 14:09, Julien Thierry wrote:
>
>
> On 12/07/2019 06:28, Viresh Kumar wrote:
> > From: Marc Zyngier <marc.zyngier@arm.com>
> >
> > commit a8e4c0a919ae310944ed2c9ace11cf3ccd8a609b upstream.
> >
> > We call arm64_apply_bp_hardening() from post_ttbr_update_workaround,
> > which has the unexpected consequence of being triggered on every
> > exception return to userspace when ARM64_SW_TTBR0_PAN is selected,
> > even if no context switch actually occured.
> >
> > This is a bit suboptimal, and it would be more logical to only
> > invalidate the branch predictor when we actually switch to
> > a different mm.
> >
> > In order to solve this, move the call to arm64_apply_bp_hardening()
> > into check_and_switch_context(), where we're guaranteed to pick
> > a different mm context.
> >
> > Acked-by: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> > arch/arm64/mm/context.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
> > index be42bd3dca5c..de5afc27b4e6 100644
> > --- a/arch/arm64/mm/context.c
> > +++ b/arch/arm64/mm/context.c
> > @@ -183,6 +183,8 @@ void check_and_switch_context(struct mm_struct *mm, unsigned int cpu)
> > raw_spin_unlock_irqrestore(&cpu_asid_lock, flags);
> >
> > switch_mm_fastpath:
> > + arm64_apply_bp_hardening();
> > +
> > cpu_switch_mm(mm->pgd, mm);
> > }
> >
> > @@ -193,8 +195,6 @@ asmlinkage void post_ttbr_update_workaround(void)
> > "ic iallu; dsb nsh; isb",
> > ARM64_WORKAROUND_CAVIUM_27456,
> > CONFIG_CAVIUM_ERRATUM_27456));
> > -
> > - arm64_apply_bp_hardening();
>
> Patches 22 and 23 factorize the post_ttbr_update_workaround() and move
> it to C code just so we would and a call to arm64_apply_bp_hardening()
> in patch 24 that now gets moved elsewhere?
>
> Is it really worth backporting patches 22 and 23?
If I can merge patch 24 and 25 into a single patch while backporting,
then patch 22 and 23 won't be required. I am not sure how should the
commit log look like in that case though :)
Is mentioning both the upstream commit ids along with log of the first
patch (which was more important) enough, like this ?
Author: Will Deacon <will.deacon@arm.com>
Date: Wed Jan 3 11:17:58 2018 +0000
arm64: Add skeleton to harden the branch predictor against aliasing attacks
commit 0f15adbb2861ce6f75ccfc5a92b19eae0ef327d0 upstream.
commit a8e4c0a919ae310944ed2c9ace11cf3ccd8a609b upstream.
Aliasing attacks against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.
This patch adds initial skeleton code behind a new Kconfig option to
enable implementation-specific mitigations against these attacks for
CPUs that are affected.
Co-developed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ v4.4: Changes made according to 4.4 codebase ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
_______________________________________________
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 v4.4 V2 24/43] arm64: Add skeleton to harden the branch predictor against aliasing attacks
From: Viresh Kumar @ 2019-08-01 5:20 UTC (permalink / raw)
To: Mark Rutland
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <20190731164556.GI39768@lakrids.cambridge.arm.com>
On 31-07-19, 17:45, Mark Rutland wrote:
> On Fri, Jul 12, 2019 at 10:58:12AM +0530, Viresh Kumar wrote:
> > From: Will Deacon <will.deacon@arm.com>
> >
> > commit 0f15adbb2861ce6f75ccfc5a92b19eae0ef327d0 upstream.
> >
> > Aliasing attacks against CPU branch predictors can allow an attacker to
> > redirect speculative control flow on some CPUs and potentially divulge
> > information from one context to another.
> >
> > This patch adds initial skeleton code behind a new Kconfig option to
> > enable implementation-specific mitigations against these attacks for
> > CPUs that are affected.
> >
> > Co-developed-by: Marc Zyngier <marc.zyngier@arm.com>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > [ v4.4: Changes made according to 4.4 codebase ]
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> [...]
>
> > /* id_aa64pfr0 */
> > +#define ID_AA64PFR0_CSV2_SHIFT 56
>
> Note: CSV3 is bits 63-60,
>
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 474b34243521..040a42d79990 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -83,7 +83,8 @@ static struct arm64_ftr_bits ftr_id_aa64isar0[] = {
> > };
> >
> > static struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
> > - ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 32, 32, 0),
> > + ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV2_SHIFT, 4, 0),
> > + ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 32, 28, 0),
>
> This line should be:
>
> ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 32, 24, 0),
>
> ... as it was in the v4.9 backbort, making it cover bits 55:32. As in
> this patch, it covers 59:32, overlapping with CSV2.
Fixed thanks.
> We also need to cater for bits 63:60. In the v4.9 backport, the meltdown
> bits were applied first, so nothing special was necessary.
>
> What's the plan w.r.t. meltdown mitigations and v4.4?
I haven't started looking at meltdown patches yet and so that will be
done at a later point of time, if at all done by me. I have been asked
to backport both Spectre and Meltdown though to 4.4.
--
viresh
_______________________________________________
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 V4 1/2] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-01 5:25 UTC (permalink / raw)
To: Robin Murphy, will@kernel.org, mark.rutland@arm.com, Frank Li
Cc: kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org,
dl-linux-imx
In-Reply-To: <ad9491ed-24c5-8553-94be-cc96479adaf6@arm.com>
> -----Original Message-----
> From: Robin Murphy <robin.murphy@arm.com>
> Sent: 2019年7月31日 20:37
> To: Joakim Zhang <qiangqing.zhang@nxp.com>; will@kernel.org;
> mark.rutland@arm.com; Frank Li <frank.li@nxp.com>
> Cc: linux-arm-kernel@lists.infradead.org; kernel@pengutronix.de; dl-linux-imx
> <linux-imx@nxp.com>
> Subject: Re: [PATCH V4 1/2] perf: imx8_ddr_perf: add AXI ID filter support
>
> On 31/07/2019 11:46, Joakim Zhang wrote:
> > AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> > writes with an ARID or AXID matching filter setting. Granularity is at
> > subsystem level. Implementation does not allow filtring between
> > masters within a subsystem. Filter is defined with 2 configuration registers.
> >
> > --AXI_ID defines AxID matching value
> > --AXI_MASKING defines which bits of AxID are meaningful for the
> > matching
> >
> > When non-masked bits are matching corresponding AXI_ID bits then
> > counter is incremented. This filter allows counting read or write
> > access from a subsystem or multiple subsystems.
> >
> > Perf counter is incremented if AxID && AXI_MASKING == AXI_ID &&
> > AXI_MASKING
> >
> > AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance
> counter.
> >
> > Read and write AXI ID filter should write same value to DPCR1 if want
> > to specify at the same time as this filter is shared between counters.
> >
> > e.g.
> > perf stat -a -e imx8_ddr0/axi-id-read,axi_id=0xMMMMDDDD/,imx8_ddr0/
> > axi-id-write,axi_id=0xMMMMDDDD/cmd
> > MMMM: AXI_MASKING
> > DDDD: AXI_ID
> >
> > ChangeLog:
> > V1 -> V2:
> > * add error log if user specifies read/write AXI ID filter at
> > the same time.
> > * of_device_get_match_data() instead of of_match_device(), and
> > remove the check of return value.
> > V2 -> V3:
> > * move the AXI ID check to event_add().
> > * add support for same value of axi_id.
> > V3 -> V4:
> > * move the AXI ID check to event_init().
> >
> > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > ---
> > drivers/perf/fsl_imx8_ddr_perf.c | 58
> ++++++++++++++++++++++++++++++--
> > 1 file changed, 56 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/perf/fsl_imx8_ddr_perf.c
> > b/drivers/perf/fsl_imx8_ddr_perf.c
> > index 63fe21600072..cb90caad6441 100644
> > --- a/drivers/perf/fsl_imx8_ddr_perf.c
> > +++ b/drivers/perf/fsl_imx8_ddr_perf.c
> > @@ -42,9 +42,22 @@
> >
> > static DEFINE_IDA(ddr_ida);
> >
> > +/* DDR Perf hardware feature */
> > +#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter */
> > +
> > +struct fsl_ddr_devtype_data {
> > + unsigned int quirks; /* quirks needed for different DDR Perf core */
> > +};
> > +
> > +static const struct fsl_ddr_devtype_data imx8_devtype_data;
> > +
> > +static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
> > + .quirks = DDR_CAP_AXI_ID_FILTER,
> > +};
> > +
> > static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> > - { .compatible = "fsl,imx8-ddr-pmu",},
> > - { .compatible = "fsl,imx8m-ddr-pmu",},
> > + { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
> > + { .compatible = "fsl,imx8m-ddr-pmu", .data = &imx8m_devtype_data},
> > { /* sentinel */ }
> > };
> >
> > @@ -57,6 +70,8 @@ struct ddr_pmu {
> > struct perf_event *events[NUM_COUNTERS];
> > int active_events;
> > enum cpuhp_state cpuhp_state;
> > + const struct fsl_ddr_devtype_data *devtype_data;
> > + unsigned int axi_id_read, axi_id_write;
>
> Given that there's apparently only one filter, tracking two different IDs seems a
> bit weird. It would be more intuitive to track one value, plus whether it's
> currently valid or not (unless that's easy to infer by just seeing whether any
> read or write events are currently scheduled).
>
> > int irq;
> > int id;
> > };
> > @@ -128,6 +143,8 @@ static struct attribute *ddr_perf_events_attrs[] = {
> > IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
> > IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
> > IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
> > + IMX8_DDR_PMU_EVENT_ATTR(axi-id-read, 0x41),
> > + IMX8_DDR_PMU_EVENT_ATTR(axi-id-write, 0x42),
> > NULL,
> > };
> >
> > @@ -137,9 +154,11 @@ static struct attribute_group
> ddr_perf_events_attr_group = {
> > };
> >
> > PMU_FORMAT_ATTR(event, "config:0-7");
> > +PMU_FORMAT_ATTR(axi_id, "config1:0-31");
> >
> > static struct attribute *ddr_perf_format_attrs[] = {
> > &format_attr_event.attr,
> > + &format_attr_axi_id.attr,
> > NULL,
> > };
> >
> > @@ -195,6 +214,18 @@ static int ddr_perf_event_init(struct perf_event
> *event)
> > struct hw_perf_event *hwc = &event->hw;
> > struct perf_event *sibling;
> >
> > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > + if (event->attr.config == 0x41)
> > + pmu->axi_id_read = event->attr.config1;
> > +
> > + if (event->attr.config == 0x42)
> > + pmu->axi_id_write = event->attr.config1;
> > +
> > + if (pmu->axi_id_read && pmu->axi_id_write &&
> > + (pmu->axi_id_read != pmu->axi_id_write))
> > + return -EINVAL;
> > + }
>
> This isn't the correct approach that Mark outlined :(
>
> In event_init, you should validate that any filtering for the given event is
> compatible with any other sibling events in the same group, but you should not
> consider (and should definitely not change) the current state of the PMU at
> that point. This step is about rejecting event configurations which could
> *never* be successfully scheduled (since a group represents a set of events
> which must be scheduled all at the same time).
>
> In event_add, you know the given event/group is sufficiently valid to
> *potentially* be scheduled, given that it has passed the event_init checks, but
> you then need to check that the filtering is compatible with all other events
> *currently* counting on the PMU. If this fails, perf core will try to reschedule
> the current events until the new one is able to run. That's why you need the
> additional step of validating groups beforehand, because otherwise you could
> end up with contradictory scheduling constraints at this point and never make
> progress.
Hi Mark and Robin,
Thanks for all your kindly detailed explanation firstly.
My understanding from your comments, I need to validate the filtering (i.e. config1/axi_id) for *all* events in same group during event_init, right?
But it's so strange for that axi_id is only for axi-id-read and axi-id-write event. We don't need to specify axi_id for any other events when mixed with these two events.
If I can just check the axi-id-read and axi-id-write event during event_add and then pass the axi_id value to the filter register. Don't check the case that user
specify both of them at the same time with different filtering value. Instead of checking it in the driver, I add the doc in Documentation/admin-guide/perf/ directory
to note that axi-id-read and axi-id-write event should be specified separately, or specified at the same time with same axi_id value.
Best Regards,
Joakim Zhang
> > +
> > if (event->attr.type != event->pmu->type)
> > return -ENOENT;
> >
> > @@ -274,6 +305,15 @@ static void ddr_perf_event_start(struct perf_event
> *event, int flags)
> > struct hw_perf_event *hwc = &event->hw;
> > int counter = hwc->idx;
> >
> > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > + if (event->attr.config == 0x41 ||
> > + event->attr.config == 0x42) {
> > + int val = event->attr.config1;
> > +
> > + writel(val, pmu->base + COUNTER_DPCR1);
> > + }
> > + }
> > +
> > local64_set(&hwc->prev_count, 0);
> >
> > ddr_perf_counter_enable(pmu, event->attr.config, counter, true);
> @@
> > -324,6 +364,11 @@ static void ddr_perf_event_del(struct perf_event *event,
> int flags)
> > struct hw_perf_event *hwc = &event->hw;
> > int counter = hwc->idx;
> >
> > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > + pmu->axi_id_read = 0;
> > + pmu->axi_id_write = 0;
> > + }
> > +
> > ddr_perf_event_stop(event, PERF_EF_UPDATE);
> >
> > ddr_perf_free_counter(pmu, counter); @@ -445,6 +490,7 @@ static
> int
> > ddr_perf_offline_cpu(unsigned int cpu, struct hlist_node *node)
> >
> > static int ddr_perf_probe(struct platform_device *pdev)
> > {
> > + const struct fsl_ddr_devtype_data *data;
>
> You don't do anything meaningful with this variable, so you may as well just get
> rid of it.
>
> > struct ddr_pmu *pmu;
> > struct device_node *np;
> > void __iomem *base;
> > @@ -472,6 +518,14 @@ static int ddr_perf_probe(struct platform_device
> *pdev)
> > if (!name)
> > return -ENOMEM;
> >
> > + data = of_device_get_match_data(&pdev->dev);
> > + pmu->devtype_data = data;
> > +
> > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > + pmu->axi_id_read = 0;
> > + pmu->axi_id_write = 0;
>
> You've just kzalloc()ed the structure, so these are already initialised to zero.
>
> Robin.
>
> > + }
> > +
> > pmu->cpu = raw_smp_processor_id();
> > ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
> > DDR_CPUHP_CB_NAME,
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH v4 6/9] ASoC: sun4i-i2s: Add multi-lane functionality
From: Jernej Škrabec @ 2019-08-01 5:31 UTC (permalink / raw)
To: linux-sunxi, maxime.ripard
Cc: Linux-ALSA, Andrea Venturi (pers), Christopher Obbard,
Liam Girdwood, linux-kernel, codekipper, Chen-Yu Tsai, Mark Brown,
linux-arm-kernel
In-Reply-To: <20190731122953.2u3iabd6gkn7jv7k@flea>
Dne sreda, 31. julij 2019 ob 14:29:53 CEST je Maxime Ripard napisal(a):
> On Tue, Jul 30, 2019 at 07:57:10PM +0200, Jernej Škrabec wrote:
> > Dne torek, 04. junij 2019 ob 11:38:44 CEST je Code Kipper napisal(a):
> > > On Tue, 4 Jun 2019 at 11:02, Christopher Obbard <chris@64studio.com>
wrote:
> > > > On Tue, 4 Jun 2019 at 09:43, Code Kipper <codekipper@gmail.com> wrote:
> > > > > On Tue, 4 Jun 2019 at 09:58, Maxime Ripard
> > > > > <maxime.ripard@bootlin.com>
> >
> > wrote:
> > > > > > On Mon, Jun 03, 2019 at 07:47:32PM +0200, codekipper@gmail.com
wrote:
> > > > > > > From: Marcus Cooper <codekipper@gmail.com>
> > > > > > >
> > > > > > > The i2s block supports multi-lane i2s output however this
> > > > > > > functionality
> > > > > > > is only possible in earlier SoCs where the pins are exposed and
> > > > > > > for
> > > > > > > the i2s block used for HDMI audio on the later SoCs.
> > > > > > >
> > > > > > > To enable this functionality, an optional property has been
> > > > > > > added to
> > > > > > > the bindings.
> > > > > > >
> > > > > > > Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> > > > > >
> > > > > > I'd like to have Mark's input on this, but I'm really worried
> > > > > > about
> > > > > > the interaction with the proper TDM support.
> > > > > >
> > > > > > Our fundamental issue is that the controller can have up to 8
> > > > > > channels, but either on 4 lines (instead of 1), or 8 channels on 1
> > > > > > (like proper TDM) (or any combination between the two, but that
> > > > > > should
> > > > > > be pretty rare).
> > > > >
> > > > > I understand...maybe the TDM needs to be extended to support this to
> > > > > consider channel mapping and multiple transfer lines. I was thinking
> > > > > about the later when someone was requesting support on IIRC a while
> > > > > ago, I thought masking might of been a solution. These can wait as
> > > > > the
> > > > > only consumer at the moment is LibreELEC and we can patch it there.
> > > >
> > > > Hi Marcus,
> > > >
> > > > FWIW, the TI McASP driver has support for TDM & (i think?) multiple
> > > > transfer lines which are called serializers.
> > > > Maybe this can help with inspiration?
> > > > see
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
> > > > e/s
> > > > ound/soc/ti/davinci-mcasp.c sample DTS:
> > > >
> > > > &mcasp0 {
> > > >
> > > > #sound-dai-cells = <0>;
> > > > status = "okay";
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <&mcasp0_pins>;
> > > >
> > > > op-mode = <0>;
> > > > tdm-slots = <8>;
> > > > serial-dir = <
> > > >
> > > > 2 0 1 0
> > > > 0 0 0 0
> > > > 0 0 0 0
> > > > 0 0 0 0
> > > > >
> > > > >;
> > > >
> > > > tx-num-evt = <1>;
> > > > rx-num-evt = <1>;
> > > >
> > > > };
> > > >
> > > > Cheers!
> > >
> > > Thanks, this looks good.
> >
> > I would really like to see this issue resolved, because HDMI audio support
> > in mainline Linux for those SoCs is long overdue.
> >
> > However, there is a possibility to still add HDMI audio suport (stereo
> > only) even if this issue is not completely solved. If we agree that
> > configuration of channels would be solved with additional property as
> > Christopher suggested, support for >2 channels can be left for a later
> > time when support for that property would be implemented. Currently,
> > stereo HDMI audio support can be added with a few patches.
> >
> > I think all I2S cores are really the same, no matter if internally
> > connected to HDMI controller or routed to pins, so it would make sense to
> > use same compatible for all of them. It's just that those I2S cores which
> > are routed to pins can use only one lane and >2 channels can be used only
> > in TDM mode of operation, if I understand this correctly.
> >
> > New property would have to be optional, so it's omission would result in
> > same channel configuration as it is already present, to preserve
> > compatibility with old device trees. And this mode is already sufficient
> > for stereo HDMI audio support.
>
> Yeah, it looks like a good plan.
>
> > Side note: HDMI audio with current sun4i-i2s driver has a delay (about a
> > second), supposedly because DW HDMI controller automatically generates CTS
> > value based on I2S clock (auto CTS value generation is enabled per
> > DesignWare recomendation for DW HDMI I2S interface).
>
> Is that a constant delay during the audio playback, or only at startup?
I think it's just at startup, e.g. if you're watching movie, audio is in sync,
it's just that first second or so is silent.
>
> > I2S driver from BSP Linux solves that by having I2S clock output
> > enabled all the time. Should this be flagged with some additional
> > property in DT?
>
> I'd say that if the codec has that requirement, then it should be
> between the codec and the DAI, the DT doesn't really have anything to
> do with this.
Ok, but how to communicate that fact to I2S driver then? BSP driver solves
that by using different compatible, but as I said before, I2S cores are not
really different, so this seems wrong.
Best regards,
Jernej
_______________________________________________
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 v3 3/4] arm64: Make debug exception handlers visible from RCU
From: Masami Hiramatsu @ 2019-08-01 5:32 UTC (permalink / raw)
To: Will Deacon
Cc: Dan Rue, Daniel Diaz, Anders Roxell, Catalin Marinas,
Naresh Kamboju, Will Deacon, linux-kernel, Matt Hart,
Paul E . McKenney, linux-arm-kernel
In-Reply-To: <20190731172602.36hdk3yb3w6uihbu@willie-the-truck>
Hi Will,
On Wed, 31 Jul 2019 18:26:03 +0100
Will Deacon <will@kernel.org> wrote:
> On Thu, Jul 25, 2019 at 05:16:15PM +0900, Masami Hiramatsu wrote:
> > Make debug exceptions visible from RCU so that synchronize_rcu()
> > correctly track the debug exception handler.
> >
> > This also introduces sanity checks for user-mode exceptions as same
> > as x86's ist_enter()/ist_exit().
> >
> > The debug exception can interrupt in idle task. For example, it warns
> > if we put a kprobe on a function called from idle task as below.
> > The warning message showed that the rcu_read_lock() caused this
> > problem. But actually, this means the RCU is lost the context which
> > is already in NMI/IRQ.
> >
> > /sys/kernel/debug/tracing # echo p default_idle_call >> kprobe_events
> > /sys/kernel/debug/tracing # echo 1 > events/kprobes/enable
> > /sys/kernel/debug/tracing # [ 135.122237]
> > [ 135.125035] =============================
> > [ 135.125310] WARNING: suspicious RCU usage
> > [ 135.125581] 5.2.0-08445-g9187c508bdc7 #20 Not tainted
> > [ 135.125904] -----------------------------
> > [ 135.126205] include/linux/rcupdate.h:594 rcu_read_lock() used illegally while idle!
> > [ 135.126839]
> > [ 135.126839] other info that might help us debug this:
> > [ 135.126839]
> > [ 135.127410]
> > [ 135.127410] RCU used illegally from idle CPU!
> > [ 135.127410] rcu_scheduler_active = 2, debug_locks = 1
> > [ 135.128114] RCU used illegally from extended quiescent state!
> > [ 135.128555] 1 lock held by swapper/0/0:
> > [ 135.128944] #0: (____ptrval____) (rcu_read_lock){....}, at: call_break_hook+0x0/0x178
> > [ 135.130499]
> > [ 135.130499] stack backtrace:
> > [ 135.131192] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0-08445-g9187c508bdc7 #20
> > [ 135.131841] Hardware name: linux,dummy-virt (DT)
> > [ 135.132224] Call trace:
> > [ 135.132491] dump_backtrace+0x0/0x140
> > [ 135.132806] show_stack+0x24/0x30
> > [ 135.133133] dump_stack+0xc4/0x10c
> > [ 135.133726] lockdep_rcu_suspicious+0xf8/0x108
> > [ 135.134171] call_break_hook+0x170/0x178
> > [ 135.134486] brk_handler+0x28/0x68
> > [ 135.134792] do_debug_exception+0x90/0x150
> > [ 135.135051] el1_dbg+0x18/0x8c
> > [ 135.135260] default_idle_call+0x0/0x44
> > [ 135.135516] cpu_startup_entry+0x2c/0x30
> > [ 135.135815] rest_init+0x1b0/0x280
> > [ 135.136044] arch_call_rest_init+0x14/0x1c
> > [ 135.136305] start_kernel+0x4d4/0x500
> > [ 135.136597]
> >
> > So make debug exception visible to RCU can fix this warning.
> >
> > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> > Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
> > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> > ---
> > Changes in v3:
> > - Make a comment for debug_exception_enter() clearer.
> > ---
> > arch/arm64/mm/fault.c | 40 ++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 40 insertions(+)
> >
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index 9568c116ac7f..ed6c55c87fdc 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -777,6 +777,42 @@ void __init hook_debug_fault_code(int nr,
> > debug_fault_info[nr].name = name;
> > }
> >
> > +/*
> > + * In debug exception context, we explicitly disable preemption.
>
> Maybe add "despite having interrupts disabled"?
OK, I'll add it.
> > + * This serves two purposes: it makes it much less likely that we would
> > + * accidentally schedule in exception context and it will force a warning
> > + * if we somehow manage to schedule by accident.
> > + */
> > +static void debug_exception_enter(struct pt_regs *regs)
> > +{
> > + if (user_mode(regs)) {
> > + RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> > + } else {
> > + /*
> > + * We might have interrupted pretty much anything. In
> > + * fact, if we're a debug exception, we can even interrupt
> > + * NMI processing. We don't want this code makes in_nmi()
> > + * to return true, but we need to notify RCU.
> > + */
> > + rcu_nmi_enter();
> > + }
> > +
> > + preempt_disable();
>
> If you're addingt new functions for entry/exit, maybe move the
> trace_hardirqs_{on,off}() calls in here too?
OK, let's move it in these functions.
Thank you!
>
> Will
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
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/3] ARM: dts: aspeed: Deprecate g[45]-style compatibles
From: Andrew Jeffery @ 2019-08-01 5:45 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-aspeed, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Rob Herring, Joel Stanley, Lee Jones,
Linux ARM
In-Reply-To: <9d0f2b20-e6f6-419c-a866-c4a0dd92aa63@www.fastmail.com>
On Tue, 30 Jul 2019, at 10:27, Andrew Jeffery wrote:
>
>
> On Tue, 30 Jul 2019, at 07:23, Linus Walleij wrote:
> > On Wed, Jul 24, 2019 at 10:13 AM Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > > It's probably best if we push the three patches all through one tree rather
> > > than fragmenting. Is everyone happy if Joel applies them to the aspeed tree?
> >
> > If you are sure it will not collide with parallell work in the
> > pinctrl tree, yes.
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> >
> > (If it does collide I'd prefer to take the pinctrl patches and fix the
> > conflicts in my tree.)
>
> Fair enough, I don't know the answer so I'll poke around. I don't
> really mind
> where the series goes in, I just want to avoid landing only part of it
> if I split it up.
Okay, it currently conflicts with my cleanup-devicetree-warnings series.
Joel, do you mind if Linus takes this series through the pinctrl tree, given
the fix to the devicetrees is patch 1/3?
Andrew
_______________________________________________
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 01/14] usb: ohci-nxp: enable compile-testing
From: Greg Kroah-Hartman @ 2019-08-01 5:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, linux-watchdog, linux-kernel, Jason Cooper,
David S. Miller, netdev, Gregory Clement, linux-usb, Russell King,
Vladimir Zapolskiy, linux-gpio, soc, Alan Stern, Guenter Roeck,
linux-serial, Sylvain Lemieux, Linus Walleij, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20190731195713.3150463-2-arnd@arndb.de>
On Wed, Jul 31, 2019 at 09:56:43PM +0200, Arnd Bergmann wrote:
> The driver hardcodes a hardware I/O address the way one should
> generally not do, and this prevents both compile-testing, and
> moving the platform to CONFIG_ARCH_MULTIPLATFORM.
>
> Change the code to be independent of the machine headers
> to allow those two. Removing the hardcoded address would
> be hard and is not necessary, so leave that in place for now.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/usb/host/Kconfig | 3 ++-
> drivers/usb/host/ohci-nxp.c | 25 ++++++++++++++++++-------
> 2 files changed, 20 insertions(+), 8 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
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 02/14] usb: udc: lpc32xx: allow compile-testing
From: Greg Kroah-Hartman @ 2019-08-01 5:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Felipe Balbi, linux-watchdog, linux-kernel, Jason Cooper,
Alexandre Belloni, Andrew Lunn, netdev, Gregory Clement,
linux-usb, Russell King, Vladimir Zapolskiy, linux-gpio, soc,
David S. Miller, Alan Stern, Guenter Roeck, linux-serial,
Sylvain Lemieux, Linus Walleij, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20190731195713.3150463-3-arnd@arndb.de>
On Wed, Jul 31, 2019 at 09:56:44PM +0200, Arnd Bergmann wrote:
> The only thing that prevents building this driver on other
> platforms is the mach/hardware.h include, which is not actually
> used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/usb/gadget/udc/Kconfig | 3 ++-
> drivers/usb/gadget/udc/lpc32xx_udc.c | 2 --
> 2 files changed, 2 insertions(+), 3 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
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 04/14] serial: lpc32xx_hs: allow compile-testing
From: Greg Kroah-Hartman @ 2019-08-01 5:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, linux-watchdog, linux-usb, linux-kernel,
Jason Cooper, David S. Miller, netdev, Gregory Clement,
Jiri Slaby, Russell King, Vladimir Zapolskiy, linux-gpio, soc,
Alan Stern, Guenter Roeck, linux-serial, Sylvain Lemieux,
Linus Walleij, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190731195713.3150463-5-arnd@arndb.de>
On Wed, Jul 31, 2019 at 09:56:46PM +0200, Arnd Bergmann wrote:
> The only thing that prevents building this driver on other
> platforms is the mach/hardware.h include, which is not actually
> used here at all, so remove the line and allow CONFIG_COMPILE_TEST.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/tty/serial/Kconfig | 3 ++-
> drivers/tty/serial/lpc32xx_hs.c | 2 --
> 2 files changed, 2 insertions(+), 3 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
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 09/14] serial: lpc32xx: allow compile testing
From: Greg Kroah-Hartman @ 2019-08-01 5:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, linux-watchdog, linux-kernel, Jason Cooper,
David S. Miller, netdev, Gregory Clement, linux-usb, Russell King,
Vladimir Zapolskiy, linux-gpio, soc, Alan Stern, Guenter Roeck,
linux-serial, Sylvain Lemieux, Jiri Slaby, Linus Walleij,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190731195713.3150463-10-arnd@arndb.de>
On Wed, Jul 31, 2019 at 09:56:51PM +0200, Arnd Bergmann wrote:
> The lpc32xx_loopback_set() function in hte lpc32xx_hs driver is the
> one thing that relies on platform header files. Move that into the
> core platform code so we only need a variable declaration for it,
> and enable COMPILE_TEST building.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-lpc32xx/serial.c | 30 ++++++++++++++++++++++++
> drivers/tty/serial/lpc32xx_hs.c | 35 ++++------------------------
> include/linux/soc/nxp/lpc32xx-misc.h | 4 ++++
> 3 files changed, 38 insertions(+), 31 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
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 v9 10/21] mm: Add generic p?d_leaf() macros
From: Anshuman Khandual @ 2019-08-01 6:09 UTC (permalink / raw)
To: Steven Price, Mark Rutland
Cc: Dave Hansen, Arnd Bergmann, Ard Biesheuvel, Peter Zijlstra,
Catalin Marinas, x86, linux-kernel, linux-mm,
Jérôme Glisse, Ingo Molnar, Borislav Petkov,
Andy Lutomirski, H. Peter Anvin, James Morse, Thomas Gleixner,
Will Deacon, Andrew Morton, linux-arm-kernel, Liang, Kan
In-Reply-To: <674bd809-f853-adb0-b1ab-aa4404093083@arm.com>
On 07/29/2019 05:08 PM, Steven Price wrote:
> On 28/07/2019 12:44, Anshuman Khandual wrote:
>>
>>
>> On 07/23/2019 03:11 PM, Mark Rutland wrote:
>>> On Mon, Jul 22, 2019 at 04:41:59PM +0100, Steven Price wrote:
>>>> Exposing the pud/pgd levels of the page tables to walk_page_range() means
>>>> we may come across the exotic large mappings that come with large areas
>>>> of contiguous memory (such as the kernel's linear map).
>>>>
>>>> For architectures that don't provide all p?d_leaf() macros, provide
>>>> generic do nothing default that are suitable where there cannot be leaf
>>>> pages that that level.
>>>>
>>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>>
>>> Not a big deal, but it would probably make sense for this to be patch 1
>>> in the series, given it defines the semantic of p?d_leaf(), and they're
>>> not used until we provide all the architectural implemetnations anyway.
>>
>> Agreed.
>>
>>>
>>> It might also be worth pointing out the reasons for this naming, e.g.
>>> p?d_large() aren't currently generic, and this name minimizes potential
>>> confusion between p?d_{large,huge}().
>>
>> Agreed. But these fallback also need to first check non-availability of large
>> pages. I am not sure whether CONFIG_HUGETLB_PAGE config being clear indicates
>> that conclusively or not. Being a page table leaf entry has a broader meaning
>> than a large page but that is really not the case today. All leaf entries here
>> are large page entries from MMU perspective. This dependency can definitely be
>> removed when there are other types of leaf entries but for now IMHO it feels
>> bit problematic not to directly associate leaf entries with large pages in
>> config restriction while doing exactly the same.
>
> The intention here is that the page walkers are able to walk any type of
> page table entry which the kernel may use. CONFIG_HUGETLB_PAGE only
> controls whether "huge TLB pages" are used by user space processes. It's
> quite possible that option to not be selected but the linear mapping to
> have been mapped using "large pages" (i.e. leaf entries further up the
> tree than normal).
I understand that kernel page table might use large pages where as user space
never enabled HugeTLB. The point to make here was CONFIG_HUGETLB approximately
indicates the presence of large pages though the absence of same does not
conclusively indicate that large pages are really absent on the MMU. Perhaps it
will requires something new like MMU_[LARGE|HUGE]_PAGES.
>
> One of the goals was to avoid tying the new functions to a configuration
> option but instead match the hardware architecture. Of course this isn't
> possible in the most general case (e.g. an architecture may have
> multiple hardware page table formats). But to the extent that other
> functions like p?d_none() work the desire is that p?d_leaf() should also
> work.
It is fair enough to assume that a platform can decide wisely and provide
accurate definition for p?d_leaf() functions. Anyways its okay not to make
this more complex by tying with a new config option which does not exist.
_______________________________________________
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] mailbox: imx: Fix Tx doorbell shutdown path
From: Oleksij Rempel @ 2019-08-01 6:10 UTC (permalink / raw)
To: Daniel Baluta
Cc: aisheng.dong, hongxing.zhu, festevam, s.hauer, jassisinghbrar,
linux-kernel, linux-imx, kernel, shawnguo, linux-arm-kernel
In-Reply-To: <20190731205539.13997-1-daniel.baluta@nxp.com>
Hi Daniel,
your patch is in conflicht with Richard's Zhu <hongxing.zhu@nxp.com>
patch "[PATCH v3] mailbox: imx: add support for imx v1 mu".
Please sync your works.
On Wed, Jul 31, 2019 at 11:55:39PM +0300, Daniel Baluta wrote:
> Tx doorbell is handled by txdb_tasklet and doesn't
> have an associated IRQ.
>
> Anyhow, imx_mu_shutdown ignores this and tries to
> free an IRQ that wasn't requested for Tx DB resulting
> in the following warning:
>
> [ 1.967644] Trying to free already-free IRQ 26
> [ 1.972108] WARNING: CPU: 2 PID: 157 at kernel/irq/manage.c:1708 __free_irq+0xc0/0x358
> [ 1.980024] Modules linked in:
> [ 1.983088] CPU: 2 PID: 157 Comm: kworker/2:1 Tainted: G
> [ 1.993524] Hardware name: Freescale i.MX8QXP MEK (DT)
> [ 1.998668] Workqueue: events deferred_probe_work_func
> [ 2.003812] pstate: 60000085 (nZCv daIf -PAN -UAO)
> [ 2.008607] pc : __free_irq+0xc0/0x358
> [ 2.012364] lr : __free_irq+0xc0/0x358
> [ 2.016111] sp : ffff00001179b7e0
> [ 2.019422] x29: ffff00001179b7e0 x28: 0000000000000018
> [ 2.024736] x27: ffff000011233000 x26: 0000000000000004
> [ 2.030053] x25: 000000000000001a x24: ffff80083bec74d4
> [ 2.035369] x23: 0000000000000000 x22: ffff80083bec7588
> [ 2.040686] x21: ffff80083b1fe8d8 x20: ffff80083bec7400
> [ 2.046003] x19: 0000000000000000 x18: ffffffffffffffff
> [ 2.051320] x17: 0000000000000000 x16: 0000000000000000
> [ 2.056637] x15: ffff0000111296c8 x14: ffff00009179b517
> [ 2.061953] x13: ffff00001179b525 x12: ffff000011142000
> [ 2.067270] x11: ffff000011129f20 x10: ffff0000105da970
> [ 2.072587] x9 : 00000000ffffffd0 x8 : 0000000000000194
> [ 2.077903] x7 : 612065657266206f x6 : ffff0000111e7b09
> [ 2.083220] x5 : 0000000000000003 x4 : 0000000000000000
> [ 2.088537] x3 : 0000000000000000 x2 : 00000000ffffffff
> [ 2.093854] x1 : 28b70f0a2b60a500 x0 : 0000000000000000
> [ 2.099173] Call trace:
> [ 2.101618] __free_irq+0xc0/0x358
> [ 2.105021] free_irq+0x38/0x98
> [ 2.108170] imx_mu_shutdown+0x90/0xb0
> [ 2.111921] mbox_free_channel.part.2+0x24/0xb8
> [ 2.116453] mbox_free_channel+0x18/0x28
>
> This bug is present from the beginning of times.
>
> Cc: Oleksij Rempel <o.rempel@pengutronix.de>
> Fixes: 2bb7005696e2246 ("mailbox: Add support for i.MX messaging unit")
> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
> ---
> drivers/mailbox/imx-mailbox.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> index 9f74dee1a58c..957c10c4e674 100644
> --- a/drivers/mailbox/imx-mailbox.c
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -214,8 +214,10 @@ static void imx_mu_shutdown(struct mbox_chan *chan)
> struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> struct imx_mu_con_priv *cp = chan->con_priv;
>
> - if (cp->type == IMX_MU_TYPE_TXDB)
> + if (cp->type == IMX_MU_TYPE_TXDB) {
> tasklet_kill(&cp->txdb_tasklet);
> + return;
> + }
>
> imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx) |
> IMX_MU_xCR_RIEn(cp->idx) | IMX_MU_xCR_GIEn(cp->idx));
Looks like here is one more bug "from the beginning of times" :)
The imx_mu_xcr_rmw() should disable only one channel depending on the
type of channel.
It should be:
switch (cp->type) {
case IMX_MU_TYPE_TX:
imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx));
break;
case IMX_MU_TYPE_RX:
imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_RIEn(cp->idx));
break;
case IMX_MU_TYPE_RXDB:
imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_GIEn(cp->idx));
break;
default:
break;
}
Right now I'm on vocation and have nothing against, if you'll provide
this fix.
--
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 |
_______________________________________________
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 v9 10/21] mm: Add generic p?d_leaf() macros
From: Anshuman Khandual @ 2019-08-01 6:13 UTC (permalink / raw)
To: Mark Rutland
Cc: x86, Arnd Bergmann, Ard Biesheuvel, Peter Zijlstra,
Catalin Marinas, Dave Hansen, linux-kernel, Steven Price,
linux-mm, Jérôme Glisse, Ingo Molnar, Borislav Petkov,
Andy Lutomirski, H. Peter Anvin, James Morse, Thomas Gleixner,
Will Deacon, Andrew Morton, linux-arm-kernel, Liang, Kan
In-Reply-To: <20190729125013.GA33794@lakrids.cambridge.arm.com>
On 07/29/2019 06:20 PM, Mark Rutland wrote:
> On Sun, Jul 28, 2019 at 05:14:31PM +0530, Anshuman Khandual wrote:
>> On 07/23/2019 03:11 PM, Mark Rutland wrote:
>>> It might also be worth pointing out the reasons for this naming, e.g.
>>> p?d_large() aren't currently generic, and this name minimizes potential
>>> confusion between p?d_{large,huge}().
>>
>> Agreed. But these fallback also need to first check non-availability of large
>> pages.
>
> We're deliberately not making the p?d_large() helpers generic, so this
> shouldn't fall back on those.
I meant non-availability of large page support in the MMU HW not just the
presence of p?d_large() helpers.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 6:21 UTC (permalink / raw)
To: Sumit Garg
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, Jonathan Corbet,
jejb, Ard Biesheuvel, Linux Doc Mailing List, James Morris,
Jarkko Sakkinen, Linux Kernel Mailing List, dhowells,
linux-security-module, keyrings, Mimi Zohar, Casey Schaufler,
linux-integrity, Jens Wiklander, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAFA6WYOEqe1a1DCyVYKA+oZaZ0n5hnjxdubstUnrwdUW1-4xHw@mail.gmail.com>
On Wed, Jul 31, 2019 at 4:58 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> > To clarify a bit further - my thought was to support any type of trust
> > source.
>
> That could be very well accomplished via Trusted Keys abstraction
> framework [1]. A trust source just need to implement following APIs:
>
> struct trusted_key_ops ts_trusted_key_ops = {
> .migratable = 0, /* non-migratable */
> .init = init_ts_trusted,
> .seal = ts_key_seal,
> .unseal = ts_key_unseal,
> .get_random = ts_get_random,
> .cleanup = cleanup_ts_trusted,
> };
Which is basically the same as implementing a new keytype in the
kernel; abstraction is not raised in any considerable manner this way?
I chose the userspace plugin due to this, you can use userspace aids
to provide any type of service. Use the crypto library you desire to
do the magic you want.
> > With the
> > user mode helper in between anyone can easily add their own thing in
> > there.
>
> Isn't actual purpose to have trusted keys is to protect user-space
> from access to kernel keys in plain format? Doesn't user mode helper
> defeat that purpose in one way or another?
Not really. CPU is in the user mode while running the code, but the
code or the secure keydata being is not available to the 'normal'
userspace. It's like microkernel service/driver this way. The usermode
driver is part of the kernel image and it runs on top of a invisible
rootfs.
--
Janne
_______________________________________________
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 v4.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context
From: Julien Thierry @ 2019-08-01 6:30 UTC (permalink / raw)
To: Viresh Kumar
Cc: Mark Rutland, Marc Zyngier, Catalin Marinas, Will Deacon, stable,
mark.brown, julien.thierry.kdev, Russell King, linux-arm-kernel
In-Reply-To: <20190801050940.h65crfawrdifsrgg@vireshk-i7>
On 01/08/2019 06:09, Viresh Kumar wrote:
> On 31-07-19, 14:09, Julien Thierry wrote:
>>
>>
>> On 12/07/2019 06:28, Viresh Kumar wrote:
>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>
>>> commit a8e4c0a919ae310944ed2c9ace11cf3ccd8a609b upstream.
>>>
>>> We call arm64_apply_bp_hardening() from post_ttbr_update_workaround,
>>> which has the unexpected consequence of being triggered on every
>>> exception return to userspace when ARM64_SW_TTBR0_PAN is selected,
>>> even if no context switch actually occured.
>>>
>>> This is a bit suboptimal, and it would be more logical to only
>>> invalidate the branch predictor when we actually switch to
>>> a different mm.
>>>
>>> In order to solve this, move the call to arm64_apply_bp_hardening()
>>> into check_and_switch_context(), where we're guaranteed to pick
>>> a different mm context.
>>>
>>> Acked-by: Will Deacon <will.deacon@arm.com>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>>> ---
>>> arch/arm64/mm/context.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
>>> index be42bd3dca5c..de5afc27b4e6 100644
>>> --- a/arch/arm64/mm/context.c
>>> +++ b/arch/arm64/mm/context.c
>>> @@ -183,6 +183,8 @@ void check_and_switch_context(struct mm_struct *mm, unsigned int cpu)
>>> raw_spin_unlock_irqrestore(&cpu_asid_lock, flags);
>>>
>>> switch_mm_fastpath:
>>> + arm64_apply_bp_hardening();
>>> +
>>> cpu_switch_mm(mm->pgd, mm);
>>> }
>>>
>>> @@ -193,8 +195,6 @@ asmlinkage void post_ttbr_update_workaround(void)
>>> "ic iallu; dsb nsh; isb",
>>> ARM64_WORKAROUND_CAVIUM_27456,
>>> CONFIG_CAVIUM_ERRATUM_27456));
>>> -
>>> - arm64_apply_bp_hardening();
>>
>> Patches 22 and 23 factorize the post_ttbr_update_workaround() and move
>> it to C code just so we would and a call to arm64_apply_bp_hardening()
>> in patch 24 that now gets moved elsewhere?
>>
>> Is it really worth backporting patches 22 and 23?
>
> If I can merge patch 24 and 25 into a single patch while backporting,
> then patch 22 and 23 won't be required. I am not sure how should the
> commit log look like in that case though :)
>
> Is mentioning both the upstream commit ids along with log of the first
> patch (which was more important) enough, like this ?
>
I must admit I am not familiar with backport/stable process enough. But
personally I think the your suggestion seems more sensible than
backporting 4 patches.
Or you can maybe ignore patch 25 and say in patch 24 that among the
changes made for the 4.4 codebase, the call arm64_apply_bp_hardening()
was moved from post_ttbr_update_workaround as it doesn't exist and
placed in check_and_switch_context() as it is its final destination.
However, I really don't know what's the best way to proceed according to
existing practices. So input from someone else would be welcome.
Thanks,
Julien
> Author: Will Deacon <will.deacon@arm.com>
> Date: Wed Jan 3 11:17:58 2018 +0000
>
> arm64: Add skeleton to harden the branch predictor against aliasing attacks
>
> commit 0f15adbb2861ce6f75ccfc5a92b19eae0ef327d0 upstream.
> commit a8e4c0a919ae310944ed2c9ace11cf3ccd8a609b upstream.
>
> Aliasing attacks against CPU branch predictors can allow an attacker to
> redirect speculative control flow on some CPUs and potentially divulge
> information from one context to another.
>
> This patch adds initial skeleton code behind a new Kconfig option to
> enable implementation-specific mitigations against these attacks for
> CPUs that are affected.
>
> Co-developed-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> [ v4.4: Changes made according to 4.4 codebase ]
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
--
Julien Thierry
_______________________________________________
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 v4.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context
From: Viresh Kumar @ 2019-08-01 6:35 UTC (permalink / raw)
To: Julien Thierry
Cc: Mark Rutland, Marc Zyngier, Catalin Marinas, Will Deacon, stable,
mark.brown, julien.thierry.kdev, Russell King, linux-arm-kernel
In-Reply-To: <86354576-fc54-a8b7-4dc9-bc613d59fb17@arm.com>
On 01-08-19, 07:30, Julien Thierry wrote:
> I must admit I am not familiar with backport/stable process enough. But
> personally I think the your suggestion seems more sensible than
> backporting 4 patches.
>
> Or you can maybe ignore patch 25 and say in patch 24 that among the
> changes made for the 4.4 codebase, the call arm64_apply_bp_hardening()
> was moved from post_ttbr_update_workaround as it doesn't exist and
> placed in check_and_switch_context() as it is its final destination.
Done that and dropped the other two patches.
> However, I really don't know what's the best way to proceed according to
> existing practices. So input from someone else would be welcome.
Lets see if someone comes up and ask me to do something else :)
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 6:36 UTC (permalink / raw)
To: Sumit Garg
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, Jonathan Corbet,
jejb, Ard Biesheuvel, Linux Doc Mailing List, James Morris,
Jarkko Sakkinen, Linux Kernel Mailing List, dhowells,
linux-security-module, keyrings, Mimi Zohar, Casey Schaufler,
linux-integrity, Jens Wiklander, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAFA6WYOKcOzSwakHhgshZcebD8ZBMSi7xQdjWYFS79=Xc+odOg@mail.gmail.com>
On Wed, Jul 31, 2019 at 5:23 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> > I guess my wording was wrong, tried to say that physical TEEs in the
> > wild vary massively hardware wise. Generalizing these things is rough.
> >
>
> There are already well defined GlobalPlatform Standards to generalize
> the TEE interface. One of them is GlobalPlatform TEE Client API [1]
> which provides the basis for this TEE interface.
I'm aware of it - I have implemented a large part of the GP TEE APIs
earlier (primarily the crypto functions). Does the TEE you work with
actually support GP properly? Can I take a look at the code?
Normally the TEE implementations are well-guarded secrets and the
state of the implementation is quite random. In many cases keeping
things secret is fine from my point of view, given that it is a RoT
after all. The secrecy is the core business here. So, this is why I
opted the userspace 'secret' route - no secrets in the kernel, but
it's fine for the userspace. Umh was a logical fit to implement it.
--
Janne
_______________________________________________
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 v9 12/21] mm: pagewalk: Allow walking without vma
From: Anshuman Khandual @ 2019-08-01 6:41 UTC (permalink / raw)
To: Steven Price, linux-mm
Cc: Mark Rutland, Dave Hansen, Arnd Bergmann, Ard Biesheuvel,
Peter Zijlstra, Catalin Marinas, x86, linux-kernel,
Jérôme Glisse, Ingo Molnar, Borislav Petkov,
Andy Lutomirski, H. Peter Anvin, James Morse, Thomas Gleixner,
Will Deacon, Andrew Morton, linux-arm-kernel, Liang, Kan
In-Reply-To: <5aff70f7-67a5-c7e8-5fec-8182dea0da0c@arm.com>
On 07/29/2019 05:59 PM, Steven Price wrote:
> On 28/07/2019 15:20, Anshuman Khandual wrote:
>>
>>
>> On 07/22/2019 09:12 PM, Steven Price wrote:
>>> Since 48684a65b4e3: "mm: pagewalk: fix misbehavior of walk_page_range
>>> for vma(VM_PFNMAP)", page_table_walk() will report any kernel area as
>>> a hole, because it lacks a vma.
>>>
>>> This means each arch has re-implemented page table walking when needed,
>>> for example in the per-arch ptdump walker.
>>>
>>> Remove the requirement to have a vma except when trying to split huge
>>> pages.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> ---
>>> mm/pagewalk.c | 25 +++++++++++++++++--------
>>> 1 file changed, 17 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/mm/pagewalk.c b/mm/pagewalk.c
>>> index 98373a9f88b8..1cbef99e9258 100644
>>> --- a/mm/pagewalk.c
>>> +++ b/mm/pagewalk.c
>>> @@ -36,7 +36,7 @@ static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
>>> do {
>>> again:
>>> next = pmd_addr_end(addr, end);
>>> - if (pmd_none(*pmd) || !walk->vma) {
>>> + if (pmd_none(*pmd)) {
>>> if (walk->pte_hole)
>>> err = walk->pte_hole(addr, next, walk);
>>> if (err)
>>> @@ -59,9 +59,14 @@ static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
>>> if (!walk->pte_entry)
>>> continue;
>>>
>>> - split_huge_pmd(walk->vma, pmd, addr);
>>> - if (pmd_trans_unstable(pmd))
>>> - goto again;
>>> + if (walk->vma) {
>>> + split_huge_pmd(walk->vma, pmd, addr);
>>
>> Check for a PMD THP entry before attempting to split it ?
>
> split_huge_pmd does the check for us:
>> #define split_huge_pmd(__vma, __pmd, __address) \
>> do { \
>> pmd_t *____pmd = (__pmd); \
>> if (is_swap_pmd(*____pmd) || pmd_trans_huge(*____pmd) \
>> || pmd_devmap(*____pmd)) \
>> __split_huge_pmd(__vma, __pmd, __address, \
>> false, NULL); \
>> } while (0)
>
> And this isn't a change from the previous code - only that the entry is
> no longer split when walk->vma==NULL.
Does it make sense to name walk->vma check to differentiate between user
and kernel page tables. IMHO that will help make things clear and explicit
during page table walk.
>
>>> + if (pmd_trans_unstable(pmd))
>>> + goto again;
>>> + } else if (pmd_leaf(*pmd)) {
>>> + continue;
>>> + }
>>> +
>>> err = walk_pte_range(pmd, addr, next, walk);
>>> if (err)
>>> break;
>>> @@ -81,7 +86,7 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end,
>>> do {
>>> again:
>>> next = pud_addr_end(addr, end);
>>> - if (pud_none(*pud) || !walk->vma) {
>>> + if (pud_none(*pud)) {
>>> if (walk->pte_hole)
>>> err = walk->pte_hole(addr, next, walk);
>>> if (err)
>>> @@ -95,9 +100,13 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end,
>>> break;
>>> }
>>>
>>> - split_huge_pud(walk->vma, pud, addr);
>>> - if (pud_none(*pud))
>>> - goto again;
>>> + if (walk->vma) {
>>> + split_huge_pud(walk->vma, pud, addr);
>>
>> Check for a PUD THP entry before attempting to split it ?
>
> Same as above.
>
>>> + if (pud_none(*pud))
>>> + goto again;
>>> + } else if (pud_leaf(*pud)) {
>>> + continue;
>>> + }
>>
>> This is bit cryptic. walk->vma check should be inside a helper is_user_page_table()
>> or similar to make things clear. p4d_leaf() check missing in walk_p4d_range() for
>> kernel page table walk ? Wondering if p?d_leaf() test should be moved earlier while
>> calling p?d_entry() for kernel page table walk.
>
> I wasn't sure if it was worth putting p4d_leaf() and pgd_leaf() checks
> in (yet). No architecture that I know of uses such large pages.
Just to be complete it does make sense to add the remaining possible leaf
entry checks but will leave it upto you.
>
> I'm not sure what you mean by moving the p?d_leaf() test earlier? Can
> you explain with an example?
In case its a kernel p?d_leaf() entry, then there is nothing to be done
after calling respective walk->p?d_entry() functions. Hence this check
should not complement user page table check (walk->vma) later in the
function but instead be checked right after walk->p?d_entry(). But its
not a big deal I guess.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Rouven Czerwinski @ 2019-08-01 6:50 UTC (permalink / raw)
To: Janne Karhunen, Sumit Garg
Cc: Jonathan Corbet, Daniel Thompson, Ard Biesheuvel, jejb,
Linux Doc Mailing List, Linux Kernel Mailing List,
Jarkko Sakkinen, tee-dev @ lists . linaro . org,
linux-security-module, keyrings, Mimi Zohar, dhowells,
Casey Schaufler, linux-integrity, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAE=NcrYz8bT9zDhS_ZcvY84fpeTDxZ-KhJKeQGGyf=o4pG2J-Q@mail.gmail.com>
On Thu, 2019-08-01 at 09:36 +0300, Janne Karhunen wrote:
> On Wed, Jul 31, 2019 at 5:23 PM Sumit Garg <sumit.garg@linaro.org>
> wrote:
>
> > > I guess my wording was wrong, tried to say that physical TEEs in
> > > the
> > > wild vary massively hardware wise. Generalizing these things is
> > > rough.
> > >
> >
> > There are already well defined GlobalPlatform Standards to
> > generalize
> > the TEE interface. One of them is GlobalPlatform TEE Client API [1]
> > which provides the basis for this TEE interface.
>
> I'm aware of it - I have implemented a large part of the GP TEE APIs
> earlier (primarily the crypto functions). Does the TEE you work with
> actually support GP properly? Can I take a look at the code?
AFAIK Sumit is working with the OP-TEE implementation, which can be
found on github: https://github.com/op-tee/optee_os
Regards,
Rouven
_______________________________________________
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 v4.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context
From: Greg KH @ 2019-08-01 6:57 UTC (permalink / raw)
To: Viresh Kumar
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Catalin Marinas,
Will Deacon, stable, mark.brown, julien.thierry.kdev,
Russell King, linux-arm-kernel
In-Reply-To: <20190801063544.ruw444isj5uojjdx@vireshk-i7>
On Thu, Aug 01, 2019 at 12:05:44PM +0530, Viresh Kumar wrote:
> On 01-08-19, 07:30, Julien Thierry wrote:
> > I must admit I am not familiar with backport/stable process enough. But
> > personally I think the your suggestion seems more sensible than
> > backporting 4 patches.
> >
> > Or you can maybe ignore patch 25 and say in patch 24 that among the
> > changes made for the 4.4 codebase, the call arm64_apply_bp_hardening()
> > was moved from post_ttbr_update_workaround as it doesn't exist and
> > placed in check_and_switch_context() as it is its final destination.
>
> Done that and dropped the other two patches.
>
> > However, I really don't know what's the best way to proceed according to
> > existing practices. So input from someone else would be welcome.
>
> Lets see if someone comes up and ask me to do something else :)
Keeping the same patches that upstream has is almost always the better
thing to do in the long-run.
thanks,
greg k-h
_______________________________________________
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