* Re: [PATCH v1 1/9] dmaengine: Actions: get rid of bit fields from dma descriptor
From: Amit Tomer @ 2020-05-14 18:34 UTC (permalink / raw)
To: Vinod Koul
Cc: Andre Przywara, linux-actions, cristian.ciocaltea,
Manivannan Sadhasivam, dmaengine, dan.j.williams,
Andreas Färber, linux-arm-kernel
In-Reply-To: <20200514182750.GJ14092@vkoul-mobl>
Hi,
On Thu, May 14, 2020 at 11:58 PM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 14-05-20, 21:40, Amit Singh Tomar wrote:
> > At the moment, Driver uses bit fields to describe registers of the DMA
> > descriptor structure that makes it less portable and maintainable, and
> > Andre suugested(and even sketched important bits for it) to make use of
> > array to describe this DMA descriptors instead. It gives the flexibility
> > while extending support for other platform such as Actions S700.
> >
> > This commit removes the "owl_dma_lli_hw" (that includes bit-fields) and
> > uses array to describe DMA descriptor.
>
> So i see patch 1/9 and 2/9 in my inbox... where are the rest ? No cover
> to detail out what the rest contains, who should merge them etc etc!
>
> If you are sending a series to different subsystem please make a habit
> to CC everyone on cover letter so that we understand details about the
> series. If not dependent, just send as individual units to subsystems!
Ok, I would make note of it and Cc everyone on cover letter going forward.
Thanks
-Amit
_______________________________________________
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] coresight: etm4x: Add support to disable trace unit power up
From: Sai Prakash Ranjan @ 2020-05-14 18:39 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Suzuki K Poulose, linux-arm-msm, coresight, linux-kernel,
Stephen Boyd, Tingwei Zhang, Leo Yan, linux-arm-kernel,
Mike Leach
In-Reply-To: <20200514180055.GA29384@xps15>
Hi Mathieu,
On 2020-05-14 23:30, Mathieu Poirier wrote:
> Good morning Sai,
>
> On Thu, May 14, 2020 at 04:29:15PM +0530, Sai Prakash Ranjan wrote:
>> From: Tingwei Zhang <tingwei@codeaurora.org>
>>
>> On some Qualcomm Technologies Inc. SoCs like SC7180, there
>> exists a hardware errata where the APSS (Application Processor
>> SubSystem)/CPU watchdog counter is stopped when ETM register
>> TRCPDCR.PU=1.
>
> Fun stuff...
>
Yes :)
>> Since the ETMs share the same power domain as
>> that of respective CPU cores, they are powered on when the
>> CPU core is powered on. So we can disable powering up of the
>> trace unit after checking for this errata via new property
>> called "qcom,tupwr-disable".
>>
>> Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
>> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>
> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
>
Tingwei is the author, so if I understand correctly, his signed-off-by
should appear first, am I wrong?
>> ---
>> .../devicetree/bindings/arm/coresight.txt | 6 ++++
>> drivers/hwtracing/coresight/coresight-etm4x.c | 29
>> ++++++++++++-------
>
> Please split in two patches.
>
Sure, I will split the dt-binding into separate patch, checkpatch did
warn.
>> 2 files changed, 25 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
>> b/Documentation/devicetree/bindings/arm/coresight.txt
>> index 846f6daae71b..d2030128fe46 100644
>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>> @@ -108,6 +108,12 @@ its hardware characteristcs.
>> * arm,cp14: must be present if the system accesses ETM/PTM
>> management
>> registers via co-processor 14.
>>
>> + * qcom,tupwr-disable: boolean. Indicates that trace unit power up
>> can
>> + be disabled on Qualcomm Technologies Inc. systems where ETMs are
>> in
>> + the same power domain as their CPU cores. This property is
>> required
>> + to identify such systems with hardware errata where the CPU
>> watchdog
>> + counter is stopped when TRCPDCR.PU=1.
>> +
>
> I think something like "qcom,skip-power-up" would be clearer.
>
> Also, a better choice of words is that TRCPDCR.PU does not have to be
> set on
> Qualcomm...
>
Yes "qcom,skip-power-up" is a lot better, thanks. Also will use
something as
you suggested for description.
>> * Optional property for TMC:
>>
>> * arm,buffer-size: size of contiguous buffer space for TMC ETR
>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
>> b/drivers/hwtracing/coresight/coresight-etm4x.c
>> index fb0f5f4f3a91..6886b44f6947 100644
>> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
>> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
>> @@ -104,6 +104,11 @@ struct etm4_enable_arg {
>> int rc;
>> };
>>
>> +static inline bool etm4_can_disable_tupwr(struct device *dev)
>> +{
>> + return fwnode_property_present(dev_fwnode(dev),
>> "qcom,tupwr-disable");
>> +}
>> +
>
> Please call fwnode_property_present() at initialisation time to set a
> new
> drvdata::skip_power_up variable. From there just switch on that in
> etm4_enable/disable_hw().
>
Will do, thanks.
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
* [PATCH AUTOSEL 5.6 36/62] stmmac: fix pointer check after utilization in stmmac_interrupt
From: Sasha Levin @ 2020-05-14 18:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, netdev, David S . Miller, Maxim Petrov, linux-stm32,
linux-arm-kernel
In-Reply-To: <20200514185147.19716-1-sashal@kernel.org>
From: Maxim Petrov <mmrmaximuzz@gmail.com>
[ Upstream commit f42234ffd531ca6b13d9da02faa60b72eccf8334 ]
The paranoidal pointer check in IRQ handler looks very strange - it
really protects us only against bogus drivers which request IRQ line
with null pointer dev_id. However, the code fragment is incorrect
because the dev pointer is used before the actual check which leads
to undefined behavior. Remove the check to avoid confusing people
with incorrect code.
Signed-off-by: Maxim Petrov <mmrmaximuzz@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7da18c9afa01d..d564459290ce1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3988,7 +3988,7 @@ static int stmmac_set_features(struct net_device *netdev,
/**
* stmmac_interrupt - main ISR
* @irq: interrupt number.
- * @dev_id: to pass the net device pointer.
+ * @dev_id: to pass the net device pointer (must be valid).
* Description: this is the main driver interrupt service routine.
* It can call:
* o DMA service routine (to manage incoming frame reception and transmission
@@ -4012,11 +4012,6 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id)
if (priv->irq_wake)
pm_wakeup_event(priv->device, 0);
- if (unlikely(!dev)) {
- netdev_err(priv->dev, "%s: invalid dev pointer\n", __func__);
- return IRQ_NONE;
- }
-
/* Check if adapter is up */
if (test_bit(STMMAC_DOWN, &priv->state))
return IRQ_HANDLED;
--
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 AUTOSEL 5.6 34/62] sun6i: dsi: fix gcc-4.8
From: Sasha Levin @ 2020-05-14 18:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Arnd Bergmann, dri-devel, Paul Kocialkowski,
Maxime Ripard, linux-arm-kernel
In-Reply-To: <20200514185147.19716-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 3a3a71f97c30983f1627c2c550d43566e9b634d2 ]
Older compilers warn about initializers with incorrect curly
braces:
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function 'sun6i_dsi_encoder_enable':
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:8: error: missing braces around initializer [-Werror=missing-braces]
union phy_configure_opts opts = { 0 };
^
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:8: error: (near initialization for 'opts.mipi_dphy') [-Werror=missing-braces]
Use the GNU empty initializer extension to avoid this.
Fixes: bb3b6fcb6849 ("sun6i: dsi: Convert to generic phy handling")
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428215105.3928459-1-arnd@arndb.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index a75fcb1131724..2b6d77ca3dfc2 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -719,7 +719,7 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
struct mipi_dsi_device *device = dsi->device;
- union phy_configure_opts opts = { 0 };
+ union phy_configure_opts opts = { };
struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
u16 delay;
--
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 AUTOSEL 5.6 37/62] net: stmmac: gmac5+: fix potential integer overflow on 32 bit multiply
From: Sasha Levin @ 2020-05-14 18:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, netdev, David S . Miller, Colin Ian King,
linux-stm32, linux-arm-kernel
In-Reply-To: <20200514185147.19716-1-sashal@kernel.org>
From: Colin Ian King <colin.king@canonical.com>
[ Upstream commit 44d95cc6b10ff7439d45839c96c581cb4368c088 ]
The multiplication of cfg->ctr[1] by 1000000000 is performed using a
32 bit multiplication (since cfg->ctr[1] is a u32) and this can lead
to a potential overflow. Fix this by making the constant a ULL to
ensure a 64 bit multiply occurs.
Fixes: 504723af0d85 ("net: stmmac: Add basic EST support for GMAC5+")
Addresses-Coverity: ("Unintentional integer overflow")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
index 494c859b4ade8..67ba67ed0cb99 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
@@ -624,7 +624,7 @@ int dwmac5_est_configure(void __iomem *ioaddr, struct stmmac_est *cfg,
total_offset += offset;
}
- total_ctr = cfg->ctr[0] + cfg->ctr[1] * 1000000000;
+ total_ctr = cfg->ctr[0] + cfg->ctr[1] * 1000000000ULL;
total_ctr += total_offset;
ctr_low = do_div(total_ctr, 1000000000);
--
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 AUTOSEL 5.6 48/62] ARM: futex: Address build warning
From: Sasha Levin @ 2020-05-14 18:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Stephen Rothwell, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20200514185147.19716-1-sashal@kernel.org>
From: Thomas Gleixner <tglx@linutronix.de>
[ Upstream commit 8101b5a1531f3390b3a69fa7934c70a8fd6566ad ]
Stephen reported the following build warning on a ARM multi_v7_defconfig
build with GCC 9.2.1:
kernel/futex.c: In function 'do_futex':
kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
1676 | return oldval == cmparg;
| ~~~~~~~^~~~~~~~~
kernel/futex.c:1652:6: note: 'oldval' was declared here
1652 | int oldval, ret;
| ^~~~~~
introduced by commit a08971e9488d ("futex: arch_futex_atomic_op_inuser()
calling conventions change").
While that change should not make any difference it confuses GCC which
fails to work out that oldval is not referenced when the return value is
not zero.
GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the
early return, the issue is with the assembly macros. GCC fails to detect
that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT
which makes oldval uninteresting. The store to the callsite supplied oldval
pointer is conditional on ret == 0.
The straight forward way to solve this is to make the store unconditional.
Aside of addressing the build warning this makes sense anyway because it
removes the conditional from the fastpath. In the error case the stored
value is uninteresting and the extra store does not matter at all.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/include/asm/futex.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index 83c391b597d45..fdc4ae3e7378d 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -164,8 +164,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
preempt_enable();
#endif
- if (!ret)
- *oval = oldval;
+ /*
+ * Store unconditionally. If ret != 0 the extra store is the least
+ * of the worries but GCC cannot figure out that __futex_atomic_op()
+ * is either setting ret to -EFAULT or storing the old value in
+ * oldval which results in a uninitialized warning at the call site.
+ */
+ *oval = oldval;
return 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 AUTOSEL 5.4 33/49] stmmac: fix pointer check after utilization in stmmac_interrupt
From: Sasha Levin @ 2020-05-14 18:52 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, netdev, David S . Miller, Maxim Petrov, linux-stm32,
linux-arm-kernel
In-Reply-To: <20200514185311.20294-1-sashal@kernel.org>
From: Maxim Petrov <mmrmaximuzz@gmail.com>
[ Upstream commit f42234ffd531ca6b13d9da02faa60b72eccf8334 ]
The paranoidal pointer check in IRQ handler looks very strange - it
really protects us only against bogus drivers which request IRQ line
with null pointer dev_id. However, the code fragment is incorrect
because the dev pointer is used before the actual check which leads
to undefined behavior. Remove the check to avoid confusing people
with incorrect code.
Signed-off-by: Maxim Petrov <mmrmaximuzz@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 89a6ae2b17e35..1623516efb171 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3832,7 +3832,7 @@ static int stmmac_set_features(struct net_device *netdev,
/**
* stmmac_interrupt - main ISR
* @irq: interrupt number.
- * @dev_id: to pass the net device pointer.
+ * @dev_id: to pass the net device pointer (must be valid).
* Description: this is the main driver interrupt service routine.
* It can call:
* o DMA service routine (to manage incoming frame reception and transmission
@@ -3856,11 +3856,6 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id)
if (priv->irq_wake)
pm_wakeup_event(priv->device, 0);
- if (unlikely(!dev)) {
- netdev_err(priv->dev, "%s: invalid dev pointer\n", __func__);
- return IRQ_NONE;
- }
-
/* Check if adapter is up */
if (test_bit(STMMAC_DOWN, &priv->state))
return IRQ_HANDLED;
--
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 AUTOSEL 5.4 31/49] sun6i: dsi: fix gcc-4.8
From: Sasha Levin @ 2020-05-14 18:52 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Arnd Bergmann, dri-devel, Paul Kocialkowski,
Maxime Ripard, linux-arm-kernel
In-Reply-To: <20200514185311.20294-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 3a3a71f97c30983f1627c2c550d43566e9b634d2 ]
Older compilers warn about initializers with incorrect curly
braces:
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function 'sun6i_dsi_encoder_enable':
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:8: error: missing braces around initializer [-Werror=missing-braces]
union phy_configure_opts opts = { 0 };
^
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:8: error: (near initialization for 'opts.mipi_dphy') [-Werror=missing-braces]
Use the GNU empty initializer extension to avoid this.
Fixes: bb3b6fcb6849 ("sun6i: dsi: Convert to generic phy handling")
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428215105.3928459-1-arnd@arndb.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index f83522717488a..4f944ace665d5 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -718,7 +718,7 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
struct mipi_dsi_device *device = dsi->device;
- union phy_configure_opts opts = { 0 };
+ union phy_configure_opts opts = { };
struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
u16 delay;
--
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 AUTOSEL 5.4 39/49] ARM: futex: Address build warning
From: Sasha Levin @ 2020-05-14 18:53 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Stephen Rothwell, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20200514185311.20294-1-sashal@kernel.org>
From: Thomas Gleixner <tglx@linutronix.de>
[ Upstream commit 8101b5a1531f3390b3a69fa7934c70a8fd6566ad ]
Stephen reported the following build warning on a ARM multi_v7_defconfig
build with GCC 9.2.1:
kernel/futex.c: In function 'do_futex':
kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
1676 | return oldval == cmparg;
| ~~~~~~~^~~~~~~~~
kernel/futex.c:1652:6: note: 'oldval' was declared here
1652 | int oldval, ret;
| ^~~~~~
introduced by commit a08971e9488d ("futex: arch_futex_atomic_op_inuser()
calling conventions change").
While that change should not make any difference it confuses GCC which
fails to work out that oldval is not referenced when the return value is
not zero.
GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the
early return, the issue is with the assembly macros. GCC fails to detect
that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT
which makes oldval uninteresting. The store to the callsite supplied oldval
pointer is conditional on ret == 0.
The straight forward way to solve this is to make the store unconditional.
Aside of addressing the build warning this makes sense anyway because it
removes the conditional from the fastpath. In the error case the stored
value is uninteresting and the extra store does not matter at all.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/include/asm/futex.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index 83c391b597d45..fdc4ae3e7378d 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -164,8 +164,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
preempt_enable();
#endif
- if (!ret)
- *oval = oldval;
+ /*
+ * Store unconditionally. If ret != 0 the extra store is the least
+ * of the worries but GCC cannot figure out that __futex_atomic_op()
+ * is either setting ret to -EFAULT or storing the old value in
+ * oldval which results in a uninitialized warning at the call site.
+ */
+ *oval = oldval;
return 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 AUTOSEL 4.19 25/31] stmmac: fix pointer check after utilization in stmmac_interrupt
From: Sasha Levin @ 2020-05-14 18:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, netdev, David S . Miller, Maxim Petrov, linux-stm32,
linux-arm-kernel
In-Reply-To: <20200514185413.20755-1-sashal@kernel.org>
From: Maxim Petrov <mmrmaximuzz@gmail.com>
[ Upstream commit f42234ffd531ca6b13d9da02faa60b72eccf8334 ]
The paranoidal pointer check in IRQ handler looks very strange - it
really protects us only against bogus drivers which request IRQ line
with null pointer dev_id. However, the code fragment is incorrect
because the dev pointer is used before the actual check which leads
to undefined behavior. Remove the check to avoid confusing people
with incorrect code.
Signed-off-by: Maxim Petrov <mmrmaximuzz@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 9c7b1d8e82204..c41879a955b57 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3684,7 +3684,7 @@ static int stmmac_set_features(struct net_device *netdev,
/**
* stmmac_interrupt - main ISR
* @irq: interrupt number.
- * @dev_id: to pass the net device pointer.
+ * @dev_id: to pass the net device pointer (must be valid).
* Description: this is the main driver interrupt service routine.
* It can call:
* o DMA service routine (to manage incoming frame reception and transmission
@@ -3708,11 +3708,6 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id)
if (priv->irq_wake)
pm_wakeup_event(priv->device, 0);
- if (unlikely(!dev)) {
- netdev_err(priv->dev, "%s: invalid dev pointer\n", __func__);
- return IRQ_NONE;
- }
-
/* Check if adapter is up */
if (test_bit(STMMAC_DOWN, &priv->state))
return IRQ_HANDLED;
--
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 AUTOSEL 4.19 28/31] ARM: futex: Address build warning
From: Sasha Levin @ 2020-05-14 18:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Stephen Rothwell, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20200514185413.20755-1-sashal@kernel.org>
From: Thomas Gleixner <tglx@linutronix.de>
[ Upstream commit 8101b5a1531f3390b3a69fa7934c70a8fd6566ad ]
Stephen reported the following build warning on a ARM multi_v7_defconfig
build with GCC 9.2.1:
kernel/futex.c: In function 'do_futex':
kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
1676 | return oldval == cmparg;
| ~~~~~~~^~~~~~~~~
kernel/futex.c:1652:6: note: 'oldval' was declared here
1652 | int oldval, ret;
| ^~~~~~
introduced by commit a08971e9488d ("futex: arch_futex_atomic_op_inuser()
calling conventions change").
While that change should not make any difference it confuses GCC which
fails to work out that oldval is not referenced when the return value is
not zero.
GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the
early return, the issue is with the assembly macros. GCC fails to detect
that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT
which makes oldval uninteresting. The store to the callsite supplied oldval
pointer is conditional on ret == 0.
The straight forward way to solve this is to make the store unconditional.
Aside of addressing the build warning this makes sense anyway because it
removes the conditional from the fastpath. In the error case the stored
value is uninteresting and the extra store does not matter at all.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/include/asm/futex.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index ffebe7b7a5b74..91ca80035fc42 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -163,8 +163,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
preempt_enable();
#endif
- if (!ret)
- *oval = oldval;
+ /*
+ * Store unconditionally. If ret != 0 the extra store is the least
+ * of the worries but GCC cannot figure out that __futex_atomic_op()
+ * is either setting ret to -EFAULT or storing the old value in
+ * oldval which results in a uninitialized warning at the call site.
+ */
+ *oval = oldval;
return 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 AUTOSEL 4.14 37/39] ARM: futex: Address build warning
From: Sasha Levin @ 2020-05-14 18:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Stephen Rothwell, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20200514185456.21060-1-sashal@kernel.org>
From: Thomas Gleixner <tglx@linutronix.de>
[ Upstream commit 8101b5a1531f3390b3a69fa7934c70a8fd6566ad ]
Stephen reported the following build warning on a ARM multi_v7_defconfig
build with GCC 9.2.1:
kernel/futex.c: In function 'do_futex':
kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
1676 | return oldval == cmparg;
| ~~~~~~~^~~~~~~~~
kernel/futex.c:1652:6: note: 'oldval' was declared here
1652 | int oldval, ret;
| ^~~~~~
introduced by commit a08971e9488d ("futex: arch_futex_atomic_op_inuser()
calling conventions change").
While that change should not make any difference it confuses GCC which
fails to work out that oldval is not referenced when the return value is
not zero.
GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the
early return, the issue is with the assembly macros. GCC fails to detect
that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT
which makes oldval uninteresting. The store to the callsite supplied oldval
pointer is conditional on ret == 0.
The straight forward way to solve this is to make the store unconditional.
Aside of addressing the build warning this makes sense anyway because it
removes the conditional from the fastpath. In the error case the stored
value is uninteresting and the extra store does not matter at all.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/include/asm/futex.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index ffebe7b7a5b74..91ca80035fc42 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -163,8 +163,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
preempt_enable();
#endif
- if (!ret)
- *oval = oldval;
+ /*
+ * Store unconditionally. If ret != 0 the extra store is the least
+ * of the worries but GCC cannot figure out that __futex_atomic_op()
+ * is either setting ret to -EFAULT or storing the old value in
+ * oldval which results in a uninitialized warning at the call site.
+ */
+ *oval = oldval;
return 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 AUTOSEL 4.9 26/27] ARM: futex: Address build warning
From: Sasha Levin @ 2020-05-14 18:55 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Stephen Rothwell, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20200514185550.21462-1-sashal@kernel.org>
From: Thomas Gleixner <tglx@linutronix.de>
[ Upstream commit 8101b5a1531f3390b3a69fa7934c70a8fd6566ad ]
Stephen reported the following build warning on a ARM multi_v7_defconfig
build with GCC 9.2.1:
kernel/futex.c: In function 'do_futex':
kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
1676 | return oldval == cmparg;
| ~~~~~~~^~~~~~~~~
kernel/futex.c:1652:6: note: 'oldval' was declared here
1652 | int oldval, ret;
| ^~~~~~
introduced by commit a08971e9488d ("futex: arch_futex_atomic_op_inuser()
calling conventions change").
While that change should not make any difference it confuses GCC which
fails to work out that oldval is not referenced when the return value is
not zero.
GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the
early return, the issue is with the assembly macros. GCC fails to detect
that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT
which makes oldval uninteresting. The store to the callsite supplied oldval
pointer is conditional on ret == 0.
The straight forward way to solve this is to make the store unconditional.
Aside of addressing the build warning this makes sense anyway because it
removes the conditional from the fastpath. In the error case the stored
value is uninteresting and the extra store does not matter at all.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/include/asm/futex.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index cc414382dab4b..561b2ba6bc284 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -162,8 +162,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
preempt_enable();
#endif
- if (!ret)
- *oval = oldval;
+ /*
+ * Store unconditionally. If ret != 0 the extra store is the least
+ * of the worries but GCC cannot figure out that __futex_atomic_op()
+ * is either setting ret to -EFAULT or storing the old value in
+ * oldval which results in a uninitialized warning at the call site.
+ */
+ *oval = oldval;
return 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 AUTOSEL 4.4 13/14] ARM: futex: Address build warning
From: Sasha Levin @ 2020-05-14 18:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Stephen Rothwell, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20200514185625.21753-1-sashal@kernel.org>
From: Thomas Gleixner <tglx@linutronix.de>
[ Upstream commit 8101b5a1531f3390b3a69fa7934c70a8fd6566ad ]
Stephen reported the following build warning on a ARM multi_v7_defconfig
build with GCC 9.2.1:
kernel/futex.c: In function 'do_futex':
kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized]
1676 | return oldval == cmparg;
| ~~~~~~~^~~~~~~~~
kernel/futex.c:1652:6: note: 'oldval' was declared here
1652 | int oldval, ret;
| ^~~~~~
introduced by commit a08971e9488d ("futex: arch_futex_atomic_op_inuser()
calling conventions change").
While that change should not make any difference it confuses GCC which
fails to work out that oldval is not referenced when the return value is
not zero.
GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the
early return, the issue is with the assembly macros. GCC fails to detect
that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT
which makes oldval uninteresting. The store to the callsite supplied oldval
pointer is conditional on ret == 0.
The straight forward way to solve this is to make the store unconditional.
Aside of addressing the build warning this makes sense anyway because it
removes the conditional from the fastpath. In the error case the stored
value is uninteresting and the extra store does not matter at all.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/include/asm/futex.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index cc414382dab4b..561b2ba6bc284 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -162,8 +162,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
preempt_enable();
#endif
- if (!ret)
- *oval = oldval;
+ /*
+ * Store unconditionally. If ret != 0 the extra store is the least
+ * of the worries but GCC cannot figure out that __futex_atomic_op()
+ * is either setting ret to -EFAULT or storing the old value in
+ * oldval which results in a uninitialized warning at the call site.
+ */
+ *oval = oldval;
return 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 0/2] Set the quality value for two HW RNGs
From: Łukasz Stelmach @ 2020-05-14 19:07 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman,
Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim,
Krzysztof Kozlowski, Florian Fainelli, Markus Elfring,
Matthias Brugger, Stefan Wahren, linux-crypto, linux-arm-kernel,
linux-kernel, linux-samsung-soc
Cc: Łukasz Stelmach, Bartlomiej Zolnierkiewicz
In-Reply-To: <CGME20200514190737eucas1p18ccdddb185ea7611683a6859e17bc721@eucas1p1.samsung.com>
The rng structure contains the quality field which tells how many bits
of entropy can be obtained from 1024 bits read from a device. With the
quality value set the hw_random framework starts a kernel thread to feed
the entropy pool in the CRNG, which helps to initialize it quickly
especially during boot.
Łukasz Stelmach (2):
hwrng: iproc-rng200 - Set the quality value
hwrng: exynos - Set the quality value
drivers/char/hw_random/exynos-trng.c | 1 +
drivers/char/hw_random/iproc-rng200.c | 1 +
2 files changed, 2 insertions(+)
--
2.25.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value
From: Łukasz Stelmach @ 2020-05-14 19:07 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman,
Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim,
Krzysztof Kozlowski, Florian Fainelli, Markus Elfring,
Matthias Brugger, Stefan Wahren, linux-crypto, linux-arm-kernel,
linux-kernel, linux-samsung-soc
Cc: Łukasz Stelmach, Bartlomiej Zolnierkiewicz
In-Reply-To: <20200514190734.32746-1-l.stelmach@samsung.com>
The value has been estimaded by obtainig 1024 chunks of data 128 bytes
(1024 bits) each from the generator and finding chunk with minimal
entropy using the ent(1) tool. The value was 6.327820 bits of entropy
in each 8 bits of data.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
---
drivers/char/hw_random/iproc-rng200.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/hw_random/iproc-rng200.c b/drivers/char/hw_random/iproc-rng200.c
index 32d9fe61a225..7eb02a23f744 100644
--- a/drivers/char/hw_random/iproc-rng200.c
+++ b/drivers/char/hw_random/iproc-rng200.c
@@ -199,6 +199,7 @@ static int iproc_rng200_probe(struct platform_device *pdev)
priv->rng.read = iproc_rng200_read,
priv->rng.init = iproc_rng200_init,
priv->rng.cleanup = iproc_rng200_cleanup,
+ priv->rng.quality = 800,
/* Register driver */
ret = devm_hwrng_register(dev, &priv->rng);
--
2.25.0
_______________________________________________
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 2/2] hwrng: exynos - Set the quality value
From: Łukasz Stelmach @ 2020-05-14 19:07 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman,
Ray Jui, Scott Branden, bcm-kernel-feedback-list, Kukjin Kim,
Krzysztof Kozlowski, Florian Fainelli, Markus Elfring,
Matthias Brugger, Stefan Wahren, linux-crypto, linux-arm-kernel,
linux-kernel, linux-samsung-soc
Cc: Łukasz Stelmach, Bartlomiej Zolnierkiewicz
In-Reply-To: <20200514190734.32746-1-l.stelmach@samsung.com>
The value has been estimaded by obtainig 1024 chunks of data 128 bytes
(1024 bits) each from the generator and finding chunk with minimal
entropy using the ent(1) tool. The value was 6.332937 bits of entropy
in each 8 bits of data.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
---
drivers/char/hw_random/exynos-trng.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
index 8e1fe3f8dd2d..ff6739272bf5 100644
--- a/drivers/char/hw_random/exynos-trng.c
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -123,6 +123,7 @@ static int exynos_trng_probe(struct platform_device *pdev)
trng->rng.init = exynos_trng_init;
trng->rng.read = exynos_trng_do_read;
trng->rng.priv = (unsigned long) trng;
+ trng->rng.quality = 800;
platform_set_drvdata(pdev, trng);
trng->dev = &pdev->dev;
--
2.25.0
_______________________________________________
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] cpuidle: psci: Fixup execution order when entering a domain idle state
From: Ulf Hansson @ 2020-05-14 19:11 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Benjamin Gaignard, Linux PM, Stephen Boyd,
Daniel Lezcano, Rafael J . Wysocki, Lina Iyer, Bjorn Andersson,
Linux ARM
In-Reply-To: <20200514172816.GA42669@bogus>
On Thu, 14 May 2020 at 19:28, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Thu, May 14, 2020 at 05:41:37PM +0200, Ulf Hansson wrote:
> > On Thu, 14 May 2020 at 16:20, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > > On Mon, May 11, 2020 at 03:33:46PM +0200, Ulf Hansson wrote:
> > > > Moving forward, platforms are going to need to execute specific "last-man"
> > > > operations before a domain idle state can be entered.
> > >
> > > I need to dig the thread details, but I remember commenting on one of
> > > the similar discussion. It was something to do with voting which wasn't
> > > necessary at all. I am interested in the details here.
> > >
> > > > In one way or the other, these operations needs to be triggered while
> > > > walking the hierarchical topology via runtime PM and genpd, as it's at that
> > > > point the last-man becomes known.
> > > >
> > > > Moreover, executing last-man operations needs to be done after the CPU PM
> > > > notifications are sent through cpu_pm_enter(), as otherwise it's likely
> > > > that some notifications would fail. Therefore, let's re-order the sequence
> > > > in psci_enter_domain_idle_state(), so cpu_pm_enter() gets called prior
> > > > pm_runtime_put_sync().
> > > >
> > >
> > > More details on why notifications fail ?
> >
> > Well, at this moment this is more of a hypothetical issue as there is
> > no last-man notification sent/used yet.
> >
>
> Ah OK.
>
> > However, typically we would call cpu_cluster_pm_enter() in the path as
> > when the psci_pd_power_off() is called (for psci PM domains), when a
> > valid domain state has been found.
> >
>
> Please don't use cpu_cluster_pm_enter. I thought the whole idea of genpd
> will remove the notion of cluster and we will never need to use
> cpu_cluster_pm_*
>
> > This means, we would violate the cpu_cluster_pm_enter() API, as it's
> > clearly stated in its corresponding function header, that
> > cpu_pm_enter() needs to be called first (and that's also how others
> > are currently using it).
> >
>
> Ah so, it was just for use of cpu_cluster_pm_* which I would like to
> avoid. That was one of the motivation for using genpd I thought.
>
> > Note that, I am currently exploring whether we shall call
> > cpu_cluster_pm_enter|exit() at all, or whether we can use some other
> > new genpd mechanism to accomplish the similar thing.
> >
>
> Good, you do think so.
Okay, let's see where things go. I will keep you posted.
> > >
> > > > Fixes: ce85aef570df ("cpuidle: psci: Manage runtime PM in the idle path")
> > > > Reported-by: Lina Iyer <ilina@codeaurora.org>
> > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > > > ---
> > > > drivers/cpuidle/cpuidle-psci.c | 8 +++++++-
> > > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/cpuidle/cpuidle-psci.c b/drivers/cpuidle/cpuidle-psci.c
> > > > index bae9140a65a5..d0fb585073c6 100644
> > > > --- a/drivers/cpuidle/cpuidle-psci.c
> > > > +++ b/drivers/cpuidle/cpuidle-psci.c
> > > > @@ -58,6 +58,10 @@ static int psci_enter_domain_idle_state(struct cpuidle_device *dev,
> > > > u32 state;
> > > > int ret;
> > > >
> > > > + ret = cpu_pm_enter();
> > > > + if (ret)
> > > > + return -1;
> > > > +
> > >
> > > This change is ignoring the retention case psci_enter_state handles and
> > > this may affect performance by doing unnecessary save/restore.
> >
> > This was already the case before. CPU_PM_CPU_IDLE_ENTER_PARAM() ends
> > up always setting "is_retention" to 0, when __CPU_PM_CPU_IDLE_ENTER()
> > is called.
> >
>
> Ah OK, I recall now, sorry for the noise.
No worries, thanks for reviewing.
That said, are you fine with Rafel queuing this then?
Kind regards
Uffe
_______________________________________________
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 0/2] iommu: arm-smmu: Add support for early direct mappings
From: bjorn.andersson @ 2020-05-14 19:32 UTC (permalink / raw)
To: Thierry Reding, Robin Murphy, Will Deacon
Cc: linux-tegra, linux-arm-msm, Joerg Roedel, iommu, linux-arm-kernel
In-Reply-To: <20200228025700.GA856087@builder>
On Thu 27 Feb 18:57 PST 2020, Bjorn Andersson wrote:
Rob, Will, we're reaching the point where upstream has enough
functionality that this is becoming a critical issue for us.
E.g. Lenovo Yoga C630 is lacking this and a single dts patch to boot
mainline with display, GPU, WiFi and audio working and the story is
similar on several devboards.
As previously described, the only thing I want is the stream mapping
related to the display controller in place, either with the CB with
translation disabled or possibly with a way to specify the framebuffer
region (although this turns out to mess things up in the display
driver...)
I did pick this up again recently and concluded that by omitting the
streams for the USB controllers causes an instability issue seen on one
of the controller to disappear. So I would prefer if we somehow could
have a mechanism to only pick the display streams and the context
allocation for this.
Can you please share some pointers/insights/wishes for how we can
conclude on this subject?
PS. The list of devices specified
https://lore.kernel.org/linux-arm-msm/cover.1587407458.git.saiprakash.ranjan@codeaurora.org/
covers this need as well, if that matters...
Thanks,
Bjorn
> On Mon 09 Dec 07:07 PST 2019, Thierry Reding wrote:
>
> > From: Thierry Reding <treding@nvidia.com>
> >
>
> Sorry for the slow response on this, finally got the time to go through
> this in detail and try it out on some Qualcomm boards.
>
> > On some platforms, the firmware will setup hardware to read from a given
> > region of memory. One such example is a display controller that is
> > scanning out a splash screen from physical memory.
> >
>
> This particular use case is the one that we need to figure out for
> Qualcomm devices as well; on some devices it's a simple splash screen
> (that on many devices can be disabled), but for others we have EFIFB
> on the display and no (sane) means to disable this.
>
> > During Linux' boot process, the ARM SMMU will configure all contexts to
> > fault by default. This means that memory accesses that happen by an SMMU
> > master before its driver has had a chance to properly set up the IOMMU
> > will cause a fault. This is especially annoying for something like the
> > display controller scanning out a splash screen because the faults will
> > result in the display controller getting bogus data (all-ones on Tegra)
> > and since it repeatedly scans that framebuffer, it will keep triggering
> > such faults and spam the boot log with them.
> >
>
> As my proposed patches indicated, the Qualcomm platform boots with
> stream mapping setup for the hardware used by the bootloader, but
> relying on the associated context banks not being enabled.
>
> USFCFG in SCR0 is set and any faults resulting of this will trap into
> secure world and the device will be reset.
>
> > In order to work around such problems, scan the device tree for IOMMU
> > masters and set up a special identity domain that will map 1:1 all of
> > the reserved regions associated with them. This happens before the SMMU
> > is enabled, so that the mappings are already set up before translations
> > begin.
> >
> > One thing that was pointed out earlier, and which I don't have a good
> > idea on how to solve it, is that the early identity domain is not
> > discarded. The assumption is that the standard direct mappings code of
> > the IOMMU framework will replace the early identity domain once devices
> > are properly attached to domains, but we don't have a good point in time
> > when it would be safe to remove the early identity domain.
> >
> > One option that I can think of would be to create an early identity
> > domain for each master and inherit it when that master is attached to
> > the domain later on, but that seems rather complicated from an book-
> > keeping point of view and tricky because we need to be careful not to
> > map regions twice, etc.
> >
>
> The one concern I ran into with this approach (after resolving below
> issues) is that when the display driver probes a new domain will be
> created automatically and I get a stream of "Unhandled context fault" in
> the log until the driver has mapped the framebuffer in the newly
> allocated context.
>
> This is normally not a problem, as we seem to be able to do this
> initialization in a few frames, but for the cases where the display
> driver probe defer this is a problem.
>
> But at least these devices doesn't reboot, so this is way better than the
> current state.
>
> > Any good ideas on how to solve this? It'd also be interesting to see if
> > there's a more generic way of doing this. I know that something like
> > this isn't necessary on earlier Tegra SoCs with the custom Tegra SMMU
> > because translations are only enabled when the devices are attached to a
> > domain. I'm not sure about other IOMMUs, but in the absence of a struct
> > device, I suspect that we can't really do anything really generic that
> > would work across drivers.
> >
>
> As I indicated above I managed to get this working on the boards we have
> that uses the arm-smmu driver.
>
> ## SDM845
> Booting the SDM845 shows the following register stream mapping register
> content:
> SMR(0): 0x80080880 S2CR(0): 0x0
> SMR(1): 0x80080c80 S2CR(1): 0x0
> SMR(2): 0x800f00a0 S2CR(2): 0x1
> SMR(3): 0x800f00c0 S2CR(3): 0x1
> SMR(4): 0x800f00e0 S2CR(4): 0x2
> SMR(5): 0x800f0100 S2CR(5): 0x2
> SMR(6): 0x0 S2CR(6): 0x0
> SMR(7): 0x0 S2CR(7): 0x0
> SMR(8): 0x0 S2CR(8): 0x200ff
> SMR(9): 0x0 S2CR(9): 0x200ff
> ...
>
> Here stream 0 and 1 (SID 0x880 and 0xc80) are the display streams, the
> remainder are related to storage and USB - which afaict doesn't need to be
> maintained.
>
> As the display uses context bank 0, using this as the identity bank results in
> a couple of occurrences of:
> Unhandled context fault: fsr=0x402, iova=0x9da00000, fsynr=0x370020, cbfrsynra=0x880, cb=0
>
> Which we survive, but as we reach arm_smmu_device_reset() to flush out the new
> stream mapping we start by writing S2CR(0) = 0, then SMR(0) = 0x800810a0. So
> until SMR(4) is written we're lacking a valid stream mapping for the display,
> and hence if the screen does refresh in during time period the device reboots.
>
>
> In addition to this, the iommu_iova_to_phys() you perform in the mapping loop
> results in a large number of "translation fault!" printouts from
> arm_smmu_iova_to_phys_hard().
>
> ## SM8150
> Boots with the following stream mapping:
> SMR(0): 0x800006a0 S2CR(0): 0x0
> SMR(1): 0x800006c0 S2CR(1): 0x0
> SMR(2): 0x80000300 S2CR(2): 0x1
> SMR(3): 0x84200800 S2CR(3): 0x2
> SMR(4): 0x0 S2CR(4): 0x0
> SMR(5): 0x0 S2CR(5): 0x0
> SMR(6): 0x0 S2CR(6): 0x200ff
> SMR(7): 0x0 S2CR(7): 0x200ff
> ...
>
> Here stream 3 (sid 0x800) is the display stream.
>
> Mapping the various memory regions into the first context works fine, but
> unless the display stream happens to be allocated to stream 3 (e.g. it always
> ends up in slot 1 with my current DT) the board reboots shortly after we start
> writing out the SMRs. I've not yet figured out why the board faults because of
> the move to an earlier SMR index. (Perhaps because we clear the previously used
> display SMR valid bit?)
>
>
> ## Conclusions
> Both of these platforms indicates that moving the stream mapping around is
> going to cause issues, so inspired by my proposal I added below snippet right
> before the call to arm_smmu_setup_identity(), in order to populate the stream
> mapping selection.
>
> for (i = 0; i < smmu->num_mapping_groups; i++) {
> smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
> smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr);
> smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
> smmu->smrs[i].valid = !!(smr & ARM_SMMU_SMR_VALID);
> }
>
> With this both boards boots fine, but I know Will had reservations wrt trusting
> these values. Perhaps we could use the read back values (with some sanity
> checking) only for setting up identity mapping?
>
>
> With this I also tested booting MSM8996 (the db820c board) and except for
> spending about 75 seconds printing below error in the kernel log during boot
> things seems to be functional.
>
> [ 96.670723] arm-smmu b40000.iommu: translation fault!
> [ 96.675038] arm-smmu b40000.iommu: PAR = 0x300000203
>
>
> Removing the call to iommu_iova_to_phys() in the mapping loop (as I know
> that I don't have any memory regions with multiple clients) solves the
> log spamming and all three boards seems to be functional.
>
> Regards,
> Bjorn
>
> > Thierry
> >
> > Thierry Reding (2):
> > iommu: arm-smmu: Extract arm_smmu_of_parse()
> > iommu: arm-smmu: Add support for early direct mappings
> >
> > drivers/iommu/arm-smmu.c | 195 +++++++++++++++++++++++++++++++++++++--
> > drivers/iommu/arm-smmu.h | 2 +
> > 2 files changed, 189 insertions(+), 8 deletions(-)
> >
> > --
> > 2.23.0
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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: stmmac: fix num_por initialization
From: David Miller @ 2020-05-14 19:49 UTC (permalink / raw)
To: vkoul
Cc: rahulak, alexandre.torgue, linux-arm-msm, linux-kernel,
bjorn.andersson, joabreu, mcoquelin.stm32, netdev,
peppe.cavallaro, linux-stm32, linux-arm-kernel
In-Reply-To: <20200514062836.190194-1-vkoul@kernel.org>
From: Vinod Koul <vkoul@kernel.org>
Date: Thu, 14 May 2020 11:58:36 +0530
> Driver missed initializing num_por which is por values that driver
> configures to hardware. In order to get this values, add a new structure
> ethqos_emac_driver_data which holds por and num_por values and populate
> that in driver probe.
>
> Fixes: a7c30e62d4b8 ("net: stmmac: Add driver for Qualcomm ethqos")
> Reported-by: Rahul Ankushrao Kawadgave <rahulak@qti.qualcomm.com>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
Applied and queued up for -stable, thanks.
_______________________________________________
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 00/15] mediatek: add support for MediaTek Ethernet MAC
From: David Miller @ 2020-05-14 19:56 UTC (permalink / raw)
To: brgl
Cc: edwin.peer, devicetree, bgolaszewski, stephane.leprovost, arnd,
corbet, netdev, sean.wang, linux-kernel, pedro.tsai, fparent,
robh+dt, linux-mediatek, andrew.perepech, john, matthias.bgg,
kuba, Mark-MC.Lee, linux-arm-kernel, hkallweit1
In-Reply-To: <20200514075942.10136-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Thu, 14 May 2020 09:59:27 +0200
> Next we do some cleanup of the mediatek ethernet drivers directory and update
> the devres documentation with existing networking devres helpers.
I don't agree with the new devres stuff.
You have to be very careful with the ordering of when you map/unmap
registers, free up anciliary resources, etc. in relationship to when
the netdev unregister happens.
Please submit this driver without these controversial devres changes,
and then you can submit and discuss those changes separately later.
Thanks.
_______________________________________________
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 v2 01/10] ARM: Remove redundant COMMON_CLK selects
From: Stephen Boyd @ 2020-05-14 19:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Arnd Bergmann, Alexander Shiyan, linux-clk, Russell King,
linux-kernel, Lubomir Rintel, Manivannan Sadhasivam,
Andreas Färber, linux-arm-kernel
In-Reply-To: <20200409064416.83340-2-sboyd@kernel.org>
Quoting Stephen Boyd (2020-04-08 23:44:07)
> The mulitplatform config already selects COMMON_CLK, so selecting it
> again is not useful. Remove these selects from ARM platforms that are
> part of the multiplatform build.
>
> Reviewed-by: "Andreas Färber" <afaerber@suse.de> # actions
> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> # actions
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Alexander Shiyan <shc_work@mail.ru>
> Cc: Lubomir Rintel <lkundrak@v3.sk>
> Cc: <linux-arm-kernel@lists.infradead.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
Applied to clk-next
_______________________________________________
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 v2 02/10] ARM: Remove redundant CLKDEV_LOOKUP selects
From: Stephen Boyd @ 2020-05-14 19:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Arnd Bergmann, Russell King, linux-kernel, Tony Prisk, linux-clk,
linux-arm-kernel
In-Reply-To: <20200409064416.83340-3-sboyd@kernel.org>
Quoting Stephen Boyd (2020-04-08 23:44:08)
> These platforms select COMMON_CLK indirectly through use of the
> ARCH_MULTIPLATFORM config option that they depend on implicitly via some
> V7/V6/V5 multi platform config option. The COMMON_CLK config option
> already selects CLKDEV_LOOKUP so it's redundant to have this selected
> again.
>
> Cc: Tony Prisk <linux@prisktech.co.nz>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: <linux-arm-kernel@lists.infradead.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
Applied to clk-next
_______________________________________________
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 v2 03/10] arm64: tegra: Remove redundant CLKDEV_LOOKUP selects
From: Stephen Boyd @ 2020-05-14 19:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Paul Walmsley, Arnd Bergmann, Catalin Marinas, linux-kernel,
Thierry Reding, Will Deacon, linux-clk, linux-arm-kernel
In-Reply-To: <20200409064416.83340-4-sboyd@kernel.org>
Quoting Stephen Boyd (2020-04-08 23:44:09)
> The arm64 architecture selects COMMON_CLK at the toplevel ARM64 config.
> The COMMON_CLK config option already selects CLKDEV_LOOKUP so it's
> redundant to have this selected again for the Tegra specific config.
>
> Cc: Paul Walmsley <paul@pwsan.com>
> Acked-by: Thierry Reding <treding@nvidia.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: <linux-arm-kernel@lists.infradead.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
Applied to clk-next
_______________________________________________
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 v2 07/10] clk: Allow the common clk framework to be selectable
From: Stephen Boyd @ 2020-05-14 19:57 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Rich Felker, Yoshinori Sato, Arnd Bergmann, linux-sh, linux-mips,
linux-kernel, Jiaxun Yang, Aurelien Jacquiot, linux-m68k,
Mark Brown, Geert Uytterhoeven, Mark Salter, Russell King,
Thomas Bogendoerfer, Guan Xuetao, linux-clk, linux-arm-kernel,
linux-c6x-dev
In-Reply-To: <20200409064416.83340-8-sboyd@kernel.org>
Quoting Stephen Boyd (2020-04-08 23:44:13)
> Enable build testing and configuration control of the common clk
> framework so that more code coverage and testing can be done on the
> common clk framework across various architectures. This also nicely
> removes the requirement that architectures must select the framework
> when they don't use it in architecture code.
>
> There's one snag with doing this, and that's making sure that randconfig
> builds don't select this option when some architecture or platform
> implements 'struct clk' outside of the common clk framework. Introduce a
> new config option 'HAVE_LEGACY_CLK' to indicate those platforms that
> haven't migrated to the common clk framework and therefore shouldn't be
> allowed to select this new config option. Also add a note that we hope
> one day to remove this config entirely.
>
> Based on a patch by Mark Brown <broonie@kernel.org>.
>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Aurelien Jacquiot <jacquiot.aurelien@gmail.com>
> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
> Cc: Guan Xuetao <gxt@pku.edu.cn>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: <linux-mips@vger.kernel.org>
> Cc: <linux-c6x-dev@linux-c6x.org>
> Cc: <linux-m68k@lists.linux-m68k.org>
> Cc: <linux-arm-kernel@lists.infradead.org>
> Cc: <linux-sh@vger.kernel.org>
> Link: https://lore.kernel.org/r/1470915049-15249-1-git-send-email-broonie@kernel.org
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
Applied to clk-next
_______________________________________________
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