* Re: [RFC] ARM: omap3: Enable HWMODS for HW Random Number Generator
From: Sebastian Reichel @ 2019-09-10 14:37 UTC (permalink / raw)
To: Adam Ford
Cc: Mark Rutland, devicetree, Paul Walmsley, Aaro Koskinen,
Tony Lindgren, Russell King, Linux Kernel Mailing List,
Tero Kristo, Rob Herring, Benoît Cousson, Pali Rohár,
Linux-OMAP, Adam Ford, arm-soc
In-Reply-To: <CAHCN7xKxffJUV2V2CCuw0iPqUm4LJT28GMrcF2=8rDJQM2dOOw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 770 bytes --]
Hi,
On Tue, Sep 10, 2019 at 08:56:49AM -0500, Adam Ford wrote:
> On Thu, Sep 5, 2019 at 6:04 PM Tony Lindgren <tony@atomide.com> wrote:
> > Oh and this needs to default to status = "disabled" for
> > HS devices like n900 as it needs to use the omap3-rom-rng.
>
> I don't know enough about the HS version of the OMAP3, but what's the
> main difference between omap3-rom-rng and this one?
The OMAP HS chips have the bus firewall configured to block direct
access to some cryptography related devices. The kernel will crash
with a bus error, if you try to read/write the registers for
protected devices. The omap3-rom-rng avoids this by communicating
with the security middleware component instead of directly accessing
the RNG hardware.
-- Sebastian
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next 3/6] net: stmmac: xgmac: Reinitialize correctly a variable
From: Jose Abreu @ 2019-09-10 14:41 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.1568126224.git.joabreu@synopsys.com>
'value' was being or'ed with a value from another register. This is a
typo and could cause new written value to be wrong. Fix it.
Signed-off-by: Jose Abreu <joabreu@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 78ac659da279..d5173dd02a71 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -568,7 +568,7 @@ static void dwxgmac2_update_vlan_hash(struct mac_device_info *hw, u32 hash,
writel(value, ioaddr + XGMAC_PACKET_FILTER);
- value |= XGMAC_VLAN_VTHM | XGMAC_VLAN_ETV;
+ value = XGMAC_VLAN_VTHM | XGMAC_VLAN_ETV;
if (is_double) {
value |= XGMAC_VLAN_EDVLP;
value |= XGMAC_VLAN_ESVL;
--
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-next 2/6] net: stmmac: Add VLAN HASH filtering support in GMAC4+
From: Jose Abreu @ 2019-09-10 14:41 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.1568126224.git.joabreu@synopsys.com>
Adds the support for VLAN HASH Filtering in GMAC4/5 cores.
Signed-off-by: Jose Abreu <joabreu@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.h | 11 ++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 31 +++++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 2 +-
3 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index 03301ffc0391..4dfa69850040 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -16,6 +16,8 @@
#define GMAC_CONFIG 0x00000000
#define GMAC_PACKET_FILTER 0x00000008
#define GMAC_HASH_TAB(x) (0x10 + (x) * 4)
+#define GMAC_VLAN_TAG 0x00000050
+#define GMAC_VLAN_HASH_TABLE 0x00000058
#define GMAC_RX_FLOW_CTRL 0x00000090
#define GMAC_QX_TX_FLOW_CTRL(x) (0x70 + x * 4)
#define GMAC_TXQ_PRTY_MAP0 0x98
@@ -62,9 +64,18 @@
#define GMAC_PACKET_FILTER_PM BIT(4)
#define GMAC_PACKET_FILTER_PCF BIT(7)
#define GMAC_PACKET_FILTER_HPF BIT(10)
+#define GMAC_PACKET_FILTER_VTFE BIT(16)
#define GMAC_MAX_PERFECT_ADDRESSES 128
+/* MAC VLAN */
+#define GMAC_VLAN_EDVLP BIT(26)
+#define GMAC_VLAN_VTHM BIT(25)
+#define GMAC_VLAN_DOVLTC BIT(20)
+#define GMAC_VLAN_ESVL BIT(18)
+#define GMAC_VLAN_ETV BIT(16)
+#define GMAC_VLAN_VID GENMASK(15, 0)
+
/* MAC RX Queue Enable */
#define GMAC_RX_QUEUE_CLEAR(queue) ~(GENMASK(1, 0) << ((queue) * 2))
#define GMAC_RX_AV_QUEUE_ENABLE(queue) BIT((queue) * 2)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 596311a80d1c..5b43a8df1536 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -731,6 +731,34 @@ static void dwmac4_set_mac_loopback(void __iomem *ioaddr, bool enable)
writel(value, ioaddr + GMAC_CONFIG);
}
+static void dwmac4_update_vlan_hash(struct mac_device_info *hw, u32 hash,
+ bool is_double)
+{
+ void __iomem *ioaddr = hw->pcsr;
+
+ writel(hash, ioaddr + GMAC_VLAN_HASH_TABLE);
+
+ if (hash) {
+ u32 value = GMAC_VLAN_VTHM | GMAC_VLAN_ETV;
+ if (is_double) {
+ value |= GMAC_VLAN_EDVLP;
+ value |= GMAC_VLAN_ESVL;
+ value |= GMAC_VLAN_DOVLTC;
+ }
+
+ writel(value, ioaddr + GMAC_VLAN_TAG);
+ } else {
+ u32 value = readl(ioaddr + GMAC_VLAN_TAG);
+
+ value &= ~(GMAC_VLAN_VTHM | GMAC_VLAN_ETV);
+ value &= ~(GMAC_VLAN_EDVLP | GMAC_VLAN_ESVL);
+ value &= ~GMAC_VLAN_DOVLTC;
+ value &= ~GMAC_VLAN_VID;
+
+ writel(value, ioaddr + GMAC_VLAN_TAG);
+ }
+}
+
const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_set_mac,
@@ -761,6 +789,7 @@ const struct stmmac_ops dwmac4_ops = {
.debug = dwmac4_debug,
.set_filter = dwmac4_set_filter,
.set_mac_loopback = dwmac4_set_mac_loopback,
+ .update_vlan_hash = dwmac4_update_vlan_hash,
};
const struct stmmac_ops dwmac410_ops = {
@@ -793,6 +822,7 @@ const struct stmmac_ops dwmac410_ops = {
.debug = dwmac4_debug,
.set_filter = dwmac4_set_filter,
.set_mac_loopback = dwmac4_set_mac_loopback,
+ .update_vlan_hash = dwmac4_update_vlan_hash,
};
const struct stmmac_ops dwmac510_ops = {
@@ -830,6 +860,7 @@ const struct stmmac_ops dwmac510_ops = {
.rxp_config = dwmac5_rxp_config,
.flex_pps_config = dwmac5_flex_pps_config,
.set_mac_loopback = dwmac4_set_mac_loopback,
+ .update_vlan_hash = dwmac4_update_vlan_hash,
};
int dwmac4_setup(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 3ed5508586ef..2456f421aac9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -333,7 +333,7 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
dma_cap->mbps_10_100 = (hw_cap & GMAC_HW_FEAT_MIISEL);
dma_cap->mbps_1000 = (hw_cap & GMAC_HW_FEAT_GMIISEL) >> 1;
dma_cap->half_duplex = (hw_cap & GMAC_HW_FEAT_HDSEL) >> 2;
- dma_cap->hash_filter = (hw_cap & GMAC_HW_FEAT_VLHASH) >> 4;
+ dma_cap->vlhash = (hw_cap & GMAC_HW_FEAT_VLHASH) >> 4;
dma_cap->multi_addr = (hw_cap & GMAC_HW_FEAT_ADDMAC) >> 18;
dma_cap->pcs = (hw_cap & GMAC_HW_FEAT_PCSSEL) >> 3;
dma_cap->sma_mdio = (hw_cap & GMAC_HW_FEAT_SMASEL) >> 5;
--
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-next 0/6] net: stmmac: Improvements for -next
From: Jose Abreu @ 2019-09-10 14:41 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 patches for -next. It includes:
- Two fixes for features in -next only
- New features support for GMAC cores (which includes GMAC4 and GMAC5)
---
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 (6):
net: stmmac: Prevent divide-by-zero
net: stmmac: Add VLAN HASH filtering support in GMAC4+
net: stmmac: xgmac: Reinitialize correctly a variable
net: stmmac: Add support for SA Insertion/Replacement in GMAC4+
net: stmmac: Add support for VLAN Insertion Offload in GMAC4+
net: stmmac: ARP Offload for GMAC4+ Cores
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 23 +++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 79 ++++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 43 ++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h | 9 +++
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 5 +-
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +-
7 files changed, 162 insertions(+), 3 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-next 6/6] net: stmmac: ARP Offload for GMAC4+ Cores
From: Jose Abreu @ 2019-09-10 14:41 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.1568126224.git.joabreu@synopsys.com>
Implement the ARP Offload feature in GMAC4 and GMAC5 cores.
Signed-off-by: Jose Abreu <joabreu@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.h | 3 +++
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 19 +++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index e88dac1dd765..89a3420eba42 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -40,6 +40,7 @@
#define GMAC_HW_FEATURE3 0x00000128
#define GMAC_MDIO_ADDR 0x00000200
#define GMAC_MDIO_DATA 0x00000204
+#define GMAC_ARP_ADDR 0x00000210
#define GMAC_ADDR_HIGH(reg) (0x300 + reg * 8)
#define GMAC_ADDR_LOW(reg) (0x304 + reg * 8)
@@ -165,6 +166,7 @@ enum power_event {
#define GMAC_DEBUG_RPESTS BIT(0)
/* MAC config */
+#define GMAC_CONFIG_ARPEN BIT(31)
#define GMAC_CONFIG_SARC GENMASK(30, 28)
#define GMAC_CONFIG_SARC_SHIFT 28
#define GMAC_CONFIG_IPC BIT(27)
@@ -188,6 +190,7 @@ enum power_event {
#define GMAC_HW_FEAT_TXCOSEL BIT(14)
#define GMAC_HW_FEAT_EEESEL BIT(13)
#define GMAC_HW_FEAT_TSSEL BIT(12)
+#define GMAC_HW_FEAT_ARPOFFSEL BIT(9)
#define GMAC_HW_FEAT_MMCSEL BIT(8)
#define GMAC_HW_FEAT_MGKSEL BIT(7)
#define GMAC_HW_FEAT_RWKSEL BIT(6)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index a99effe61325..9b4b5f69fc02 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -782,6 +782,22 @@ static void dwmac4_enable_vlan(struct mac_device_info *hw, u32 type)
writel(value, ioaddr + GMAC_VLAN_INCL);
}
+static void dwmac4_set_arp_offload(struct mac_device_info *hw, bool en,
+ u32 addr)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 value;
+
+ writel(addr, ioaddr + GMAC_ARP_ADDR);
+
+ value = readl(ioaddr + GMAC_CONFIG);
+ if (en)
+ value |= GMAC_CONFIG_ARPEN;
+ else
+ value &= ~GMAC_CONFIG_ARPEN;
+ writel(value, ioaddr + GMAC_CONFIG);
+}
+
const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_set_mac,
@@ -815,6 +831,7 @@ const struct stmmac_ops dwmac4_ops = {
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
.enable_vlan = dwmac4_enable_vlan,
+ .set_arp_offload = dwmac4_set_arp_offload,
};
const struct stmmac_ops dwmac410_ops = {
@@ -850,6 +867,7 @@ const struct stmmac_ops dwmac410_ops = {
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
.enable_vlan = dwmac4_enable_vlan,
+ .set_arp_offload = dwmac4_set_arp_offload,
};
const struct stmmac_ops dwmac510_ops = {
@@ -890,6 +908,7 @@ const struct stmmac_ops dwmac510_ops = {
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
.enable_vlan = dwmac4_enable_vlan,
+ .set_arp_offload = dwmac4_set_arp_offload,
};
int dwmac4_setup(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index f3ca0236450d..68c157979b94 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -349,6 +349,7 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
dma_cap->tx_coe = (hw_cap & GMAC_HW_FEAT_TXCOSEL) >> 14;
dma_cap->rx_coe = (hw_cap & GMAC_HW_FEAT_RXCOESEL) >> 16;
dma_cap->vlins = (hw_cap & GMAC_HW_FEAT_SAVLANINS) >> 27;
+ dma_cap->arpoffsel = (hw_cap & GMAC_HW_FEAT_ARPOFFSEL) >> 9;
/* MAC HW feature1 */
hw_cap = readl(ioaddr + GMAC_HW_FEATURE1);
--
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-next 5/6] net: stmmac: Add support for VLAN Insertion Offload in GMAC4+
From: Jose Abreu @ 2019-09-10 14:41 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.1568126224.git.joabreu@synopsys.com>
Adds support for TX VLAN Offload using descriptors based features
available in GMAC4/5.
Signed-off-by: Jose Abreu <joabreu@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.h | 6 ++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 16 ++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 35 ++++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h | 8 +++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 1 +
5 files changed, 66 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index fad121cbfe0e..e88dac1dd765 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -19,6 +19,7 @@
#define GMAC_VLAN_TAG 0x00000050
#define GMAC_VLAN_HASH_TABLE 0x00000058
#define GMAC_RX_FLOW_CTRL 0x00000090
+#define GMAC_VLAN_INCL 0x00000060
#define GMAC_QX_TX_FLOW_CTRL(x) (0x70 + x * 4)
#define GMAC_TXQ_PRTY_MAP0 0x98
#define GMAC_TXQ_PRTY_MAP1 0x9C
@@ -75,6 +76,10 @@
#define GMAC_VLAN_ESVL BIT(18)
#define GMAC_VLAN_ETV BIT(16)
#define GMAC_VLAN_VID GENMASK(15, 0)
+#define GMAC_VLAN_VLTI BIT(20)
+#define GMAC_VLAN_CSVL BIT(19)
+#define GMAC_VLAN_VLC GENMASK(17, 16)
+#define GMAC_VLAN_VLC_SHIFT 16
/* MAC RX Queue Enable */
#define GMAC_RX_QUEUE_CLEAR(queue) ~(GENMASK(1, 0) << ((queue) * 2))
@@ -212,6 +217,7 @@ enum power_event {
#define GMAC_HW_FEAT_FRPES GENMASK(14, 13)
#define GMAC_HW_FEAT_FRPBS GENMASK(12, 11)
#define GMAC_HW_FEAT_FRPSEL BIT(10)
+#define GMAC_HW_FEAT_DVLAN BIT(5)
/* MAC HW ADDR regs */
#define GMAC_HI_DCS GENMASK(18, 16)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 73dbfd810fca..a99effe61325 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -769,6 +769,19 @@ static void dwmac4_sarc_configure(void __iomem *ioaddr, int val)
writel(value, ioaddr + GMAC_CONFIG);
}
+static void dwmac4_enable_vlan(struct mac_device_info *hw, u32 type)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 value;
+
+ value = readl(ioaddr + GMAC_VLAN_INCL);
+ value |= GMAC_VLAN_VLTI;
+ value |= GMAC_VLAN_CSVL; /* Only use SVLAN */
+ value &= ~GMAC_VLAN_VLC;
+ value |= (type << GMAC_VLAN_VLC_SHIFT) & GMAC_VLAN_VLC;
+ writel(value, ioaddr + GMAC_VLAN_INCL);
+}
+
const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_set_mac,
@@ -801,6 +814,7 @@ const struct stmmac_ops dwmac4_ops = {
.set_mac_loopback = dwmac4_set_mac_loopback,
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
+ .enable_vlan = dwmac4_enable_vlan,
};
const struct stmmac_ops dwmac410_ops = {
@@ -835,6 +849,7 @@ const struct stmmac_ops dwmac410_ops = {
.set_mac_loopback = dwmac4_set_mac_loopback,
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
+ .enable_vlan = dwmac4_enable_vlan,
};
const struct stmmac_ops dwmac510_ops = {
@@ -874,6 +889,7 @@ const struct stmmac_ops dwmac510_ops = {
.set_mac_loopback = dwmac4_set_mac_loopback,
.update_vlan_hash = dwmac4_update_vlan_hash,
.sarc_configure = dwmac4_sarc_configure,
+ .enable_vlan = dwmac4_enable_vlan,
};
int dwmac4_setup(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 8edc9f8787cc..15eb1abba91d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -459,6 +459,39 @@ static int set_16kib_bfsize(int mtu)
return ret;
}
+static void dwmac4_set_vlan_tag(struct dma_desc *p, u16 tag, u16 inner_tag,
+ u32 inner_type)
+{
+ p->des0 = 0;
+ p->des1 = 0;
+ p->des2 = 0;
+ p->des3 = 0;
+
+ /* Inner VLAN */
+ if (inner_type) {
+ u32 des = inner_tag << TDES2_IVT_SHIFT;
+
+ des &= TDES2_IVT_MASK;
+ p->des2 = cpu_to_le32(des);
+
+ des = inner_type << TDES3_IVTIR_SHIFT;
+ des &= TDES3_IVTIR_MASK;
+ p->des3 = cpu_to_le32(des | TDES3_IVLTV);
+ }
+
+ /* Outer VLAN */
+ p->des3 |= cpu_to_le32(tag & TDES3_VLAN_TAG);
+ p->des3 |= cpu_to_le32(TDES3_VLTV);
+
+ p->des3 |= cpu_to_le32(TDES3_CONTEXT_TYPE);
+}
+
+static void dwmac4_set_vlan(struct dma_desc *p, u32 type)
+{
+ type <<= TDES2_VLAN_TAG_SHIFT;
+ p->des2 |= cpu_to_le32(type & TDES2_VLAN_TAG_MASK);
+}
+
const struct stmmac_desc_ops dwmac4_desc_ops = {
.tx_status = dwmac4_wrback_get_tx_status,
.rx_status = dwmac4_wrback_get_rx_status,
@@ -484,6 +517,8 @@ const struct stmmac_desc_ops dwmac4_desc_ops = {
.set_addr = dwmac4_set_addr,
.clear = dwmac4_clear,
.set_sarc = dwmac4_set_sarc,
+ .set_vlan_tag = dwmac4_set_vlan_tag,
+ .set_vlan = dwmac4_set_vlan,
};
const struct stmmac_mode_ops dwmac4_ring_mode_ops = {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h
index 6089d76a00d3..0d7b3bbcd5a7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h
@@ -18,13 +18,21 @@
/* TDES2 (read format) */
#define TDES2_BUFFER1_SIZE_MASK GENMASK(13, 0)
#define TDES2_VLAN_TAG_MASK GENMASK(15, 14)
+#define TDES2_VLAN_TAG_SHIFT 14
#define TDES2_BUFFER2_SIZE_MASK GENMASK(29, 16)
#define TDES2_BUFFER2_SIZE_MASK_SHIFT 16
+#define TDES3_IVTIR_MASK GENMASK(19, 18)
+#define TDES3_IVTIR_SHIFT 18
+#define TDES3_IVLTV BIT(17)
#define TDES2_TIMESTAMP_ENABLE BIT(30)
+#define TDES2_IVT_MASK GENMASK(31, 16)
+#define TDES2_IVT_SHIFT 16
#define TDES2_INTERRUPT_ON_COMPLETION BIT(31)
/* TDES3 (read format) */
#define TDES3_PACKET_SIZE_MASK GENMASK(14, 0)
+#define TDES3_VLAN_TAG GENMASK(15, 0)
+#define TDES3_VLTV BIT(16)
#define TDES3_CHECKSUM_INSERTION_MASK GENMASK(17, 16)
#define TDES3_CHECKSUM_INSERTION_SHIFT 16
#define TDES3_TCP_PKT_PAYLOAD_MASK GENMASK(17, 0)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 82d9761b2df2..f3ca0236450d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -386,6 +386,7 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
dma_cap->frpes = (hw_cap & GMAC_HW_FEAT_FRPES) >> 13;
dma_cap->frpbs = (hw_cap & GMAC_HW_FEAT_FRPBS) >> 11;
dma_cap->frpsel = (hw_cap & GMAC_HW_FEAT_FRPSEL) >> 10;
+ dma_cap->dvlan = (hw_cap & GMAC_HW_FEAT_DVLAN) >> 5;
}
/* Enable/disable TSO feature and set MSS */
--
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-next 1/6] net: stmmac: Prevent divide-by-zero
From: Jose Abreu @ 2019-09-10 14:41 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.1568126224.git.joabreu@synopsys.com>
When RX Coalesce settings are set to all zero (which is a valid setting)
we will currently get a divide-by-zero error. Fix it.
Signed-off-by: Jose Abreu <joabreu@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 | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 686b82068142..6e44013b20cc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3418,7 +3418,9 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv, u32 queue)
stmmac_refill_desc3(priv, rx_q, p);
rx_q->rx_count_frames++;
- rx_q->rx_count_frames %= priv->rx_coal_frames;
+ rx_q->rx_count_frames += priv->rx_coal_frames;
+ if (rx_q->rx_count_frames > priv->rx_coal_frames)
+ rx_q->rx_count_frames = 0;
use_rx_wd = priv->use_riwt && rx_q->rx_count_frames;
dma_wmb();
--
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-next 4/6] net: stmmac: Add support for SA Insertion/Replacement in GMAC4+
From: Jose Abreu @ 2019-09-10 14:41 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.1568126224.git.joabreu@synopsys.com>
Add the support for Source Address Insertion and Replacement in GMAC4
and GMAC5 cores. Two methods are supported: Descriptor based and
register based.
Signed-off-by: Jose Abreu <joabreu@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.h | 3 +++
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 13 +++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 8 ++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 1 +
5 files changed, 26 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index 4dfa69850040..fad121cbfe0e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -160,6 +160,8 @@ enum power_event {
#define GMAC_DEBUG_RPESTS BIT(0)
/* MAC config */
+#define GMAC_CONFIG_SARC GENMASK(30, 28)
+#define GMAC_CONFIG_SARC_SHIFT 28
#define GMAC_CONFIG_IPC BIT(27)
#define GMAC_CONFIG_2K BIT(22)
#define GMAC_CONFIG_ACS BIT(20)
@@ -175,6 +177,7 @@ enum power_event {
#define GMAC_CONFIG_RE BIT(0)
/* MAC HW features0 bitmap */
+#define GMAC_HW_FEAT_SAVLANINS BIT(27)
#define GMAC_HW_FEAT_ADDMAC BIT(18)
#define GMAC_HW_FEAT_RXCOESEL BIT(16)
#define GMAC_HW_FEAT_TXCOSEL BIT(14)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 5b43a8df1536..73dbfd810fca 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -759,6 +759,16 @@ static void dwmac4_update_vlan_hash(struct mac_device_info *hw, u32 hash,
}
}
+static void dwmac4_sarc_configure(void __iomem *ioaddr, int val)
+{
+ u32 value = readl(ioaddr + GMAC_CONFIG);
+
+ value &= ~GMAC_CONFIG_SARC;
+ value |= val << GMAC_CONFIG_SARC_SHIFT;
+
+ writel(value, ioaddr + GMAC_CONFIG);
+}
+
const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_set_mac,
@@ -790,6 +800,7 @@ const struct stmmac_ops dwmac4_ops = {
.set_filter = dwmac4_set_filter,
.set_mac_loopback = dwmac4_set_mac_loopback,
.update_vlan_hash = dwmac4_update_vlan_hash,
+ .sarc_configure = dwmac4_sarc_configure,
};
const struct stmmac_ops dwmac410_ops = {
@@ -823,6 +834,7 @@ const struct stmmac_ops dwmac410_ops = {
.set_filter = dwmac4_set_filter,
.set_mac_loopback = dwmac4_set_mac_loopback,
.update_vlan_hash = dwmac4_update_vlan_hash,
+ .sarc_configure = dwmac4_sarc_configure,
};
const struct stmmac_ops dwmac510_ops = {
@@ -861,6 +873,7 @@ const struct stmmac_ops dwmac510_ops = {
.flex_pps_config = dwmac5_flex_pps_config,
.set_mac_loopback = dwmac4_set_mac_loopback,
.update_vlan_hash = dwmac4_update_vlan_hash,
+ .sarc_configure = dwmac4_sarc_configure,
};
int dwmac4_setup(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index dbde23e7e169..8edc9f8787cc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -443,6 +443,13 @@ static void dwmac4_clear(struct dma_desc *p)
p->des3 = 0;
}
+static void dwmac4_set_sarc(struct dma_desc *p, u32 sarc_type)
+{
+ sarc_type <<= TDES3_SA_INSERT_CTRL_SHIFT;
+
+ p->des3 |= cpu_to_le32(sarc_type & TDES3_SA_INSERT_CTRL_MASK);
+}
+
static int set_16kib_bfsize(int mtu)
{
int ret = 0;
@@ -476,6 +483,7 @@ const struct stmmac_desc_ops dwmac4_desc_ops = {
.get_addr = dwmac4_get_addr,
.set_addr = dwmac4_set_addr,
.clear = dwmac4_clear,
+ .set_sarc = dwmac4_set_sarc,
};
const struct stmmac_mode_ops dwmac4_ring_mode_ops = {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h
index f58191174287..6089d76a00d3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h
@@ -32,6 +32,7 @@
#define TDES3_HDR_LEN_SHIFT 19
#define TDES3_SLOT_NUMBER_MASK GENMASK(22, 19)
#define TDES3_SA_INSERT_CTRL_MASK GENMASK(25, 23)
+#define TDES3_SA_INSERT_CTRL_SHIFT 23
#define TDES3_CRC_PAD_CTRL_MASK GENMASK(27, 26)
/* TDES3 (write back format) */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 2456f421aac9..82d9761b2df2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -348,6 +348,7 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
/* TX and RX csum */
dma_cap->tx_coe = (hw_cap & GMAC_HW_FEAT_TXCOSEL) >> 14;
dma_cap->rx_coe = (hw_cap & GMAC_HW_FEAT_RXCOESEL) >> 16;
+ dma_cap->vlins = (hw_cap & GMAC_HW_FEAT_SAVLANINS) >> 27;
/* MAC HW feature1 */
hw_cap = readl(ioaddr + GMAC_HW_FEATURE1);
--
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 v9 0/8] stg mail -e --version=v9 \
From: Alexander Duyck @ 2019-09-10 14:42 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190910124209.GY2063@dhcp22.suse.cz>
On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> I wanted to review "mm: Introduce Reported pages" just realize that I
> have no clue on what is going on so returned to the cover and it didn't
> really help much. I am completely unfamiliar with virtio so please bear
> with me.
>
> On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> [...]
> > This series provides an asynchronous means of reporting to a hypervisor
> > that a guest page is no longer in use and can have the data associated
> > with it dropped. To do this I have implemented functionality that allows
> > for what I am referring to as unused page reporting
> >
> > The functionality for this is fairly simple. When enabled it will allocate
> > statistics to track the number of reported pages in a given free area.
> > When the number of free pages exceeds this value plus a high water value,
> > currently 32, it will begin performing page reporting which consists of
> > pulling pages off of free list and placing them into a scatter list. The
> > scatterlist is then given to the page reporting device and it will perform
> > the required action to make the pages "reported", in the case of
> > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > and as such they are forced out of the guest. After this they are placed
> > back on the free list,
>
> And here I am reallly lost because "forced out of the guest" makes me
> feel that those pages are no longer usable by the guest. So how come you
> can add them back to the free list. I suspect understanding this part
> will allow me to understand why we have to mark those pages and prevent
> merging.
Basically as the paragraph above mentions "forced out of the guest"
really is just the hypervisor calling MADV_DONTNEED on the page in
question. So the behavior is the same as any userspace application
that calls MADV_DONTNEED where the contents are no longer accessible
from userspace and attempting to access them will result in a fault
and the page being populated with a zero fill on-demand page, or a
copy of the file contents if the memory is file backed.
_______________________________________________
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] ARM: omap3: Enable HWMODS for HW Random Number Generator
From: Pali Rohár @ 2019-09-10 14:44 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Mark Rutland, devicetree, Paul Walmsley, Aaro Koskinen,
Tony Lindgren, Adam Ford, Russell King, Linux Kernel Mailing List,
Tero Kristo, Rob Herring, Benoît Cousson, Linux-OMAP,
Adam Ford, arm-soc
In-Reply-To: <20190910143732.3g3q4acvnx2pqvjx@earth.universe>
On Tuesday 10 September 2019 15:37:32 Sebastian Reichel wrote:
> Hi,
>
> On Tue, Sep 10, 2019 at 08:56:49AM -0500, Adam Ford wrote:
> > On Thu, Sep 5, 2019 at 6:04 PM Tony Lindgren <tony@atomide.com> wrote:
> > > Oh and this needs to default to status = "disabled" for
> > > HS devices like n900 as it needs to use the omap3-rom-rng.
> >
> > I don't know enough about the HS version of the OMAP3, but what's the
> > main difference between omap3-rom-rng and this one?
>
> The OMAP HS chips have the bus firewall configured to block direct
> access to some cryptography related devices. The kernel will crash
> with a bus error, if you try to read/write the registers for
> protected devices.
And if you try to read it more times, SOC would be rebooted for security
reasons.
> The omap3-rom-rng avoids this by communicating
> with the security middleware component instead of directly accessing
> the RNG hardware.
And that component is loaded by signed bootloader into "secure" area not
accessible by "non-secure" work (like kernel) and communication is done
via arm smc instruction.
--
Pali Rohár
pali.rohar@gmail.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 v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
From: Alexander Duyck @ 2019-09-10 14:46 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190910122313.GW2063@dhcp22.suse.cz>
On Tue, Sep 10, 2019 at 5:23 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >
> > In order to support page reporting it will be necessary to store and
> > retrieve the migratetype of a page. To enable that I am moving the set and
> > get operations for pcppage_migratetype into the mm/internal.h header so
> > that they can be used outside of the page_alloc.c file.
>
> Please describe who is the user and why does it needs this interface.
> This is really important because migratetype is an MM internal thing and
> external users shouldn't really care about it at all. We really do not
> want a random code to call those, especially the set_pcppage_migratetype.
I was using it to store the migratetype of the page so that I could
find the boundary list that contained the reported page as the array
is indexed based on page order and migratetype. However on further
discussion I am thinking I may just use page->index directly to index
into the boundary array. Doing that I should be able to get a very
slight improvement in lookup time since I am not having to pull order
and migratetype and then compute the index based on that. In addition
it becomes much more clear as to what is going on, and if needed I
could add debug checks to verify the page is "Reported" and that the
"Buddy" page type is set.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Michal Hocko @ 2019-09-10 14:47 UTC (permalink / raw)
To: Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <CAKgT0Udr6nYQFTRzxLbXk41SiJ-pcT_bmN1j1YR4deCwdTOaUQ@mail.gmail.com>
On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > I wanted to review "mm: Introduce Reported pages" just realize that I
> > have no clue on what is going on so returned to the cover and it didn't
> > really help much. I am completely unfamiliar with virtio so please bear
> > with me.
> >
> > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > [...]
> > > This series provides an asynchronous means of reporting to a hypervisor
> > > that a guest page is no longer in use and can have the data associated
> > > with it dropped. To do this I have implemented functionality that allows
> > > for what I am referring to as unused page reporting
> > >
> > > The functionality for this is fairly simple. When enabled it will allocate
> > > statistics to track the number of reported pages in a given free area.
> > > When the number of free pages exceeds this value plus a high water value,
> > > currently 32, it will begin performing page reporting which consists of
> > > pulling pages off of free list and placing them into a scatter list. The
> > > scatterlist is then given to the page reporting device and it will perform
> > > the required action to make the pages "reported", in the case of
> > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > and as such they are forced out of the guest. After this they are placed
> > > back on the free list,
> >
> > And here I am reallly lost because "forced out of the guest" makes me
> > feel that those pages are no longer usable by the guest. So how come you
> > can add them back to the free list. I suspect understanding this part
> > will allow me to understand why we have to mark those pages and prevent
> > merging.
>
> Basically as the paragraph above mentions "forced out of the guest"
> really is just the hypervisor calling MADV_DONTNEED on the page in
> question. So the behavior is the same as any userspace application
> that calls MADV_DONTNEED where the contents are no longer accessible
> from userspace and attempting to access them will result in a fault
> and the page being populated with a zero fill on-demand page, or a
> copy of the file contents if the memory is file backed.
As I've said I have no idea about virt so this doesn't really tell me
much. Does that mean that if somebody allocates such a page and tries to
access it then virt will handle a fault and bring it back?
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
From: Alexander Duyck @ 2019-09-10 14:48 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190910122030.GV2063@dhcp22.suse.cz>
On Tue, Sep 10, 2019 at 5:20 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Sat 07-09-19 10:25:20, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >
> > Move the head/tail adding logic out of the shuffle code and into the
> > __free_one_page function since ultimately that is where it is really
> > needed anyway. By doing this we should be able to reduce the overhead
> > and can consolidate all of the list addition bits in one spot.
>
> This changelog doesn't really explain why we want this. You are
> reshuffling the code, allright, but why do we want to reshuffle? Is the
> result readability a better code reuse or something else? Where
> does the claimed reduced overhead coming from?
>
> From a quick look buddy_merge_likely looks nicer than the code splat
> we have. Good.
>
> But then
>
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>
> [...]
>
> > - if (is_shuffle_order(order))
> > - add_to_free_area_random(page, &zone->free_area[order],
> > - migratetype);
> > + area = &zone->free_area[order];
> > + if (is_shuffle_order(order) ? shuffle_pick_tail() :
> > + buddy_merge_likely(pfn, buddy_pfn, page, order))
>
> Ouch this is just awful don't you think?
Yeah. I am going to go with Kirill's suggestion and probably do
something more along the lines of:
bool to_tail;
...
if (is_shuffle_order(order))
to_tail = shuffle_pick_tail();
else
to_tail = buddy_merge_likely(pfn, buddy_pfn, page, order);
if (to_tail)
add_to_free_area_tail(page, area, migratetype);
else
add_to_free_area(page, area, migratetype);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Mainlining support for MStar ARMv7 SoCs; Where to start?
From: Matthias Brugger @ 2019-09-10 14:59 UTC (permalink / raw)
To: Daniel Palmer, linux-arm-kernel
In-Reply-To: <CAFr9PXkDNy7Xh+0rLqsoSfBF5suddB_tTeFxVZfBeJz2Feq-YQ@mail.gmail.com>
Hi Daniel,
On 10/09/2019 16:18, Daniel Palmer wrote:
> Hi all,
>
> I've been working independently on support for MStar's ARMv7 SoCs for
> a few months now
> and I'm at the point where it's probably good enough for general consumption.
>
> Right now I'm sitting on a bunch of commits that adds the new machine,
> adds support for the clocks, pinctrl etc all the way up to mmc host,
> ethernet and usb. I'm sure I can't drop all of that in one go but I'm
> unsure of what the initial set of commits should look like. For
> instance does it matter if the new machine is added but it's totally
> unusable because there is no support for the clocks or should I put
> together a package that is the minimum needed to get to a shell?
>
I think a shell is the minimum you should get to.
So my take would be to send basic DTS (and clocks, if needed) so that you can
boot into a shell, even using a initramfs.
For the rest I'd propose to send each driver as a independent series. If you
want to add the DTS patch which adds the driver to your board, then make sure to
notice that it is based on the basic support.
Hope that helps.
Regards,
Matthias
_______________________________________________
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] iommu/arm-smmu: fix "hang" when games exit
From: Robin Murphy @ 2019-09-10 15:01 UTC (permalink / raw)
To: Rob Clark, iommu
Cc: Rob Clark, Will Deacon, linux-arm-msm, Joerg Roedel, open list,
freedreno, moderated list:ARM SMMU DRIVERS
In-Reply-To: <20190907175013.24246-1-robdclark@gmail.com>
On 07/09/2019 18:50, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
>
> When games, browser, or anything using a lot of GPU buffers exits, there
> can be many hundreds or thousands of buffers to unmap and free. If the
> GPU is otherwise suspended, this can cause arm-smmu to resume/suspend
> for each buffer, resulting 5-10 seconds worth of reprogramming the
> context bank (arm_smmu_write_context_bank()/arm_smmu_write_s2cr()/etc).
> To the user it would appear that the system is locked up.
>
> A simple solution is to use pm_runtime_put_autosuspend() instead, so we
> don't immediately suspend the SMMU device.
>
> Signed-off-by: Rob Clark <robdclark@chromium.org>
> ---
> Note: I've tied the autosuspend enable/delay to the consumer device,
> based on the reasoning that if the consumer device benefits from using
> an autosuspend delay, then it's corresponding SMMU probably does too.
> Maybe that is overkill and we should just unconditionally enable
> autosuspend.
I'm not sure there's really any reason to expect that a supplier's usage
model when doing things for itself bears any relation to that of its
consumer(s), so I'd certainly lean towards the "unconditional" argument
myself.
Of course ideally we'd skip resuming altogether in the map/unmap paths
(since resume implies a full TLB reset anyway), but IIRC that approach
started to get messy in the context of the initial RPM patchset. I'm
planning to fiddle around a bit more to clean up the implementation of
the new iommu_flush_ops stuff, so I've made a note to myself to revisit
RPM to see if there's a sufficiently clean way to do better. In the
meantime, though, I don't have any real objection to using some
reasonable autosuspend delay on the principle that if we've been woken
up to map/unmap one page, there's a high likelihood that more will
follow in short order (and in the configuration slow-paths it won't have
much impact either way).
Robin.
> drivers/iommu/arm-smmu.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c2733b447d9c..73a0dd53c8a3 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -289,7 +289,7 @@ static inline int arm_smmu_rpm_get(struct arm_smmu_device *smmu)
> static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
> {
> if (pm_runtime_enabled(smmu->dev))
> - pm_runtime_put(smmu->dev);
> + pm_runtime_put_autosuspend(smmu->dev);
> }
>
> static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
> @@ -1445,6 +1445,15 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
> /* Looks ok, so add the device to the domain */
> ret = arm_smmu_domain_add_master(smmu_domain, fwspec);
>
> +#ifdef CONFIG_PM
> + /* TODO maybe device_link_add() should do this for us? */
> + if (dev->power.use_autosuspend) {
> + pm_runtime_set_autosuspend_delay(smmu->dev,
> + dev->power.autosuspend_delay);
> + pm_runtime_use_autosuspend(smmu->dev);
> + }
> +#endif
> +
> rpm_put:
> arm_smmu_rpm_put(smmu);
> return ret;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Mainlining support for MStar ARMv7 SoCs; Where to start?
From: Chen-Yu Tsai @ 2019-09-10 15:10 UTC (permalink / raw)
To: Daniel Palmer; +Cc: Matthias Brugger, linux-arm-kernel
In-Reply-To: <71d30e3f-65b3-0f0e-4078-f917b5d1f075@gmail.com>
On Tue, Sep 10, 2019 at 3:59 PM Matthias Brugger <matthias.bgg@gmail.com> wrote:
>
> Hi Daniel,
>
> On 10/09/2019 16:18, Daniel Palmer wrote:
> > Hi all,
> >
> > I've been working independently on support for MStar's ARMv7 SoCs for
> > a few months now
> > and I'm at the point where it's probably good enough for general consumption.
> >
> > Right now I'm sitting on a bunch of commits that adds the new machine,
> > adds support for the clocks, pinctrl etc all the way up to mmc host,
> > ethernet and usb. I'm sure I can't drop all of that in one go but I'm
> > unsure of what the initial set of commits should look like. For
> > instance does it matter if the new machine is added but it's totally
> > unusable because there is no support for the clocks or should I put
> > together a package that is the minimum needed to get to a shell?
> >
>
> I think a shell is the minimum you should get to.
> So my take would be to send basic DTS (and clocks, if needed) so that you can
> boot into a shell, even using a initramfs.
To expand on this, your basic DTS would likely include the CPU cores, an
interrupt controller (GIC?), a basic timer block (ARM arch timer?), the
UART(s), and a dummy clock for the UART(s).
If the hardware blocks are already supported in mainline, then the first
series would be extremely simple. Otherwise you would need to include
the drivers for the UART, timer, and interrupt controllers so you can
boot to a shell.
An old example would be the initial Allwinner support patches:
https://patchwork.kernel.org/patch/2838400/
Note the watchdog node is not needed.
ChenYu
> For the rest I'd propose to send each driver as a independent series. If you
> want to add the DTS patch which adds the driver to your board, then make sure to
> notice that it is based on the basic support.
>
> Hope that helps.
> Regards,
> Matthias
>
> _______________________________________________
> 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] irqchip/atmel-aic5: add support for sam9x60 irqchip
From: Alexandre Belloni @ 2019-09-10 15:15 UTC (permalink / raw)
To: Claudiu Beznea
Cc: mark.rutland, devicetree, jason, maz,
Sandeep Sheriker Mallikarjun, linux-kernel, ludovic.desroches,
robh+dt, tglx, linux-arm-kernel
In-Reply-To: <1568026835-6646-1-git-send-email-claudiu.beznea@microchip.com>
On 09/09/2019 14:00:35+0300, Claudiu Beznea wrote:
> From: Sandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com>
>
> Add support for SAM9X60 irqchip.
>
> Signed-off-by: Sandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com>
> [claudiu.beznea@microchip.com: update aic5_irq_fixups[], update
> documentation]
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> .../devicetree/bindings/interrupt-controller/atmel,aic.txt | 7 +++++--
> drivers/irqchip/irq-atmel-aic5.c | 10 ++++++++++
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
> index f4c5d34c4111..7079d44bf3ba 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
> @@ -1,8 +1,11 @@
> * Advanced Interrupt Controller (AIC)
>
> Required properties:
> -- compatible: Should be "atmel,<chip>-aic"
> - <chip> can be "at91rm9200", "sama5d2", "sama5d3" or "sama5d4"
> +- compatible: Should be:
> + - "atmel,<chip>-aic" where <chip> can be "at91rm9200", "sama5d2",
> + "sama5d3" or "sama5d4"
> + - "microchip,<chip>-aic" where <chip> can be "sam9x60"
> +
> - interrupt-controller: Identifies the node as an interrupt controller.
> - #interrupt-cells: The number of cells to define the interrupts. It should be 3.
> The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
> diff --git a/drivers/irqchip/irq-atmel-aic5.c b/drivers/irqchip/irq-atmel-aic5.c
> index 6acad2ea0fb3..29333497ba10 100644
> --- a/drivers/irqchip/irq-atmel-aic5.c
> +++ b/drivers/irqchip/irq-atmel-aic5.c
> @@ -313,6 +313,7 @@ static void __init sama5d3_aic_irq_fixup(void)
> static const struct of_device_id aic5_irq_fixups[] __initconst = {
> { .compatible = "atmel,sama5d3", .data = sama5d3_aic_irq_fixup },
> { .compatible = "atmel,sama5d4", .data = sama5d3_aic_irq_fixup },
> + { .compatible = "microchip,sam9x60", .data = sama5d3_aic_irq_fixup },
> { /* sentinel */ },
> };
>
> @@ -390,3 +391,12 @@ static int __init sama5d4_aic5_of_init(struct device_node *node,
> return aic5_of_init(node, parent, NR_SAMA5D4_IRQS);
> }
> IRQCHIP_DECLARE(sama5d4_aic5, "atmel,sama5d4-aic", sama5d4_aic5_of_init);
> +
> +#define NR_SAM9X60_IRQS 50
> +
> +static int __init sam9x60_aic5_of_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + return aic5_of_init(node, parent, NR_SAM9X60_IRQS);
> +}
> +IRQCHIP_DECLARE(sam9x60_aic5, "microchip,sam9x60-aic", sam9x60_aic5_of_init);
> --
> 2.7.4
>
--
Alexandre Belloni, 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 1/2] clk: at91: fix update bit maps on CFG_MOR write
From: Alexandre Belloni @ 2019-09-10 15:16 UTC (permalink / raw)
To: Eugen.Hristev
Cc: sboyd, mturquette, linux-kernel, Ludovic.Desroches, linux-clk,
linux-arm-kernel
In-Reply-To: <1568042692-11784-1-git-send-email-eugen.hristev@microchip.com>
On 09/09/2019 15:30:31+0000, Eugen.Hristev@microchip.com wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> The regmap update bits call was not selecting the proper mask, considering
> the bits which was updating.
> Update the mask from call to also include OSCBYPASS.
> Removed MOSCEN which was not updated.
>
> Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally")
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/clk/at91/clk-main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
> index f607ee7..ebe9b99 100644
> --- a/drivers/clk/at91/clk-main.c
> +++ b/drivers/clk/at91/clk-main.c
> @@ -152,7 +152,7 @@ at91_clk_register_main_osc(struct regmap *regmap,
> if (bypass)
> regmap_update_bits(regmap,
> AT91_CKGR_MOR, MOR_KEY_MASK |
> - AT91_PMC_MOSCEN,
> + AT91_PMC_OSCBYPASS,
> AT91_PMC_OSCBYPASS | AT91_PMC_KEY);
>
> hw = &osc->hw;
> --
> 2.7.4
>
--
Alexandre Belloni, 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: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
From: Qian Cai @ 2019-09-10 15:22 UTC (permalink / raw)
To: Petr Mladek, Steven Rostedt, Catalin Marinas, Will Deacon
Cc: Sergey Senozhatsky, Peter Zijlstra, linux-kernel, linux-mm,
Waiman Long, Dan Williams, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <1567717680.5576.104.camel@lca.pw>
On Thu, 2019-09-05 at 17:08 -0400, Qian Cai wrote:
> Another data point is if change CONFIG_DEBUG_OBJECTS_TIMERS from =y to =n, it
> will also fix it.
>
> On Thu, 2019-08-22 at 17:33 -0400, Qian Cai wrote:
> > https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
> >
> > Booting an arm64 ThunderX2 server with page_alloc.shuffle=1 [1] +
> > CONFIG_PROVE_LOCKING=y results in hanging.
> >
> > [1] https://lore.kernel.org/linux-mm/154899811208.3165233.17623209031065121886.s
> > tgit@dwillia2-desk3.amr.corp.intel.com/
> >
> > ...
> > [ 125.142689][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: option mask 0x2
> > [ 125.149687][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: ias 44-bit, oas 44-bit
> > (features 0x0000170d)
> > [ 125.165198][ T1] arm-smmu-v3 arm-smmu-v3.2.auto: allocated 524288 entries
> > for cmdq
> > [ 125.239425][ [ 125.251484][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: option
> > mask 0x2
> > [ 125.258233][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: ias 44-bit, oas 44-bit
> > (features 0x0000170d)
> > [ 125.282750][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: allocated 524288 entries
> > for cmdq
> > [ 125.320097][ T1] arm-smmu-v3 arm-smmu-v3.3.auto: allocated 524288 entries
> > for evtq
> > [ 125.332667][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: option mask 0x2
> > [ 125.339427][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas 44-bit
> > (features 0x0000170d)
> > [ 125.354846][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries
> > for cmdq
> > [ 125.375295][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries
> > for evtq
> > [ 125.387371][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2
> > [ 125.393955][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas 44-bit
> > (features 0x0000170d)
> > [ 125.522605][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries
> > for cmdq
> > [ 125.543338][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries
> > for evtq
> > [ 126.694742][ T1] EFI Variables Facility v0.08 2004-May-17
> > [ 126.799291][ T1] NET: Registered protocol family 17
> > [ 126.978632][ T1] zswap: loaded using pool lzo/zbud
> > [ 126.989168][ T1] kmemleak: Kernel memory leak detector initialized
> > [ 126.989191][ T1577] kmemleak: Automatic memory scanning thread started
> > [ 127.044079][ T1335] pcieport 0000:0f:00.0: Adding to iommu group 0
> > [ 127.388074][ T1] Freeing unused kernel memory: 22528K
> > [ 133.527005][ T1] Checked W+X mappings: passed, no W+X pages found
> > [ 133.533474][ T1] Run /init as init process
> > [ 133.727196][ T1] systemd[1]: System time before build time, advancing
> > clock.
> > [ 134.576021][ T1587] modprobe (1587) used greatest stack depth: 27056 bytes
> > left
> > [ 134.764026][ T1] systemd[1]: systemd 239 running in system mode. (+PAM
> > +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT
> > +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-
> > hierarchy=legacy)
> > [ 134.799044][ T1] systemd[1]: Detected architecture arm64.
> > [ 134.804818][ T1] systemd[1]: Running in initial RAM disk.
> > <...hang...>
> >
> > Fix it by either set page_alloc.shuffle=0 or CONFIG_PROVE_LOCKING=n which allow
> > it to continue successfully.
> >
> >
> > [ 121.093846][ T1] systemd[1]: Set hostname to <hpe-apollo-cn99xx>.
> > [ 123.157524][ T1] random: systemd: uninitialized urandom read (16 bytes
> > read)
> > [ 123.168562][ T1] systemd[1]: Listening on Journal Socket.
> > [ OK ] Listening on Journal Socket.
> > [ 123.203932][ T1] random: systemd: uninitialized urandom read (16 bytes
> > read)
> > [ 123.212813][ T1] systemd[1]: Listening on udev Kernel Socket.
> > [ OK ] Listening on udev Kernel Socket.
> > ...
Not sure if the arm64 hang is just an effect of the potential console deadlock
below. The lockdep splat can be reproduced by set,
CONFIG_DEBUG_OBJECTS_TIMER=n (=y will lead to the hang above)
CONFIG_PROVE_LOCKING=y
CONFIG_SLAB_FREELIST_RANDOM=y (with page_alloc.shuffle=1)
while compiling kernels,
[ 1078.214683][T43784] WARNING: possible circular locking dependency detected
[ 1078.221550][T43784] 5.3.0-rc7-next-20190904 #14 Not tainted
[ 1078.227112][T43784] ------------------------------------------------------
[ 1078.233976][T43784] vi/43784 is trying to acquire lock:
[ 1078.239192][T43784] ffff008b7cff9290 (&(&zone->lock)->rlock){-.-.}, at:
rmqueue_bulk.constprop.21+0xb0/0x1218
[ 1078.249111][T43784]
[ 1078.249111][T43784] but task is already holding lock:
[ 1078.256322][T43784] ffff00938db47d40 (&(&port->lock)->rlock){-.-.}, at:
pty_write+0x78/0x100
[ 1078.264760][T43784]
[ 1078.264760][T43784] which lock already depends on the new lock.
[ 1078.264760][T43784]
[ 1078.275008][T43784]
[ 1078.275008][T43784] the existing dependency chain (in reverse order) is:
[ 1078.283869][T43784]
[ 1078.283869][T43784] -> #3 (&(&port->lock)->rlock){-.-.}:
[ 1078.291350][T43784] __lock_acquire+0x5c8/0xbb0
[ 1078.296394][T43784] lock_acquire+0x154/0x428
[ 1078.301266][T43784] _raw_spin_lock_irqsave+0x80/0xa0
[ 1078.306831][T43784] tty_port_tty_get+0x28/0x68
[ 1078.311873][T43784] tty_port_default_wakeup+0x20/0x40
[ 1078.317523][T43784] tty_port_tty_wakeup+0x38/0x48
[ 1078.322827][T43784] uart_write_wakeup+0x2c/0x50
[ 1078.327956][T43784] pl011_tx_chars+0x240/0x260
[ 1078.332999][T43784] pl011_start_tx+0x24/0xa8
[ 1078.337868][T43784] __uart_start+0x90/0xa0
[ 1078.342563][T43784] uart_write+0x15c/0x2c8
[ 1078.347261][T43784] do_output_char+0x1c8/0x2b0
[ 1078.352304][T43784] n_tty_write+0x300/0x668
[ 1078.357087][T43784] tty_write+0x2e8/0x430
[ 1078.361696][T43784] redirected_tty_write+0xcc/0xe8
[ 1078.367086][T43784] do_iter_write+0x228/0x270
[ 1078.372041][T43784] vfs_writev+0x10c/0x1c8
[ 1078.376735][T43784] do_writev+0xdc/0x180
[ 1078.381257][T43784] __arm64_sys_writev+0x50/0x60
[ 1078.386476][T43784] el0_svc_handler+0x11c/0x1f0
[ 1078.391606][T43784] el0_svc+0x8/0xc
[ 1078.395691][T43784]
[ 1078.395691][T43784] -> #2 (&port_lock_key){-.-.}:
[ 1078.402561][T43784] __lock_acquire+0x5c8/0xbb0
[ 1078.407604][T43784] lock_acquire+0x154/0x428
[ 1078.412474][T43784] _raw_spin_lock+0x68/0x88
[ 1078.417343][T43784] pl011_console_write+0x2ac/0x318
[ 1078.422820][T43784] console_unlock+0x3c4/0x898
[ 1078.427863][T43784] vprintk_emit+0x2d4/0x460
[ 1078.432732][T43784] vprintk_default+0x48/0x58
[ 1078.437688][T43784] vprintk_func+0x194/0x250
[ 1078.442557][T43784] printk+0xbc/0xec
[ 1078.446732][T43784] register_console+0x4a8/0x580
[ 1078.451947][T43784] uart_add_one_port+0x748/0x878
[ 1078.457250][T43784] pl011_register_port+0x98/0x128
[ 1078.462639][T43784] sbsa_uart_probe+0x398/0x480
[ 1078.467772][T43784] platform_drv_probe+0x70/0x108
[ 1078.473075][T43784] really_probe+0x15c/0x5d8
[ 1078.477944][T43784] driver_probe_device+0x94/0x1d0
[ 1078.483335][T43784] __device_attach_driver+0x11c/0x1a8
[ 1078.489072][T43784] bus_for_each_drv+0xf8/0x158
[ 1078.494201][T43784] __device_attach+0x164/0x240
[ 1078.499331][T43784] device_initial_probe+0x24/0x30
[ 1078.504721][T43784] bus_probe_device+0xf0/0x100
[ 1078.509850][T43784] device_add+0x63c/0x960
[ 1078.514546][T43784] platform_device_add+0x1ac/0x3b8
[ 1078.520023][T43784] platform_device_register_full+0x1fc/0x290
[ 1078.526373][T43784] acpi_create_platform_device.part.0+0x264/0x3a8
[ 1078.533152][T43784] acpi_create_platform_device+0x68/0x80
[ 1078.539150][T43784] acpi_default_enumeration+0x34/0x78
[ 1078.544887][T43784] acpi_bus_attach+0x340/0x3b8
[ 1078.550015][T43784] acpi_bus_attach+0xf8/0x3b8
[ 1078.555057][T43784] acpi_bus_attach+0xf8/0x3b8
[ 1078.560099][T43784] acpi_bus_attach+0xf8/0x3b8
[ 1078.565142][T43784] acpi_bus_scan+0x9c/0x100
[ 1078.570015][T43784] acpi_scan_init+0x16c/0x320
[ 1078.575058][T43784] acpi_init+0x330/0x3b8
[ 1078.579666][T43784] do_one_initcall+0x158/0x7ec
[ 1078.584797][T43784] kernel_init_freeable+0x9a8/0xa70
[ 1078.590360][T43784] kernel_init+0x18/0x138
[ 1078.595055][T43784] ret_from_fork+0x10/0x1c
[ 1078.599835][T43784]
[ 1078.599835][T43784] -> #1 (console_owner){-...}:
[ 1078.606618][T43784] __lock_acquire+0x5c8/0xbb0
[ 1078.611661][T43784] lock_acquire+0x154/0x428
[ 1078.616530][T43784] console_unlock+0x298/0x898
[ 1078.621573][T43784] vprintk_emit+0x2d4/0x460
[ 1078.626442][T43784] vprintk_default+0x48/0x58
[ 1078.631398][T43784] vprintk_func+0x194/0x250
[ 1078.636267][T43784] printk+0xbc/0xec
[ 1078.640443][T43784] _warn_unseeded_randomness+0xb4/0xd0
[ 1078.646267][T43784] get_random_u64+0x4c/0x100
[ 1078.651224][T43784] add_to_free_area_random+0x168/0x1a0
[ 1078.657047][T43784] free_one_page+0x3dc/0xd08
[ 1078.662003][T43784] __free_pages_ok+0x490/0xd00
[ 1078.667132][T43784] __free_pages+0xc4/0x118
[ 1078.671914][T43784] __free_pages_core+0x2e8/0x428
[ 1078.677219][T43784] memblock_free_pages+0xa4/0xec
[ 1078.682522][T43784] memblock_free_all+0x264/0x330
[ 1078.687825][T43784] mem_init+0x90/0x148
[ 1078.692259][T43784] start_kernel+0x368/0x684
[ 1078.697126][T43784]
[ 1078.697126][T43784] -> #0 (&(&zone->lock)->rlock){-.-.}:
[ 1078.704604][T43784] check_prev_add+0x120/0x1138
[ 1078.709733][T43784] validate_chain+0x888/0x1270
[ 1078.714863][T43784] __lock_acquire+0x5c8/0xbb0
[ 1078.719906][T43784] lock_acquire+0x154/0x428
[ 1078.724776][T43784] _raw_spin_lock+0x68/0x88
[ 1078.729645][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
[ 1078.735643][T43784] get_page_from_freelist+0x898/0x24a0
[ 1078.741467][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
[ 1078.747291][T43784] alloc_pages_current+0xb4/0x150
[ 1078.752682][T43784] allocate_slab+0xab8/0x2350
[ 1078.757725][T43784] new_slab+0x98/0xc0
[ 1078.762073][T43784] ___slab_alloc+0x66c/0xa30
[ 1078.767029][T43784] __slab_alloc+0x68/0xc8
[ 1078.771725][T43784] __kmalloc+0x3d4/0x658
[ 1078.776333][T43784] __tty_buffer_request_room+0xd4/0x220
[ 1078.782244][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
[ 1078.788849][T43784] pty_write+0x98/0x100
[ 1078.793370][T43784] n_tty_write+0x2a0/0x668
[ 1078.798152][T43784] tty_write+0x2e8/0x430
[ 1078.802760][T43784] __vfs_write+0x5c/0xb0
[ 1078.807368][T43784] vfs_write+0xf0/0x230
[ 1078.811890][T43784] ksys_write+0xd4/0x180
[ 1078.816498][T43784] __arm64_sys_write+0x4c/0x60
[ 1078.821627][T43784] el0_svc_handler+0x11c/0x1f0
[ 1078.826756][T43784] el0_svc+0x8/0xc
[ 1078.830842][T43784]
[ 1078.830842][T43784] other info that might help us debug this:
[ 1078.830842][T43784]
[ 1078.840918][T43784] Chain exists of:
[ 1078.840918][T43784] &(&zone->lock)->rlock --> &port_lock_key --> &(&port-
>lock)->rlock
[ 1078.840918][T43784]
[ 1078.854731][T43784] Possible unsafe locking scenario:
[ 1078.854731][T43784]
[ 1078.862029][T43784] CPU0 CPU1
[ 1078.867243][T43784] ---- ----
[ 1078.872457][T43784] lock(&(&port->lock)->rlock);
[ 1078.877238][T43784] lock(&port_lock_key);
[ 1078.883929][T43784] lock(&(&port->lock)-
>rlock);
[ 1078.891228][T43784] lock(&(&zone->lock)->rlock);
[ 1078.896010][T43784]
[ 1078.896010][T43784] *** DEADLOCK ***
[ 1078.896010][T43784]
[ 1078.904004][T43784] 5 locks held by vi/43784:
[ 1078.908351][T43784] #0: ffff000c36240890 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x44/0x50
[ 1078.917133][T43784] #1: ffff000c36240918 (&tty->atomic_write_lock){+.+.},
at: tty_write_lock+0x24/0x60
[ 1078.926521][T43784] #2: ffff000c36240aa0 (&o_tty->termios_rwsem/1){++++},
at: n_tty_write+0x108/0x668
[ 1078.935823][T43784] #3: ffffa0001e0b2360 (&ldata->output_lock){+.+.}, at:
n_tty_write+0x1d0/0x668
[ 1078.944777][T43784] #4: ffff00938db47d40 (&(&port->lock)->rlock){-.-.}, at:
pty_write+0x78/0x100
[ 1078.953644][T43784]
[ 1078.953644][T43784] stack backtrace:
[ 1078.959382][T43784] CPU: 97 PID: 43784 Comm: vi Not tainted 5.3.0-rc7-next-
20190904 #14
[ 1078.967376][T43784] Hardware name: HPE Apollo
70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
[ 1078.977799][T43784] Call trace:
[ 1078.980932][T43784] dump_backtrace+0x0/0x228
[ 1078.985279][T43784] show_stack+0x24/0x30
[ 1078.989282][T43784] dump_stack+0xe8/0x13c
[ 1078.993370][T43784] print_circular_bug+0x334/0x3d8
[ 1078.998240][T43784] check_noncircular+0x268/0x310
[ 1079.003022][T43784] check_prev_add+0x120/0x1138
[ 1079.007631][T43784] validate_chain+0x888/0x1270
[ 1079.012241][T43784] __lock_acquire+0x5c8/0xbb0
[ 1079.016763][T43784] lock_acquire+0x154/0x428
[ 1079.021111][T43784] _raw_spin_lock+0x68/0x88
[ 1079.025460][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
[ 1079.030937][T43784] get_page_from_freelist+0x898/0x24a0
[ 1079.036240][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
[ 1079.041542][T43784] alloc_pages_current+0xb4/0x150
[ 1079.046412][T43784] allocate_slab+0xab8/0x2350
[ 1079.050934][T43784] new_slab+0x98/0xc0
[ 1079.054761][T43784] ___slab_alloc+0x66c/0xa30
[ 1079.059196][T43784] __slab_alloc+0x68/0xc8
[ 1079.063371][T43784] __kmalloc+0x3d4/0x658
[ 1079.067458][T43784] __tty_buffer_request_room+0xd4/0x220
[ 1079.072847][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
[ 1079.078932][T43784] pty_write+0x98/0x100
[ 1079.082932][T43784] n_tty_write+0x2a0/0x668
[ 1079.087193][T43784] tty_write+0x2e8/0x430
[ 1079.091280][T43784] __vfs_write+0x5c/0xb0
[ 1079.095367][T43784] vfs_write+0xf0/0x230
[ 1079.099368][T43784] ksys_write+0xd4/0x180
[ 1079.103455][T43784] __arm64_sys_write+0x4c/0x60
[ 1079.108064][T43784] el0_svc_handler+0x11c/0x1f0
[ 1079.112672][T43784] el0_svc+0x8/0xc
_______________________________________________
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] iommu/arm-smmu: fix "hang" when games exit
From: Rob Clark @ 2019-09-10 15:45 UTC (permalink / raw)
To: Robin Murphy
Cc: Rob Clark, Jordan Crouse, Will Deacon, linux-arm-msm,
Joerg Roedel, open list,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
freedreno, moderated list:ARM SMMU DRIVERS
In-Reply-To: <418d8426-f299-1269-2b2e-f86677cf22c2@arm.com>
On Tue, Sep 10, 2019 at 8:01 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 07/09/2019 18:50, Rob Clark wrote:
> > From: Rob Clark <robdclark@chromium.org>
> >
> > When games, browser, or anything using a lot of GPU buffers exits, there
> > can be many hundreds or thousands of buffers to unmap and free. If the
> > GPU is otherwise suspended, this can cause arm-smmu to resume/suspend
> > for each buffer, resulting 5-10 seconds worth of reprogramming the
> > context bank (arm_smmu_write_context_bank()/arm_smmu_write_s2cr()/etc).
> > To the user it would appear that the system is locked up.
> >
> > A simple solution is to use pm_runtime_put_autosuspend() instead, so we
> > don't immediately suspend the SMMU device.
> >
> > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > ---
> > Note: I've tied the autosuspend enable/delay to the consumer device,
> > based on the reasoning that if the consumer device benefits from using
> > an autosuspend delay, then it's corresponding SMMU probably does too.
> > Maybe that is overkill and we should just unconditionally enable
> > autosuspend.
>
> I'm not sure there's really any reason to expect that a supplier's usage
> model when doing things for itself bears any relation to that of its
> consumer(s), so I'd certainly lean towards the "unconditional" argument
> myself.
Sounds good, I'll respin w/ unconditional autosuspend
> Of course ideally we'd skip resuming altogether in the map/unmap paths
> (since resume implies a full TLB reset anyway), but IIRC that approach
> started to get messy in the context of the initial RPM patchset. I'm
> planning to fiddle around a bit more to clean up the implementation of
> the new iommu_flush_ops stuff, so I've made a note to myself to revisit
> RPM to see if there's a sufficiently clean way to do better. In the
> meantime, though, I don't have any real objection to using some
> reasonable autosuspend delay on the principle that if we've been woken
> up to map/unmap one page, there's a high likelihood that more will
> follow in short order (and in the configuration slow-paths it won't have
> much impact either way).
It does sort of remind me about something I was chatting with Jordan
the other day.. about how we could possibly skip the TLB inv for
unmaps from non-current pagetables once we have per-context
pagetables.
The challenge is, since the GPU's command parser is the one switching
pagetables, we don't have any race-free way to know which pagetables
are current. But we do know which contexts have work queued up for
the GPU, so we can know either that a given context definitely isn't
current, or that it might be current. And in the "definitely not
current" case we could skip TLB inv.
BR,
-R
>
> Robin.
>
> > drivers/iommu/arm-smmu.c | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > index c2733b447d9c..73a0dd53c8a3 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -289,7 +289,7 @@ static inline int arm_smmu_rpm_get(struct arm_smmu_device *smmu)
> > static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
> > {
> > if (pm_runtime_enabled(smmu->dev))
> > - pm_runtime_put(smmu->dev);
> > + pm_runtime_put_autosuspend(smmu->dev);
> > }
> >
> > static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
> > @@ -1445,6 +1445,15 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
> > /* Looks ok, so add the device to the domain */
> > ret = arm_smmu_domain_add_master(smmu_domain, fwspec);
> >
> > +#ifdef CONFIG_PM
> > + /* TODO maybe device_link_add() should do this for us? */
> > + if (dev->power.use_autosuspend) {
> > + pm_runtime_set_autosuspend_delay(smmu->dev,
> > + dev->power.autosuspend_delay);
> > + pm_runtime_use_autosuspend(smmu->dev);
> > + }
> > +#endif
> > +
> > rpm_put:
> > arm_smmu_rpm_put(smmu);
> > return ret;
> >
_______________________________________________
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: socfpga: re-use the `interface` parameter from platform data
From: David Miller @ 2019-09-10 15:45 UTC (permalink / raw)
To: alexandru.ardelean
Cc: alexandre.torgue, netdev, linux-kernel, joabreu, mcoquelin.stm32,
peppe.cavallaro, linux-stm32, linux-arm-kernel
In-Reply-To: <20190906123054.5514-1-alexandru.ardelean@analog.com>
From: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date: Fri, 6 Sep 2019 15:30:54 +0300
> The socfpga sub-driver defines an `interface` field in the `socfpga_dwmac`
> struct and parses it on init.
>
> The shared `stmmac_probe_config_dt()` function also parses this from the
> device-tree and makes it available on the returned `plat_data` (which is
> the same data available via `netdev_priv()`).
>
> All that's needed now is to dig that information out, via some
> `dev_get_drvdata()` && `netdev_priv()` calls and re-use it.
>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
This doesn't build even on net-next.
And if your patch does target net-next you must indicate this properly in the
Subject line as "[PATCH net-next]" vs. "[PATCH net]"
_______________________________________________
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: socfpga: re-use the `interface` parameter from platform data
From: David Miller @ 2019-09-10 15:46 UTC (permalink / raw)
To: alexandru.ardelean
Cc: alexandre.torgue, netdev, linux-kernel, joabreu, mcoquelin.stm32,
peppe.cavallaro, linux-stm32, linux-arm-kernel
In-Reply-To: <20190910.174544.945128884852877943.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 10 Sep 2019 17:45:44 +0200 (CEST)
> From: Alexandru Ardelean <alexandru.ardelean@analog.com>
> Date: Fri, 6 Sep 2019 15:30:54 +0300
>
>> The socfpga sub-driver defines an `interface` field in the `socfpga_dwmac`
>> struct and parses it on init.
>>
>> The shared `stmmac_probe_config_dt()` function also parses this from the
>> device-tree and makes it available on the returned `plat_data` (which is
>> the same data available via `netdev_priv()`).
>>
>> All that's needed now is to dig that information out, via some
>> `dev_get_drvdata()` && `netdev_priv()` calls and re-use it.
>>
>> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
>
> This doesn't build even on net-next.
Specifically:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c: In function ‘socfpga_gen5_set_phy_mode’:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:264:44: error: ‘phymode’ undeclared (first use in this function); did you mean ‘phy_modes’?
264 | dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
| ^~~~~~~
./include/linux/device.h:1499:32: note: in definition of macro ‘dev_err’
1499 | _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~~~~~
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:264:44: note: each undeclared identifier is reported only once for each function it appears in
264 | dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
| ^~~~~~~
./include/linux/device.h:1499:32: note: in definition of macro ‘dev_err’
1499 | _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~~~~~
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c: In function ‘socfpga_gen10_set_phy_mode’:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:340:6: error: ‘phymode’ undeclared (first use in this function); did you mean ‘phy_modes’?
340 | phymode == PHY_INTERFACE_MODE_MII ||
| ^~~~~~~
| phy_modes
_______________________________________________
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] ARM: omap3: Enable HWMODS for HW Random Number Generator
From: Adam Ford @ 2019-09-10 15:48 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Rutland, devicetree, Paul Walmsley, Aaro Koskinen,
Russell King, Linux Kernel Mailing List, Tero Kristo, Rob Herring,
Benoît Cousson, Pali Rohár, Linux-OMAP, Adam Ford,
arm-soc
In-Reply-To: <20190909163543.GQ52127@atomide.com>
On Mon, Sep 9, 2019 at 11:35 AM Tony Lindgren <tony@atomide.com> wrote:
>
> * Pali Rohár <pali.rohar@gmail.com> [190909 13:41]:
> > On Monday 09 September 2019 08:37:09 Adam Ford wrote:
> > > I applied this on 5.3 and it is working. I assume the same is true in for-next.
>
> Hmm I noticed I stopped getting RNG data after several rmmod modprobe
> cycles, or several hd /dev/random reads. Anybody else seeing that?
>
> > > Do you want to submit a formal patch? I can mark it as 'tested-by'
> > > This really helps speed up the startup sequence on boards with sshd
> > > because it delays for nearly 80 seconds waiting for entropy without
> > > the hwrng.
> >
> > Hi! When applying a patch, could you please disable this rng for n900?
> >
> > In omap3-n900.dts for rng should be status = "disabled" (as Tony already
> > wrote), similarly like for aes.
>
> Yeah I'll post a proper patch after -rc1.
FYI,
By putting your node into omap34xx.dtsi and omap36xx.dtsi along with
the following, I can get the RNG to work on an OMAP3530 and a DM3730.
diff --git a/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
b/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
index 5e9d1afcd422..73f351e6d132 100644
--- a/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
@@ -259,7 +259,7 @@
<&i2c1_ick>, <&uart2_ick>, <&uart1_ick>, <&gpt11_ick>,
<&gpt10_ick>, <&mcbsp5_ick>, <&mcbsp1_ick>,
<&omapctrl_ick>, <&aes2_ick>, <&sha12_ick>, <&icr_ick>,
- <&des2_ick>, <&mspro_ick>, <&mailboxes_ick>,
+ <&des2_ick>, <&mspro_ick>, <&mailboxes_ick>,
<&rng_ick>,
<&mspro_fck>;
};
};
I tried doing the same for am3517, but it doesn't appear to work. In
fact, the board hangs at boot with no splat, so I assume that some
clock isn't running and causing a hang. Figure 4-50 in the AM3517 TRM
shows the security_l4_iclk2, so I wonder if the HW mods for AES, SHA,
etc are doing something to enable this clock. Those HWmods are
disabled on AM3517. I tried turning on the hwmods for them before
without success, but I'll try it again.
adam
>
> Regards,
>
> Tony
_______________________________________________
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: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: tinywrkb @ 2019-09-10 15:55 UTC (permalink / raw)
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Fabio Estevam, Sascha Hauer, tinywrkb, Russell King, open list,
Rob Herring, NXP Linux Team, Pengutronix Kernel Team, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
This adds a phy node to the MicroSoM DTS and a 100Mb/s max-speed limit
to the Cubox-i Solo/DualLite carrier DTS.
Signed-off-by: tinywrkb <tinywrkb@gmail.com>
---
This patch fixes ethernet on my Cubox-i2-300-D which is limited to 100Mb/s,
afaik due to the carrier board magnetics, and was since commit 5502b218e001
("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
The AR8035 PHY on the CPU module reports to the driver as 1GbE capable
via MII_BSMR's BMSR_ESTATEN status bit, the auto-negotiation sets the
speed at 1GbE while the carrier board can't support it.
Same behavior with the generic phy_device and the at803x drivers.
While the PHY is on the CPU module board I added the max-speed limit to
the cubox-i carrier DTS as I suspect that if the Solo or DualLite v1.3
MicroSoM will be connected to a 1GbE capable carrier board then it would
work correctly with 1GbE.
I can confirm that this commit doesn't break networking on the my
Cubox-i4Pro Quad (i4P-300-D) with it's 1GbE capable carrier board, and
was tested separately with the generic phy_device and at803x drivers.
arch/arm/boot/dts/imx6dl-cubox-i.dts | 4 ++++
arch/arm/boot/dts/imx6qdl-sr-som.dtsi | 9 +++++++++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-cubox-i.dts b/arch/arm/boot/dts/imx6dl-cubox-i.dts
index 2b1b3e193f53..cfc82513c78c 100644
--- a/arch/arm/boot/dts/imx6dl-cubox-i.dts
+++ b/arch/arm/boot/dts/imx6dl-cubox-i.dts
@@ -49,3 +49,7 @@
model = "SolidRun Cubox-i Solo/DualLite";
compatible = "solidrun,cubox-i/dl", "fsl,imx6dl";
};
+
+ðphy {
+ max-speed = <100>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
index 6d7f6b9035bc..969bc96c3f99 100644
--- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
@@ -57,6 +57,15 @@
phy-reset-duration = <2>;
phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
status = "okay";
+ phy-handle = <ðphy>;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethphy: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+ };
};
&iomuxc {
--
2.23.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 v9 0/8] stg mail -e --version=v9 \
From: Alexander Duyck @ 2019-09-10 16:05 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190910144713.GF2063@dhcp22.suse.cz>
On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > have no clue on what is going on so returned to the cover and it didn't
> > > really help much. I am completely unfamiliar with virtio so please bear
> > > with me.
> > >
> > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > [...]
> > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > that a guest page is no longer in use and can have the data associated
> > > > with it dropped. To do this I have implemented functionality that allows
> > > > for what I am referring to as unused page reporting
> > > >
> > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > statistics to track the number of reported pages in a given free area.
> > > > When the number of free pages exceeds this value plus a high water value,
> > > > currently 32, it will begin performing page reporting which consists of
> > > > pulling pages off of free list and placing them into a scatter list. The
> > > > scatterlist is then given to the page reporting device and it will perform
> > > > the required action to make the pages "reported", in the case of
> > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > and as such they are forced out of the guest. After this they are placed
> > > > back on the free list,
> > >
> > > And here I am reallly lost because "forced out of the guest" makes me
> > > feel that those pages are no longer usable by the guest. So how come you
> > > can add them back to the free list. I suspect understanding this part
> > > will allow me to understand why we have to mark those pages and prevent
> > > merging.
> >
> > Basically as the paragraph above mentions "forced out of the guest"
> > really is just the hypervisor calling MADV_DONTNEED on the page in
> > question. So the behavior is the same as any userspace application
> > that calls MADV_DONTNEED where the contents are no longer accessible
> > from userspace and attempting to access them will result in a fault
> > and the page being populated with a zero fill on-demand page, or a
> > copy of the file contents if the memory is file backed.
>
> As I've said I have no idea about virt so this doesn't really tell me
> much. Does that mean that if somebody allocates such a page and tries to
> access it then virt will handle a fault and bring it back?
Actually I am probably describing too much as the MADV_DONTNEED is the
hypervisor behavior in response to the virtio-balloon notification. A
more thorough explanation of it can be found by just running "man
madvise", probably best just to leave it at that since I am probably
confusing things by describing hypervisor behavior in a kernel patch
set.
For the most part all the page reporting really does is provide a way
to incrementally identify unused regions of memory in the buddy
allocator. That in turn is used by virtio-balloon in a polling thread
to report to the hypervisor what pages are not in use so that it can
make a decision on what to do with the pages now that it knows they
are unused.
All this is providing is just a report and it is optional if the
hypervisor will act on it or not. If the hypervisor takes some sort of
action on the page, then the expectation is that the hypervisor will
use some sort of mechanism such as a page fault to discover when the
page is used again.
_______________________________________________
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