* Re: [PATCH RFC 1/2] clk: introduce clk_invalidate_rate()
From: Neil Armstrong @ 2019-09-27 6:40 UTC (permalink / raw)
To: Stephen Boyd, jbrunet, mturquette
Cc: linux-amlogic, linux-clk, linux-arm-kernel, linux-kernel
In-Reply-To: <20190927001425.DFDC7207FF@mail.kernel.org>
On 27/09/2019 02:14, Stephen Boyd wrote:
> Quoting Neil Armstrong (2019-09-19 03:25:17)
>> This introduces the clk_invalidate_rate() call used to recalculate the
>> rate and parent tree of a particular clock if it's known that the
>> underlying registers set has been altered by the firmware, like from
>> a suspend/resume handler running in trusted cpu mode.
>>
>> The call refreshes the actual parent and when changed, instructs CCF
>> the parent has changed. Finally the call will recalculate the rate of
>> each part of the tree to make sure the CCF cached tree is in sync with
>> the hardware.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>
> The knee-jerk reaction to these patches is that it shouldn't be a
> consumer API (i.e. taking a struct clk) but a provider API (i.e. taking
> a struct clk_hw). I haven't looked in any more detail but just know that
> it's a non-starter to be a consumer based API because we don't want
> random consumers out there to be telling the CCF or provider drivers
> that some clk has lost state and needs to be "refreshed".
>
Totally agree, I hesitated and obviously did the wrong choice, but
this is a nit, the main algorithm is not tied to the API level.
Should I resend it with clk_hw ? the difference will be small and
the main subject is the resync algorithm.
Neil
_______________________________________________
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] dt-bindings: timer: Use defines instead of numbers in Exynos MCT examples
From: Krzysztof Kozlowski @ 2019-09-27 6:52 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Mark Rutland, devicetree, linux-samsung-soc, Daniel Lezcano,
linux-kernel, Rob Herring, Kukjin Kim, Thomas Gleixner,
linux-arm-kernel
In-Reply-To: <fc0809b0-1e6a-0564-75d9-0ccb14d2826c@samsung.com>
On Fri, Sep 27, 2019 at 08:36:47AM +0200, Marek Szyprowski wrote:
> Hi Krzysztof,
>
> > timer@10050000 {
> > compatible = "samsung,exynos4412-mct";
> > reg = <0x10050000 0x800>;
> >
> > - interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> > - <0 42 0>;
> > + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
>
> the last one should be GIC_PPI
>
> > };
> >
> > - |
> > // In this example, the IP contains four local timers, but using
> > // a per-processor interrupt to handle them. All the local timer
> > // interrupts are specified.
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> >
> > timer@10050000 {
> > compatible = "samsung,exynos4412-mct";
> > reg = <0x10050000 0x800>;
> >
> > - interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> > - <0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
> > + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
>
> again, last 4 entries should use GIC_PPI
Indeed, thanks for noticing it.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: ov5695: Add suport for registering sensor-related
From: Dongchun Zhu @ 2019-09-27 7:18 UTC (permalink / raw)
To: mchehab, andriy.shevchenko, robh+dt, mark.rutland, sakari.ailus,
drinkcat, tfiga, matthias.bgg, bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
Hello,
This series modifies the interface of async register V4L2 sub-device invoked in probe function for OV5695 CMOS sensor.
The Omnivision OV5695 image sensor would be used in camera features on CrOS application.
5.0 Mega Pixel MIPI Camera Mdoule also supports auto-focus control (AFC) with embedded AF VCM Driver.
Here we use v4l2_async_register_subdev_sensor_common() instead of v4l2_async_register_subdev()
to register a sensor sub-device to the asynchronous sub-device framework and parse set up
common sensor-related devices, such as actuator.
This function is just like v4l2_async_register_subdev() with the exception that calling it will also parse
firmware interfaces for remote references using v4l2_async_notifier_parse_fwnode_sensor_common()
and registers the async sub-devices.
After applying this change, we can see the VCM move when changing the scene.
Dongchun Zhu (1):
media: i2c: ov5695: Modify the function of async register subdev
drivers/media/i2c/ov5695.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: i2c: ov5695: Modify the function of async register subdev related devices
From: Dongchun Zhu @ 2019-09-27 7:18 UTC (permalink / raw)
To: mchehab, andriy.shevchenko, robh+dt, mark.rutland, sakari.ailus,
drinkcat, tfiga, matthias.bgg, bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
linux-media
In-Reply-To: <20190927071824.18675-1-dongchun.zhu@mediatek.com>
This patch adds support for registering a sensor sub-device to the async sub-device framework and parse set up common
sensor related devices such as actuator/VCM.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
drivers/media/i2c/ov5695.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov5695.c b/drivers/media/i2c/ov5695.c
index e65a943..b6ee62c 100644
--- a/drivers/media/i2c/ov5695.c
+++ b/drivers/media/i2c/ov5695.c
@@ -1328,7 +1328,7 @@ static int ov5695_probe(struct i2c_client *client,
goto err_power_off;
#endif
- ret = v4l2_async_register_subdev(sd);
+ ret = v4l2_async_register_subdev_sensor_common(sd);
if (ret) {
dev_err(dev, "v4l2 async register subdev failed\n");
goto err_clean_entity;
--
2.9.2
_______________________________________________
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: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API
From: Jason A. Donenfeld @ 2019-09-27 7:20 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Catalin Marinas, Herbert Xu, Arnd Bergmann, Ard Biesheuvel,
Greg KH, Eric Biggers, Samuel Neves, Will Deacon,
Linux Crypto Mailing List, Marc Zyngier, Dan Carpenter,
Linus Torvalds, David Miller, linux-arm-kernel
In-Reply-To: <CALCETrUrbSGNfo=g=PS4=t1zzXqGAHSs5oUL46LwMgu+2aVh1Q@mail.gmail.com>
Hey Andy,
Thanks for weighing in.
> inlining. I'd be surprised for chacha20. If you really want inlining
> to dictate the overall design, I think you need some real numbers for
> why it's necessary. There also needs to be a clear story for how
> exactly making everything inline plays with the actual decision of
> which implementation to use.
Take a look at my description for the MIPS case: when on MIPS, the
arch code is *always* used since it's just straight up scalar
assembly. In this case, the chacha20_arch function *never* returns
false [1], which means it's always included [2], so the generic
implementation gets optimized out, saving disk and memory, which I
assume MIPS people care about.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/tree/lib/zinc/chacha20/chacha20-mips-glue.c?h=jd/wireguard#n13
[2] https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/tree/lib/zinc/chacha20/chacha20.c?h=jd/wireguard#n118
I'm fine with considering this a form of "premature optimization",
though, and ditching the motivation there.
On Thu, Sep 26, 2019 at 11:37 PM Andy Lutomirski <luto@kernel.org> wrote:
> My suggestion from way back, which is at
> least a good deal of the way toward being doable, is to do static
> calls. This means that the common code will call out to the arch code
> via a regular CALL instruction and will *not* inline the arch code.
> This means that the arch code could live in its own module, it can be
> selected at boot time, etc.
Alright, let's do static calls, then, to deal with the case of going
from the entry point implementation in lib/zinc (or lib/crypto, if you
want, Ard) to the arch-specific implementation in arch/${ARCH}/crypto.
And then within each arch, we can keep it simple, since everything is
already in the same directory.
Sound good?
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net 5/8] net: stmmac: Correctly take timestamp for PTPv2
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
The case for PTPV2_EVENT requires event packets to be captured so add
this setting to the list of enabled captures.
Fixes: 891434b18ec0 ("stmmac: add IEEE PTPv1 and PTPv2 support.")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d3232738fb25..31a237ec73bc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -629,6 +629,7 @@ static int stmmac_hwtstamp_set(struct net_device *dev, struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+ ts_event_en = PTP_TCR_TSEVNTENA;
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
ptp_over_ethernet = PTP_TCR_TSIPENA;
--
2.7.4
_______________________________________________
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 net 1/8] net: stmmac: xgmac: Not all Unicast addresses may be available
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
Some setups may not have all Unicast addresses filters available. Let's
check this before trying to setup filters.
Fixes: 0efedbf11f07 ("net: stmmac: xgmac: Fix XGMAC selftests")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 2b277b2c586b..6d8ac2ef4fc2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -472,7 +472,7 @@ static void dwxgmac2_set_filter(struct mac_device_info *hw,
dwxgmac2_set_mchash(ioaddr, mc_filter, mcbitslog2);
/* Handle multiple unicast addresses */
- if (netdev_uc_count(dev) > XGMAC_ADDR_MAX) {
+ if (netdev_uc_count(dev) > hw->unicast_filter_entries) {
value |= XGMAC_FILTER_PR;
} else {
struct netdev_hw_addr *ha;
--
2.7.4
_______________________________________________
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 net 3/8] net: stmmac: selftests: Always use max DMA size in Jumbo Test
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
Although some XGMAC setups support frames larger than DMA size, some of
them may not. As we can't know before-hand which ones support let's use
the maximum DMA buffer size in the Jumbo Tests.
User can always reconfigure the MTU to achieve larger frames.
Fixes: 427849e8c37f ("net: stmmac: selftests: Add Jumbo Frame tests")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index 5f66f6161629..cc76a42c7466 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -1564,10 +1564,6 @@ static int __stmmac_test_jumbo(struct stmmac_priv *priv, u16 queue)
struct stmmac_packet_attrs attr = { };
int size = priv->dma_buf_sz;
- /* Only XGMAC has SW support for multiple RX descs in same packet */
- if (priv->plat->has_xgmac)
- size = priv->dev->max_mtu;
-
attr.dst = priv->dev->dev_addr;
attr.max_size = size - ETH_FCS_LEN;
attr.queue_mapping = queue;
--
2.7.4
_______________________________________________
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 net 8/8] net: stmmac: xgmac: Fix RSS not writing all Keys to HW
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, Nick Desaulniers,
linux-kernel, linux-stm32, Maxime Coquelin, Giuseppe Cavallaro,
David S. Miller, linux-arm-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
The sizeof(cfg->key) is != ARRAY_SIZE(cfg->key). Fix it.
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Fixes: 76067459c686 ("net: stmmac: Implement RSS and enable it in XGMAC core")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: Nick Desaulniers <ndesaulniers@google.com>
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 6d8ac2ef4fc2..4a1f52474dbc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -533,7 +533,7 @@ static int dwxgmac2_rss_configure(struct mac_device_info *hw,
return 0;
}
- for (i = 0; i < (sizeof(cfg->key) / sizeof(u32)); i++) {
+ for (i = 0; i < (ARRAY_SIZE(cfg->key) / sizeof(u32)); i++) {
ret = dwxgmac2_rss_write_reg(ioaddr, true, i, cfg->key[i]);
if (ret)
return ret;
--
2.7.4
_______________________________________________
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 net 4/8] net: stmmac: dwmac4: Always update the MAC Hash Filter
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
We need to always update the MAC Hash Filter so that previous entries
are invalidated.
Found out while running stmmac selftests.
Fixes: b8ef7020d6e5 ("net: stmmac: add support for hash table size 128/256 in dwmac4")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 9b4b5f69fc02..2cb9c53f93b8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -401,8 +401,11 @@ static void dwmac4_set_filter(struct mac_device_info *hw,
int numhashregs = (hw->multicast_filter_bins >> 5);
int mcbitslog2 = hw->mcast_bits_log2;
unsigned int value;
+ u32 mc_filter[8];
int i;
+ memset(mc_filter, 0, sizeof(mc_filter));
+
value = readl(ioaddr + GMAC_PACKET_FILTER);
value &= ~GMAC_PACKET_FILTER_HMC;
value &= ~GMAC_PACKET_FILTER_HPF;
@@ -416,16 +419,13 @@ static void dwmac4_set_filter(struct mac_device_info *hw,
/* Pass all multi */
value |= GMAC_PACKET_FILTER_PM;
/* Set all the bits of the HASH tab */
- for (i = 0; i < numhashregs; i++)
- writel(0xffffffff, ioaddr + GMAC_HASH_TAB(i));
+ memset(mc_filter, 0xff, sizeof(mc_filter));
} else if (!netdev_mc_empty(dev)) {
struct netdev_hw_addr *ha;
- u32 mc_filter[8];
/* Hash filter for multicast */
value |= GMAC_PACKET_FILTER_HMC;
- memset(mc_filter, 0, sizeof(mc_filter));
netdev_for_each_mc_addr(ha, dev) {
/* The upper n bits of the calculated CRC are used to
* index the contents of the hash table. The number of
@@ -440,10 +440,11 @@ static void dwmac4_set_filter(struct mac_device_info *hw,
*/
mc_filter[bit_nr >> 5] |= (1 << (bit_nr & 0x1f));
}
- for (i = 0; i < numhashregs; i++)
- writel(mc_filter[i], ioaddr + GMAC_HASH_TAB(i));
}
+ for (i = 0; i < numhashregs; i++)
+ writel(mc_filter[i], ioaddr + GMAC_HASH_TAB(i));
+
value |= GMAC_PACKET_FILTER_HPF;
/* Handle multiple unicast addresses */
--
2.7.4
_______________________________________________
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 net 6/8] net: stmmac: Do not stop PHY if WoL is enabled
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
If WoL is enabled we can't really stop the PHY, otherwise we will not
receive the WoL packet. Fix this by telling phylink that only the MAC is
down and only stop the PHY if WoL is not enabled.
Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 31a237ec73bc..843d53e084b7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4718,9 +4718,7 @@ int stmmac_suspend(struct device *dev)
mutex_lock(&priv->lock);
- rtnl_lock();
- phylink_stop(priv->phylink);
- rtnl_unlock();
+ phylink_mac_change(priv->phylink, false);
netif_device_detach(ndev);
stmmac_stop_all_queues(priv);
@@ -4735,6 +4733,10 @@ int stmmac_suspend(struct device *dev)
stmmac_pmt(priv, priv->hw, priv->wolopts);
priv->irq_wake = 1;
} else {
+ rtnl_lock();
+ phylink_stop(priv->phylink);
+ rtnl_unlock();
+
stmmac_mac_set(priv, priv->ioaddr, false);
pinctrl_pm_select_sleep_state(priv->device);
/* Disable clock in case of PWM is off */
@@ -4825,9 +4827,13 @@ int stmmac_resume(struct device *dev)
stmmac_start_all_queues(priv);
- rtnl_lock();
- phylink_start(priv->phylink);
- rtnl_unlock();
+ if (!device_may_wakeup(priv->device)) {
+ rtnl_lock();
+ phylink_start(priv->phylink);
+ rtnl_unlock();
+ }
+
+ phylink_mac_change(priv->phylink, true);
mutex_unlock(&priv->lock);
--
2.7.4
_______________________________________________
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 net 0/8] net: stmmac: Fixes for -net
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
Misc fixes for -net tree. More info in commit logs.
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
Jose Abreu (8):
net: stmmac: xgmac: Not all Unicast addresses may be available
net: stmmac: xgmac: Detect Hash Table size dinamically
net: stmmac: selftests: Always use max DMA size in Jumbo Test
net: stmmac: dwmac4: Always update the MAC Hash Filter
net: stmmac: Correctly take timestamp for PTPv2
net: stmmac: Do not stop PHY if WoL is enabled
net: stmmac: xgmac: Disable the Timestamp interrupt by default
net: stmmac: xgmac: Fix RSS not writing all Keys to HW
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 13 +++++++------
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 4 ++--
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +++++++++++++------
.../net/ethernet/stmicro/stmmac/stmmac_selftests.c | 4 ----
6 files changed, 25 insertions(+), 19 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net 7/8] net: stmmac: xgmac: Disable the Timestamp interrupt by default
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
We don't use it anyway as XGMAC only supports polling for timestamp (in
current SW implementation). This greatly reduces the system load by
reducing the number of interrupts.
Fixes: 2142754f8b9c ("net: stmmac: Add MAC related callbacks for XGMAC2")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index f7eb06f8fb37..99037386080a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -84,7 +84,7 @@
#define XGMAC_TSIE BIT(12)
#define XGMAC_LPIIE BIT(5)
#define XGMAC_PMTIE BIT(4)
-#define XGMAC_INT_DEFAULT_EN (XGMAC_LPIIE | XGMAC_PMTIE | XGMAC_TSIE)
+#define XGMAC_INT_DEFAULT_EN (XGMAC_LPIIE | XGMAC_PMTIE)
#define XGMAC_Qx_TX_FLOW_CTRL(x) (0x00000070 + (x) * 4)
#define XGMAC_PT GENMASK(31, 16)
#define XGMAC_PT_SHIFT 16
--
2.7.4
_______________________________________________
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 net 2/8] net: stmmac: xgmac: Detect Hash Table size dinamically
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
Since commit b8ef7020d6e5 ("net: stmmac: add support for hash table size
128/256 in dwmac4"), we can detect the Hash Table dinamically.
Let's implement this feature in XGMAC cores and fix possible setups that
don't support the maximum size for Hash Table.
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 1 +
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 5923ca62d793..f7eb06f8fb37 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -122,6 +122,7 @@
#define XGMAC_HWFEAT_GMIISEL BIT(1)
#define XGMAC_HW_FEATURE1 0x00000120
#define XGMAC_HWFEAT_L3L4FNUM GENMASK(30, 27)
+#define XGMAC_HWFEAT_HASHTBLSZ GENMASK(25, 24)
#define XGMAC_HWFEAT_RSSEN BIT(20)
#define XGMAC_HWFEAT_TSOEN BIT(18)
#define XGMAC_HWFEAT_SPHEN BIT(17)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index 53c4a40d8386..965cbe3e6f51 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -380,6 +380,7 @@ static void dwxgmac2_get_hw_feature(void __iomem *ioaddr,
/* MAC HW feature 1 */
hw_cap = readl(ioaddr + XGMAC_HW_FEATURE1);
dma_cap->l3l4fnum = (hw_cap & XGMAC_HWFEAT_L3L4FNUM) >> 27;
+ dma_cap->hash_tb_sz = (hw_cap & XGMAC_HWFEAT_HASHTBLSZ) >> 24;
dma_cap->rssen = (hw_cap & XGMAC_HWFEAT_RSSEN) >> 20;
dma_cap->tsoen = (hw_cap & XGMAC_HWFEAT_TSOEN) >> 18;
dma_cap->sphen = (hw_cap & XGMAC_HWFEAT_SPHEN) >> 17;
--
2.7.4
_______________________________________________
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] PCI: aardvark: Don't rely on jiffies while holding spinlock
From: Remi Pommarel @ 2019-09-27 8:25 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Bjorn Helgaas, linux-pci, Lorenzo Pieralisi, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190925113351.0b53d2e9@windsurf>
Hi Thomas,
Thanks for the review.
On Wed, Sep 25, 2019 at 11:33:51AM +0200, Thomas Petazzoni wrote:
> Hello Remi,
>
> Thanks for the patch, I have a few comments/questions below.
>
> On Sun, 1 Sep 2019 16:23:03 +0200
> Remi Pommarel <repk@triplefau.lt> wrote:
>
> > diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
> > index fc0fe4d4de49..1fa6d04ad7aa 100644
> > --- a/drivers/pci/controller/pci-aardvark.c
> > +++ b/drivers/pci/controller/pci-aardvark.c
> > @@ -175,7 +175,8 @@
> > (PCIE_CONF_BUS(bus) | PCIE_CONF_DEV(PCI_SLOT(devfn)) | \
> > PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where))
> >
> > -#define PIO_TIMEOUT_MS 1
> > +#define PIO_RETRY_CNT 10
> > +#define PIO_RETRY_DELAY 100 /* 100 us*/
> >
> > #define LINK_WAIT_MAX_RETRIES 10
> > #define LINK_WAIT_USLEEP_MIN 90000
> > @@ -383,17 +384,16 @@ static void advk_pcie_check_pio_status(struct advk_pcie *pcie)
> > static int advk_pcie_wait_pio(struct advk_pcie *pcie)
> > {
> > struct device *dev = &pcie->pdev->dev;
> > - unsigned long timeout;
> > + size_t i;
>
> Is it common to use a size_t for a loop counter ?
It was for me but seem not to be used that much. I can change that to an
int.
> >
> > - timeout = jiffies + msecs_to_jiffies(PIO_TIMEOUT_MS);
> > -
> > - while (time_before(jiffies, timeout)) {
> > + for (i = 0; i < PIO_RETRY_CNT; ++i) {
>
> I find it more common to use post-increment for loop counters rather
> than pre-increment, but that's a really nitpick and I don't care much.
>
Will change that to post-increment.
> > u32 start, isr;
> >
> > start = advk_readl(pcie, PIO_START);
> > isr = advk_readl(pcie, PIO_ISR);
> > if (!start && isr)
> > return 0;
> > + udelay(PIO_RETRY_DELAY);
>
> But the bigger issue is that this change causes a 100us delay at
> *every* single PIO read or write operation.
>
> Indeed, at the first iteration of the loop, the PIO operation has not
> completed, so you will always hit the udelay(100) a first time, and
> it's only at the second iteration of the loop that the PIO operation
> has completed (for successful PIO operations of course, which don't hit
> the timeout).
>
> I took a measurement around wait_pio() with sched_clock before and
> after the patch. Before the patch, I have measurements like this (in
> nanoseconds):
>
> [ 1.562801] time = 6000
> [ 1.565310] time = 6000
> [ 1.567809] time = 6080
> [ 1.570327] time = 6080
> [ 1.572836] time = 6080
> [ 1.575339] time = 6080
> [ 1.577858] time = 2720
> [ 1.580366] time = 2720
> [ 1.582862] time = 6000
> [ 1.585377] time = 2720
> [ 1.587890] time = 2720
> [ 1.590393] time = 2720
>
> So it takes a few microseconds for each PIO operation.
>
> With your patch applied:
>
> [ 2.267291] time = 101680
> [ 2.270002] time = 100880
> [ 2.272852] time = 100800
> [ 2.275573] time = 100880
> [ 2.278285] time = 100800
> [ 2.281005] time = 100880
> [ 2.283722] time = 100800
> [ 2.286444] time = 100880
> [ 2.289264] time = 100880
> [ 2.291981] time = 100800
> [ 2.294690] time = 100800
> [ 2.297405] time = 100800
>
> We're jumping to 100us for every PIO read/write operation. To be
> honest, I don't know if this is very important, there are not that many
> PIO operations, and they are not used in any performance hot path. But
> I thought it was worth pointing out the additional delay caused by this
> implementation change.
Good catch thanks for the measurements, will move to a 2us delay.
--
Remi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] PCI: aardvark: Don't rely on jiffies while holding spinlock
From: Remi Pommarel @ 2019-09-27 8:31 UTC (permalink / raw)
To: Thomas Petazzoni, Lorenzo Pieralisi, Bjorn Helgaas
Cc: linux-pci, Remi Pommarel, linux-kernel, linux-arm-kernel
advk_pcie_wait_pio() can be called while holding a spinlock (from
pci_bus_read_config_dword()), then depends on jiffies in order to
timeout while polling on PIO state registers. In the case the PIO
transaction failed, the timeout will never happen and will also cause
the cpu to stall.
This decrements a variable and wait instead of using jiffies.
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
---
Changes since v1:
- Reduce polling delay
- Change size_t into int for loop counter
---
drivers/pci/controller/pci-aardvark.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index fc0fe4d4de49..ee05ccb2b686 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -175,7 +175,8 @@
(PCIE_CONF_BUS(bus) | PCIE_CONF_DEV(PCI_SLOT(devfn)) | \
PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where))
-#define PIO_TIMEOUT_MS 1
+#define PIO_RETRY_CNT 10
+#define PIO_RETRY_DELAY 2 /* 2 us*/
#define LINK_WAIT_MAX_RETRIES 10
#define LINK_WAIT_USLEEP_MIN 90000
@@ -383,17 +384,16 @@ static void advk_pcie_check_pio_status(struct advk_pcie *pcie)
static int advk_pcie_wait_pio(struct advk_pcie *pcie)
{
struct device *dev = &pcie->pdev->dev;
- unsigned long timeout;
+ int i;
- timeout = jiffies + msecs_to_jiffies(PIO_TIMEOUT_MS);
-
- while (time_before(jiffies, timeout)) {
+ for (i = 0; i < PIO_RETRY_CNT; i++) {
u32 start, isr;
start = advk_readl(pcie, PIO_START);
isr = advk_readl(pcie, PIO_ISR);
if (!start && isr)
return 0;
+ udelay(PIO_RETRY_DELAY);
}
dev_err(dev, "config read/write timed out\n");
--
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/3] Optimize the u8500_hsem hwlock driver
From: Baolin Wang @ 2019-09-27 8:27 UTC (permalink / raw)
To: linus.walleij, ohad, bjorn.andersson
Cc: linux-remoteproc, linux-kernel, linux-arm-kernel, baolin.wang
This patch set did some Optimization with changing to use devm_xxx()
APIs to simplify the code and make code more readable.
Baolin Wang (3):
hwspinlock: u8500_hsem: Change to use
devm_platform_ioremap_resource()
hwspinlock: u8500_hsem: Use devm_kzalloc() to allocate memory
hwspinlock: u8500_hsem: Use devm_hwspin_lock_register() to register
hwlock controller
drivers/hwspinlock/u8500_hsem.c | 46 +++++++++++----------------------------
1 file changed, 13 insertions(+), 33 deletions(-)
--
1.7.9.5
_______________________________________________
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/3] hwspinlock: u8500_hsem: Change to use devm_platform_ioremap_resource()
From: Baolin Wang @ 2019-09-27 8:27 UTC (permalink / raw)
To: linus.walleij, ohad, bjorn.andersson
Cc: linux-remoteproc, linux-kernel, linux-arm-kernel, baolin.wang
In-Reply-To: <cover.1569572448.git.baolin.wang@linaro.org>
Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together, which can simpify the code.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/hwspinlock/u8500_hsem.c | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index 572ca79..c247a87 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -88,7 +88,6 @@ static int u8500_hsem_probe(struct platform_device *pdev)
struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
struct hwspinlock_device *bank;
struct hwspinlock *hwlock;
- struct resource *res;
void __iomem *io_base;
int i, ret, num_locks = U8500_MAX_SEMAPHORE;
ulong val;
@@ -96,13 +95,9 @@ static int u8500_hsem_probe(struct platform_device *pdev)
if (!pdata)
return -ENODEV;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
-
- io_base = ioremap(res->start, resource_size(res));
- if (!io_base)
- return -ENOMEM;
+ io_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(io_base))
+ return PTR_ERR(io_base);
/* make sure protocol 1 is selected */
val = readl(io_base + HSEM_CTRL_REG);
@@ -112,10 +107,8 @@ static int u8500_hsem_probe(struct platform_device *pdev)
writel(0xFFFF, io_base + HSEM_ICRALL);
bank = kzalloc(struct_size(bank, lock, num_locks), GFP_KERNEL);
- if (!bank) {
- ret = -ENOMEM;
- goto iounmap_base;
- }
+ if (!bank)
+ return -ENOMEM;
platform_set_drvdata(pdev, bank);
@@ -135,8 +128,6 @@ static int u8500_hsem_probe(struct platform_device *pdev)
reg_fail:
pm_runtime_disable(&pdev->dev);
kfree(bank);
-iounmap_base:
- iounmap(io_base);
return ret;
}
@@ -156,7 +147,6 @@ static int u8500_hsem_remove(struct platform_device *pdev)
}
pm_runtime_disable(&pdev->dev);
- iounmap(io_base);
kfree(bank);
return 0;
--
1.7.9.5
_______________________________________________
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 3/3] hwspinlock: u8500_hsem: Use devm_hwspin_lock_register() to register hwlock controller
From: Baolin Wang @ 2019-09-27 8:27 UTC (permalink / raw)
To: linus.walleij, ohad, bjorn.andersson
Cc: linux-remoteproc, linux-kernel, linux-arm-kernel, baolin.wang
In-Reply-To: <cover.1569572448.git.baolin.wang@linaro.org>
Use devm_hwspin_lock_register() to register the hwlock controller instead of
unregistering the hwlock controller explicitly when removing the device.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/hwspinlock/u8500_hsem.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index 0e8d4ff..b31141a 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -119,8 +119,8 @@ static int u8500_hsem_probe(struct platform_device *pdev)
/* no pm needed for HSem but required to comply with hwspilock core */
pm_runtime_enable(&pdev->dev);
- ret = hwspin_lock_register(bank, &pdev->dev, &u8500_hwspinlock_ops,
- pdata->base_id, num_locks);
+ ret = devm_hwspin_lock_register(&pdev->dev, bank, &u8500_hwspinlock_ops,
+ pdata->base_id, num_locks);
if (ret) {
pm_runtime_disable(&pdev->dev);
return ret;
@@ -133,17 +133,10 @@ static int u8500_hsem_remove(struct platform_device *pdev)
{
struct hwspinlock_device *bank = platform_get_drvdata(pdev);
void __iomem *io_base = bank->lock[0].priv - HSEM_REGISTER_OFFSET;
- int ret;
/* clear all interrupts */
writel(0xFFFF, io_base + HSEM_ICRALL);
- ret = hwspin_lock_unregister(bank);
- if (ret) {
- dev_err(&pdev->dev, "%s failed: %d\n", __func__, ret);
- return ret;
- }
-
pm_runtime_disable(&pdev->dev);
return 0;
--
1.7.9.5
_______________________________________________
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/3] hwspinlock: u8500_hsem: Use devm_kzalloc() to allocate memory
From: Baolin Wang @ 2019-09-27 8:27 UTC (permalink / raw)
To: linus.walleij, ohad, bjorn.andersson
Cc: linux-remoteproc, linux-kernel, linux-arm-kernel, baolin.wang
In-Reply-To: <cover.1569572448.git.baolin.wang@linaro.org>
Use devm_kzalloc() to allocate memory.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/hwspinlock/u8500_hsem.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index c247a87..0e8d4ff 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -106,7 +106,8 @@ static int u8500_hsem_probe(struct platform_device *pdev)
/* clear all interrupts */
writel(0xFFFF, io_base + HSEM_ICRALL);
- bank = kzalloc(struct_size(bank, lock, num_locks), GFP_KERNEL);
+ bank = devm_kzalloc(&pdev->dev, struct_size(bank, lock, num_locks),
+ GFP_KERNEL);
if (!bank)
return -ENOMEM;
@@ -120,15 +121,12 @@ static int u8500_hsem_probe(struct platform_device *pdev)
ret = hwspin_lock_register(bank, &pdev->dev, &u8500_hwspinlock_ops,
pdata->base_id, num_locks);
- if (ret)
- goto reg_fail;
+ if (ret) {
+ pm_runtime_disable(&pdev->dev);
+ return ret;
+ }
return 0;
-
-reg_fail:
- pm_runtime_disable(&pdev->dev);
- kfree(bank);
- return ret;
}
static int u8500_hsem_remove(struct platform_device *pdev)
@@ -147,7 +145,6 @@ static int u8500_hsem_remove(struct platform_device *pdev)
}
pm_runtime_disable(&pdev->dev);
- kfree(bank);
return 0;
}
--
1.7.9.5
_______________________________________________
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 1/5] arm64: Add ARM64_WORKAROUND_1319367 for all A57 and A72 versions
From: Suzuki K Poulose @ 2019-09-27 8:33 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
Cc: Mark Rutland, Catalin Marinas, Will Deacon, James Morse,
Julien Thierry
In-Reply-To: <20190925111941.88103-2-maz@kernel.org>
On 25/09/2019 12:19, Marc Zyngier wrote:
> Rework the EL2 vector hardening that is only selected for A57 and A72
> so that the table can also be used for ARM64_WORKAROUND_1319367.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
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] PCI: aardvark: Don't rely on jiffies while holding spinlock
From: Thomas Petazzoni @ 2019-09-27 8:34 UTC (permalink / raw)
To: Remi Pommarel
Cc: Bjorn Helgaas, linux-pci, Lorenzo Pieralisi, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190927083142.8571-1-repk@triplefau.lt>
Hello Remi,
Thanks for the new iteration!
On Fri, 27 Sep 2019 10:31:42 +0200
Remi Pommarel <repk@triplefau.lt> wrote:
> diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
> index fc0fe4d4de49..ee05ccb2b686 100644
> --- a/drivers/pci/controller/pci-aardvark.c
> +++ b/drivers/pci/controller/pci-aardvark.c
> @@ -175,7 +175,8 @@
> (PCIE_CONF_BUS(bus) | PCIE_CONF_DEV(PCI_SLOT(devfn)) | \
> PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where))
>
> -#define PIO_TIMEOUT_MS 1
> +#define PIO_RETRY_CNT 10
> +#define PIO_RETRY_DELAY 2 /* 2 us*/
So this changes the timeout from 1ms to just 20us, a division by 50
from the previous timeout value. From my measurements, it could
sometime take up to 6us from a single PIO read operation to complete,
which is getting close to the 20us timeout.
Shouldn't PIO_RETRY_CNT be kept at 500, so that we keep using a 1ms
timeout ?
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
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] PCI: aardvark: Don't rely on jiffies while holding spinlock
From: Remi Pommarel @ 2019-09-27 8:50 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Bjorn Helgaas, linux-pci, Lorenzo Pieralisi, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190927103420.48bb9335@windsurf>
Hi Thomas,
On Fri, Sep 27, 2019 at 10:34:20AM +0200, Thomas Petazzoni wrote:
> Hello Remi,
>
> Thanks for the new iteration!
>
> On Fri, 27 Sep 2019 10:31:42 +0200
> Remi Pommarel <repk@triplefau.lt> wrote:
>
> > diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
> > index fc0fe4d4de49..ee05ccb2b686 100644
> > --- a/drivers/pci/controller/pci-aardvark.c
> > +++ b/drivers/pci/controller/pci-aardvark.c
> > @@ -175,7 +175,8 @@
> > (PCIE_CONF_BUS(bus) | PCIE_CONF_DEV(PCI_SLOT(devfn)) | \
> > PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where))
> >
> > -#define PIO_TIMEOUT_MS 1
> > +#define PIO_RETRY_CNT 10
> > +#define PIO_RETRY_DELAY 2 /* 2 us*/
>
> So this changes the timeout from 1ms to just 20us, a division by 50
> from the previous timeout value. From my measurements, it could
> sometime take up to 6us from a single PIO read operation to complete,
> which is getting close to the 20us timeout.
>
> Shouldn't PIO_RETRY_CNT be kept at 500, so that we keep using a 1ms
> timeout ?
Damn. You right of course, sorry about that.
Thanks
--
Remi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] PCI: aardvark: Don't rely on jiffies while holding spinlock
From: Remi Pommarel @ 2019-09-27 8:55 UTC (permalink / raw)
To: Thomas Petazzoni, Lorenzo Pieralisi, Bjorn Helgaas
Cc: linux-pci, Remi Pommarel, linux-kernel, linux-arm-kernel
advk_pcie_wait_pio() can be called while holding a spinlock (from
pci_bus_read_config_dword()), then depends on jiffies in order to
timeout while polling on PIO state registers. In the case the PIO
transaction failed, the timeout will never happen and will also cause
the cpu to stall.
This decrements a variable and wait instead of using jiffies.
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
---
Changes since v1:
- Reduce polling delay
- Change size_t into int for loop counter
Changes since v2:
- Keep timeout to 1ms by increasing retry counter
---
drivers/pci/controller/pci-aardvark.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index fc0fe4d4de49..7b5c9d6c8706 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -175,7 +175,8 @@
(PCIE_CONF_BUS(bus) | PCIE_CONF_DEV(PCI_SLOT(devfn)) | \
PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where))
-#define PIO_TIMEOUT_MS 1
+#define PIO_RETRY_CNT 500
+#define PIO_RETRY_DELAY 2 /* 2 us*/
#define LINK_WAIT_MAX_RETRIES 10
#define LINK_WAIT_USLEEP_MIN 90000
@@ -383,17 +384,16 @@ static void advk_pcie_check_pio_status(struct advk_pcie *pcie)
static int advk_pcie_wait_pio(struct advk_pcie *pcie)
{
struct device *dev = &pcie->pdev->dev;
- unsigned long timeout;
+ int i;
- timeout = jiffies + msecs_to_jiffies(PIO_TIMEOUT_MS);
-
- while (time_before(jiffies, timeout)) {
+ for (i = 0; i < PIO_RETRY_CNT; i++) {
u32 start, isr;
start = advk_readl(pcie, PIO_START);
isr = advk_readl(pcie, PIO_ISR);
if (!start && isr)
return 0;
+ udelay(PIO_RETRY_DELAY);
}
dev_err(dev, "config read/write timed out\n");
--
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] ARM: dts: stm32: Enable high resolution timer
From: Benjamin Gaignard @ 2019-09-27 8:48 UTC (permalink / raw)
To: alexandre.torgue, robh+dt, mark.rutland
Cc: Benjamin Gaignard, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel
Adding always-on makes arm arch_timer claim to be an high resolution timer.
That is possible because power mode won't stop clocking the timer.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/boot/dts/stm32mp157c.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
index 9b11654a0a39..74f64745d60d 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -50,6 +50,7 @@
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
interrupt-parent = <&intc>;
+ always-on;
};
clocks {
--
2.15.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
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