[PATCH RFC net-next 11/19] net: mvpp2: add flow control RXQ and BM pool config callbacks

[stefanc]

From: Stefan Chulski 

This patch did not change any functionality.
Added flow control RXQ and BM pool config callbacks that would be
used to configure RXQ and BM pool thresholds.
APIs also will disable/enable RXQ and pool Flow Control polling.

In this stage BM pool and RXQ has same stop/start thresholds
defined in code.
Also there are common thresholds for all RXQs.

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h  |  51 +-
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 169 
 2 files changed, 216 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 4d58af6..0ba0598 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -763,10 +763,53 @@
((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
 
 /* MSS Flow control */
-#define MSS_SRAM_SIZE  0x800
-#define FC_QUANTA  0x
-#define FC_CLK_DIVIDER 0x140
-#define MSS_THRESHOLD_STOP768
+#define MSS_SRAM_SIZE  0x800
+#define MSS_FC_COM_REG 0
+#define FLOW_CONTROL_ENABLE_BITBIT(0)
+#define FLOW_CONTROL_UPDATE_COMMAND_BITBIT(31)
+#define FC_QUANTA  0x
+#define FC_CLK_DIVIDER 0x140
+
+#define MSS_BUF_POOL_BASE  0x40
+#define MSS_BUF_POOL_OFFS  4
+#define MSS_BUF_POOL_REG(id)   (MSS_BUF_POOL_BASE  \
+   + (id) * MSS_BUF_POOL_OFFS)
+
+#define MSS_BUF_POOL_STOP_MASK 0xFFF
+#define MSS_BUF_POOL_START_MASK(0xFFF << 
MSS_BUF_POOL_START_OFFS)
+#define MSS_BUF_POOL_START_OFFS12
+#define MSS_BUF_POOL_PORTS_MASK(0xF << MSS_BUF_POOL_PORTS_OFFS)
+#define MSS_BUF_POOL_PORTS_OFFS24
+#define MSS_BUF_POOL_PORT_OFFS(id) (0x1 << \
+   ((id) + MSS_BUF_POOL_PORTS_OFFS))
+
+#define MSS_RXQ_TRESH_BASE 0x200
+#define MSS_RXQ_TRESH_OFFS 4
+#define MSS_RXQ_TRESH_REG(q, fq)   (MSS_RXQ_TRESH_BASE + (((q) + (fq)) \
+   * MSS_RXQ_TRESH_OFFS))
+
+#define MSS_RXQ_TRESH_START_MASK   0x
+#define MSS_RXQ_TRESH_STOP_MASK(0x << 
MSS_RXQ_TRESH_STOP_OFFS)
+#define MSS_RXQ_TRESH_STOP_OFFS16
+
+#define MSS_RXQ_ASS_BASE   0x80
+#define MSS_RXQ_ASS_OFFS   4
+#define MSS_RXQ_ASS_PER_REG4
+#define MSS_RXQ_ASS_PER_OFFS   8
+#define MSS_RXQ_ASS_PORTID_OFFS0
+#define MSS_RXQ_ASS_PORTID_MASK0x3
+#define MSS_RXQ_ASS_HOSTID_OFFS2
+#define MSS_RXQ_ASS_HOSTID_MASK0x3F
+
+#define MSS_RXQ_ASS_Q_BASE(q, fq) q) + (fq)) % MSS_RXQ_ASS_PER_REG)
 \
+ * MSS_RXQ_ASS_PER_OFFS)
+#define MSS_RXQ_ASS_PQ_BASE(q, fq) q) + (fq)) / MSS_RXQ_ASS_PER_REG) \
+  * MSS_RXQ_ASS_OFFS)
+#define MSS_RXQ_ASS_REG(q, fq) (MSS_RXQ_ASS_BASE + MSS_RXQ_ASS_PQ_BASE(q, fq))
+
+#define MSS_THRESHOLD_STOP 768
+#define MSS_THRESHOLD_START1024
+
 
 /* RX buffer constants */
 #define MVPP2_SKB_SHINFO_SIZE \
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index bc4b8069..19648c4 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -744,6 +744,175 @@ static void *mvpp2_buf_alloc(struct mvpp2_port *port,
return data;
 }
 
+/* Routine calculate single queue shares address space */
+static int mvpp22_calc_shared_addr_space(struct mvpp2_port *port)
+{
+   /* If number of CPU's greater than number of threads, return last
+* address space
+*/
+   if (num_active_cpus() >= MVPP2_MAX_THREADS)
+   return MVPP2_MAX_THREADS - 1;
+
+   return num_active_cpus();
+}
+
+/* Routine enable flow control for RXQs conditon */
+void mvpp2_rxq_enable_fc(struct mvpp2_port *port)
+{
+   int val, cm3_state, host_id, q;
+   int fq = port->first_rxq;
+   unsigned long flags;
+
+   spin_lock_irqsave(&port->priv->mss_spinlock, flags);
+
+   /* Remove Flow control enable bit to prevent race between FW and Kernel
+* If Flow control were enabled, it would be re-enabled.
+*/
+   val = mvpp2_cm3_read(port->priv, MSS_FC_COM_REG);
+   cm3_state = (val & FLOW_CONTROL_ENABLE_BIT);
+   val &= ~FLOW_CONTROL_ENABLE_BIT;
+   mvpp2_cm3_write(port->priv, MSS_FC_COM_REG, val);
+
+   /* Set same Flow control for all RXQs */
+   for (q = 0; q < port->nrxqs; q++) {
+   /* Set stop and start Flow control RXQ thresholds */
+   val = MSS_THRESHOLD_START;
+   val |= (MSS_THRESHOLD_STOP << MSS_RXQ_TRESH_STOP_OFFS);
+   mvpp2_cm3_write(port->priv, MSS_RX

[PATCH RFC net-next 12/19] net: mvpp2: enable global flow control

[stefanc]

From: Stefan Chulski 

This patch enable global flow control in FW.
Per port flow control is still disabled.

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h  |  3 +++
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 15 ++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 0ba0598..e6bab52 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -1065,6 +1065,9 @@ struct mvpp2 {
/* CM3 SRAM pool */
struct gen_pool *sram_pool;
 
+   /* Global TX Flow Control config */
+   bool global_tx_fc;
+
bool custom_dma_mask;
 
/* Spinlocks for CM3 shared memory configuration */
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 19648c4..b7ea94f 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -7142,7 +7142,7 @@ static int mvpp2_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *base;
int i, shared;
-   int err;
+   int err, val;
 
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -7194,6 +7194,10 @@ static int mvpp2_probe(struct platform_device *pdev)
err = mvpp2_get_sram(pdev, priv);
if (err)
dev_warn(&pdev->dev, "Fail to alloc CM3 SRAM\n");
+
+   /* Enable global Flow Control only if hanler to SRAM not NULL */
+   if (priv->cm3_base)
+   priv->global_tx_fc = true;
}
 
if (priv->hw_version != MVPP21 && dev_of_node(&pdev->dev)) {
@@ -7364,6 +7368,15 @@ static int mvpp2_probe(struct platform_device *pdev)
goto err_port_probe;
}
 
+   /* Enable global flow control. In this stage global
+* flow control enabled, but still disabled per port.
+*/
+   if (priv->global_tx_fc && priv->hw_version != MVPP21) {
+   val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
+   val |= FLOW_CONTROL_ENABLE_BIT;
+   mvpp2_cm3_write(priv, MSS_FC_COM_REG, val);
+   }
+
mvpp2_dbgfs_init(priv, pdev->name);
 
platform_set_drvdata(pdev, priv);
-- 
1.9.1

[PATCH RFC net-next 08/19] net: mvpp2: add FCA periodic timer configurations

[stefanc]

From: Stefan Chulski 

Flow Control periodic timer would be used if port in
XOFF to transmit periodic XOFF frames.

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h  | 13 +-
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 45 
 2 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index cac9885..0861c0b 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -596,6 +596,15 @@
 #define MVPP22_MPCS_CLK_RESET_DIV_RATIO(n) ((n) << 4)
 #define MVPP22_MPCS_CLK_RESET_DIV_SET  BIT(11)
 
+/* FCA registers. PPv2.2 and PPv2.3 */
+#define MVPP22_FCA_BASE(port)  (0x7600 + (port) * 0x1000)
+#define MVPP22_FCA_REG_SIZE16
+#define MVPP22_FCA_REG_MASK0x
+#define MVPP22_FCA_CONTROL_REG 0x0
+#define MVPP22_FCA_ENABLE_PERIODIC BIT(11)
+#define MVPP22_PERIODIC_COUNTER_LSB_REG(0x110)
+#define MVPP22_PERIODIC_COUNTER_MSB_REG(0x114)
+
 /* XPCS registers. PPv2.2 and PPv2.3 */
 #define MVPP22_XPCS_BASE(port) (0x7400 + (port) * 0x1000)
 #define MVPP22_XPCS_CFG0   0x0
@@ -752,7 +761,9 @@
((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
 
 /* MSS Flow control */
-#define MSS_SRAM_SIZE  0x800
+#define MSS_SRAM_SIZE  0x800
+#define FC_QUANTA  0x
+#define FC_CLK_DIVIDER 0x140
 
 /* RX buffer constants */
 #define MVPP2_SKB_SHINFO_SIZE \
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index aa1f6b4..b5b7902 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1293,6 +1293,49 @@ static void mvpp22_gop_init_10gkr(struct mvpp2_port 
*port)
writel(val, mpcs + MVPP22_MPCS_CLK_RESET);
 }
 
+static void mvpp22_gop_fca_enable_periodic(struct mvpp2_port *port, bool en)
+{
+   struct mvpp2 *priv = port->priv;
+   void __iomem *fca = priv->iface_base + MVPP22_FCA_BASE(port->gop_id);
+   u32 val;
+
+   val = readl(fca + MVPP22_FCA_CONTROL_REG);
+   val &= ~MVPP22_FCA_ENABLE_PERIODIC;
+   if (en)
+   val |= MVPP22_FCA_ENABLE_PERIODIC;
+   writel(val, fca + MVPP22_FCA_CONTROL_REG);
+}
+
+static void mvpp22_gop_fca_set_timer(struct mvpp2_port *port, u32 timer)
+{
+   struct mvpp2 *priv = port->priv;
+   void __iomem *fca = priv->iface_base + MVPP22_FCA_BASE(port->gop_id);
+   u32 lsb, msb;
+
+   lsb = timer & MVPP22_FCA_REG_MASK;
+   msb = timer >> MVPP22_FCA_REG_SIZE;
+
+   writel(lsb, fca + MVPP22_PERIODIC_COUNTER_LSB_REG);
+   writel(msb, fca + MVPP22_PERIODIC_COUNTER_MSB_REG);
+}
+
+/* Set Flow Control timer x140 faster than pause quanta to ensure that link
+ * partner won't send taffic if port in XOFF mode.
+ */
+static void mvpp22_gop_fca_set_periodic_timer(struct mvpp2_port *port)
+{
+   u32 timer;
+
+   timer = (port->priv->tclk / (USEC_PER_SEC * FC_CLK_DIVIDER))
+   * FC_QUANTA;
+
+   mvpp22_gop_fca_enable_periodic(port, false);
+
+   mvpp22_gop_fca_set_timer(port, timer);
+
+   mvpp22_gop_fca_enable_periodic(port, true);
+}
+
 static int mvpp22_gop_init(struct mvpp2_port *port)
 {
struct mvpp2 *priv = port->priv;
@@ -1337,6 +1380,8 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
val |= GENCONF_SOFT_RESET1_GOP;
regmap_write(priv->sysctrl_base, GENCONF_SOFT_RESET1, val);
 
+   mvpp22_gop_fca_set_periodic_timer(port);
+
 unsupported_conf:
return 0;
 
-- 
1.9.1

[PATCH RFC net-next 13/19] net: mvpp2: add RXQ flow control configurations

[stefanc]

From: Stefan Chulski 

This patch add RXQ flow control configurations.
Patch do not enable flow control itself, flow control
disabled by default.

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h  | 3 +++
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index e6bab52..57f7bbc 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -1234,6 +1234,9 @@ struct mvpp2_port {
bool rx_hwtstamp;
enum hwtstamp_tx_types tx_hwtstamp_type;
struct mvpp2_hwtstamp_queue tx_hwtstamp_queue[2];
+
+   /* Firmware TX flow control */
+   bool tx_fc;
 };
 
 /* The mvpp2_tx_desc and mvpp2_rx_desc structures describe the
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index b7ea94f..3b85aec 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3176,6 +3176,9 @@ static void mvpp2_cleanup_rxqs(struct mvpp2_port *port)
 
for (queue = 0; queue < port->nrxqs; queue++)
mvpp2_rxq_deinit(port, port->rxqs[queue]);
+
+   if (port->tx_fc)
+   mvpp2_rxq_disable_fc(port);
 }
 
 /* Init all Rx queues for port */
@@ -3188,6 +3191,10 @@ static int mvpp2_setup_rxqs(struct mvpp2_port *port)
if (err)
goto err_cleanup;
}
+
+   if (port->tx_fc)
+   mvpp2_rxq_enable_fc(port);
+
return 0;
 
 err_cleanup:
-- 
1.9.1

[PATCH RFC net-next 14/19] net: mvpp2: add ethtool flow control configuration support

[stefanc]

From: Stefan Chulski 

This patch add ethtool flow control configuration support.

Tx flow control retrieved correctly by ethtool get function.
FW per port ethtool configuration capability added.

Patch also takes care about mtu change procedure, if PPv2 switch
BM pools during mtu change.

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 53 
 1 file changed, 53 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 3b85aec..4869b14 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1243,6 +1243,16 @@ static int mvpp2_bm_update_mtu(struct net_device *dev, 
int mtu)
new_long_pool = MVPP2_BM_LONG;
 
if (new_long_pool != port->pool_long->id) {
+   if (port->tx_fc) {
+   if (pkt_size > MVPP2_BM_LONG_PKT_SIZE)
+   mvpp2_bm_pool_update_fc(port,
+   port->pool_short,
+   false);
+   else
+   mvpp2_bm_pool_update_fc(port, port->pool_long,
+   false);
+   }
+
/* Remove port from old short & long pool */
port->pool_long = mvpp2_bm_pool_use(port, port->pool_long->id,
port->pool_long->pkt_size);
@@ -1260,6 +1270,25 @@ static int mvpp2_bm_update_mtu(struct net_device *dev, 
int mtu)
mvpp2_swf_bm_pool_init(port);
 
mvpp2_set_hw_csum(port, new_long_pool);
+
+   if (port->tx_fc) {
+   if (pkt_size > MVPP2_BM_LONG_PKT_SIZE)
+   mvpp2_bm_pool_update_fc(port, port->pool_long,
+   true);
+   else
+   mvpp2_bm_pool_update_fc(port, port->pool_short,
+   true);
+   }
+
+   /* Update L4 checksum when jumbo enable/disable on port */
+   if (new_long_pool == MVPP2_BM_JUMBO && port->id != 0) {
+   dev->features &= ~(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM);
+   dev->hw_features &= ~(NETIF_F_IP_CSUM |
+ NETIF_F_IPV6_CSUM);
+   } else {
+   dev->features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
+   dev->hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
+   }
}
 
 out_set:
@@ -5373,6 +5402,30 @@ static int mvpp2_ethtool_set_pause_param(struct 
net_device *dev,
 struct ethtool_pauseparam *pause)
 {
struct mvpp2_port *port = netdev_priv(dev);
+   int i;
+
+   if (pause->tx_pause && port->priv->global_tx_fc) {
+   port->tx_fc = true;
+   mvpp2_rxq_enable_fc(port);
+   if (port->priv->percpu_pools) {
+   for (i = 0; i < port->nrxqs; i++)
+   mvpp2_bm_pool_update_fc(port, 
&port->priv->bm_pools[i], true);
+   } else {
+   mvpp2_bm_pool_update_fc(port, port->pool_long, true);
+   mvpp2_bm_pool_update_fc(port, port->pool_short, true);
+   }
+
+   } else if (port->priv->global_tx_fc) {
+   port->tx_fc = false;
+   mvpp2_rxq_disable_fc(port);
+   if (port->priv->percpu_pools) {
+   for (i = 0; i < port->nrxqs; i++)
+   mvpp2_bm_pool_update_fc(port, 
&port->priv->bm_pools[i], false);
+   } else {
+   mvpp2_bm_pool_update_fc(port, port->pool_long, false);
+   mvpp2_bm_pool_update_fc(port, port->pool_short, false);
+   }
+   }
 
if (!port->phylink)
return -ENOTSUPP;
-- 
1.9.1

[PATCH RFC net-next 15/19] net: mvpp2: add BM protection underrun feature support

[stefanc]

From: Stefan Chulski 

Feature double size of BPPI by decreasing number of pools from 16 to 8.
Increasing of BPPI size protect BM drop from BPPI underrun.
Underrun could occurred due to stress on DDR and as result slow buffer
transition from BPPE to BPPI.
New BPPI threshold recommended by spec is:
BPPI low threshold - 640 buffers
BPPI high threshold - 832 buffers
Supported only in PPv23.

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h  |  8 +
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 36 +++-
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 57f7bbc..27aa593 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -324,6 +324,10 @@
 #define MVPP2_BM_HIGH_THRESH_MASK  0x7f
 #define MVPP2_BM_HIGH_THRESH_VALUE(val)((val) << \
MVPP2_BM_HIGH_THRESH_OFFS)
+#define MVPP2_BM_BPPI_HIGH_THRESH  0x1E
+#define MVPP2_BM_BPPI_LOW_THRESH   0x1C
+#define MVPP23_BM_BPPI_HIGH_THRESH 0x34
+#define MVPP23_BM_BPPI_LOW_THRESH  0x28
 #define MVPP2_BM_INTR_CAUSE_REG(pool)  (0x6240 + ((pool) * 4))
 #define MVPP2_BM_RELEASED_DELAY_MASK   BIT(0)
 #define MVPP2_BM_ALLOC_FAILED_MASK BIT(1)
@@ -352,6 +356,10 @@
 #define MVPP2_OVERRUN_ETH_DROP 0x7000
 #define MVPP2_CLS_ETH_DROP 0x7020
 
+#define MVPP22_BM_POOL_BASE_ADDR_HIGH_REG  0x6310
+#define MVPP22_BM_POOL_BASE_ADDR_HIGH_MASK 0xff
+#define MVPP23_BM_8POOL_MODE   BIT(8)
+
 /* Hit counters registers */
 #define MVPP2_CTRS_IDX 0x7040
 #define MVPP22_CTRS_TX_CTR(port, txq)  ((txq) | ((port) << 3) | BIT(7))
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 4869b14..8827f52 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -70,6 +70,11 @@ enum mvpp2_bm_pool_log_num {
 module_param(queue_mode, int, 0444);
 MODULE_PARM_DESC(queue_mode, "Set queue_mode (single=0, multi=1)");
 
+static int bm_underrun_protect = 1;
+
+module_param(bm_underrun_protect, int, 0444);
+MODULE_PARM_DESC(bm_underrun_protect, "Set BM underrun protect feature (0-1), 
def=1");
+
 /* Utility/helper methods */
 
 void mvpp2_write(struct mvpp2 *priv, u32 offset, u32 data)
@@ -426,6 +431,21 @@ static int mvpp2_bm_pool_create(struct device *dev, struct 
mvpp2 *priv,
 
val = mvpp2_read(priv, MVPP2_BM_POOL_CTRL_REG(bm_pool->id));
val |= MVPP2_BM_START_MASK;
+
+   val &= ~MVPP2_BM_LOW_THRESH_MASK;
+   val &= ~MVPP2_BM_HIGH_THRESH_MASK;
+
+   /* Set 8 Pools BPPI threshold if BM underrun protection feature
+* were enabled
+*/
+   if (priv->hw_version == MVPP23 && bm_underrun_protect) {
+   val |= MVPP2_BM_LOW_THRESH_VALUE(MVPP23_BM_BPPI_LOW_THRESH);
+   val |= MVPP2_BM_HIGH_THRESH_VALUE(MVPP23_BM_BPPI_HIGH_THRESH);
+   } else {
+   val |= MVPP2_BM_LOW_THRESH_VALUE(MVPP2_BM_BPPI_LOW_THRESH);
+   val |= MVPP2_BM_HIGH_THRESH_VALUE(MVPP2_BM_BPPI_HIGH_THRESH);
+   }
+
mvpp2_write(priv, MVPP2_BM_POOL_CTRL_REG(bm_pool->id), val);
 
bm_pool->size = size;
@@ -594,6 +614,16 @@ static int mvpp2_bm_pools_init(struct device *dev, struct 
mvpp2 *priv)
return err;
 }
 
+/* Routine enable PPv23 8 pool mode */
+static void mvpp23_bm_set_8pool_mode(struct mvpp2 *priv)
+{
+   int val;
+
+   val = mvpp2_read(priv, MVPP22_BM_POOL_BASE_ADDR_HIGH_REG);
+   val |= MVPP23_BM_8POOL_MODE;
+   mvpp2_write(priv, MVPP22_BM_POOL_BASE_ADDR_HIGH_REG, val);
+}
+
 static int mvpp2_bm_init(struct device *dev, struct mvpp2 *priv)
 {
enum dma_data_direction dma_dir = DMA_FROM_DEVICE;
@@ -647,6 +677,9 @@ static int mvpp2_bm_init(struct device *dev, struct mvpp2 
*priv)
if (!priv->bm_pools)
return -ENOMEM;
 
+   if (priv->hw_version == MVPP23 && bm_underrun_protect)
+   mvpp23_bm_set_8pool_mode(priv);
+
err = mvpp2_bm_pools_init(dev, priv);
if (err < 0)
return err;
@@ -5404,7 +5437,8 @@ static int mvpp2_ethtool_set_pause_param(struct 
net_device *dev,
struct mvpp2_port *port = netdev_priv(dev);
int i;
 
-   if (pause->tx_pause && port->priv->global_tx_fc) {
+   if (pause->tx_pause && port->priv->global_tx_fc &&
+   bm_underrun_protect) {
port->tx_fc = true;
mvpp2_rxq_enable_fc(port);
if (port->priv->percpu_pools) {
-- 
1.9.1

[PATCH RFC net-next 16/19] net: mvpp2: add PPv23 RX FIFO flow control

[stefanc]

From: Stefan Chulski 

New FIFO flow control feature were added in PPv23.
PPv2 FIFO polled by HW and trigger pause frame if FIFO
fill level is below threshold.
FIFO HW flow control enabled with CM3 RXQ&BM flow
control with ethtool.
Current  FIFO thresholds is:
9KB for port with maximum speed 10Gb/s port
4KB for port with maximum speed 5Gb/s port
2KB for port with maximum speed 1Gb/s port

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h  | 16 +-
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 55 
 2 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 27aa593..3451618 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -770,6 +770,18 @@
 #define MVPP2_TX_FIFO_THRESHOLD(kb)\
((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
 
+/* RX FIFO threshold in 1KB granularity */
+#define MVPP23_PORT0_FIFO_TRSH (9 * 1024)
+#define MVPP23_PORT1_FIFO_TRSH (4 * 1024)
+#define MVPP23_PORT2_FIFO_TRSH (2 * 1024)
+
+/* RX Flow Control Registers */
+#define MVPP2_RX_FC_REG(port)  (0x150 + 4 * (port))
+#define MVPP2_RX_FC_EN BIT(24)
+#define MVPP2_RX_FC_TRSH_OFFS  16
+#define MVPP2_RX_FC_TRSH_MASK  (0xFF << MVPP2_RX_FC_TRSH_OFFS)
+#define MVPP2_RX_FC_TRSH_UNIT  256
+
 /* MSS Flow control */
 #define MSS_SRAM_SIZE  0x800
 #define MSS_FC_COM_REG 0
@@ -818,7 +830,6 @@
 #define MSS_THRESHOLD_STOP 768
 #define MSS_THRESHOLD_START1024
 
-
 /* RX buffer constants */
 #define MVPP2_SKB_SHINFO_SIZE \
SKB_DATA_ALIGN(sizeof(struct skb_shared_info))
@@ -1505,6 +1516,8 @@ struct mvpp2_bm_pool {
 
 void mvpp2_dbgfs_cleanup(struct mvpp2 *priv);
 
+void mvpp23_rx_fifo_fc_en(struct mvpp2 *priv, int port, bool en);
+
 #ifdef CONFIG_MVPP2_PTP
 int mvpp22_tai_probe(struct device *dev, struct mvpp2 *priv);
 void mvpp22_tai_tstamp(struct mvpp2_tai *tai, u32 tstamp,
@@ -1537,4 +1550,5 @@ static inline bool mvpp22_rx_hwtstamping(struct 
mvpp2_port *port)
 {
return IS_ENABLED(CONFIG_MVPP2_PTP) && port->rx_hwtstamp;
 }
+
 #endif
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 8827f52..757dfe0 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -5448,6 +5448,8 @@ static int mvpp2_ethtool_set_pause_param(struct 
net_device *dev,
mvpp2_bm_pool_update_fc(port, port->pool_long, true);
mvpp2_bm_pool_update_fc(port, port->pool_short, true);
}
+   if (port->priv->hw_version == MVPP23)
+   mvpp23_rx_fifo_fc_en(port->priv, port->id, true);
 
} else if (port->priv->global_tx_fc) {
port->tx_fc = false;
@@ -5459,6 +5461,8 @@ static int mvpp2_ethtool_set_pause_param(struct 
net_device *dev,
mvpp2_bm_pool_update_fc(port, port->pool_long, false);
mvpp2_bm_pool_update_fc(port, port->pool_short, false);
}
+   if (port->priv->hw_version == MVPP23)
+   mvpp23_rx_fifo_fc_en(port->priv, port->id, false);
}
 
if (!port->phylink)
@@ -7022,6 +7026,55 @@ static void mvpp22_rx_fifo_init(struct mvpp2 *priv)
mvpp2_write(priv, MVPP2_RX_FIFO_INIT_REG, 0x1);
 }
 
+/* Configure Rx FIFO Flow control thresholds */
+static void mvpp23_rx_fifo_fc_set_tresh(struct mvpp2 *priv)
+{
+   int port, val;
+
+   /* Port 0: maximum speed -10Gb/s port
+* required by spec RX FIFO threshold 9KB
+* Port 1: maximum speed -5Gb/s port
+* required by spec RX FIFO threshold 4KB
+* Port 2: maximum speed -1Gb/s port
+* required by spec RX FIFO threshold 2KB
+*/
+
+   /* Without loopback port */
+   for (port = 0; port < (MVPP2_MAX_PORTS - 1); port++) {
+   if (port == 0) {
+   val = (MVPP23_PORT0_FIFO_TRSH / MVPP2_RX_FC_TRSH_UNIT)
+   << MVPP2_RX_FC_TRSH_OFFS;
+   val &= MVPP2_RX_FC_TRSH_MASK;
+   mvpp2_write(priv, MVPP2_RX_FC_REG(port), val);
+   } else if (port == 1) {
+   val = (MVPP23_PORT1_FIFO_TRSH / MVPP2_RX_FC_TRSH_UNIT)
+   << MVPP2_RX_FC_TRSH_OFFS;
+   val &= MVPP2_RX_FC_TRSH_MASK;
+   mvpp2_write(priv, MVPP2_RX_FC_REG(port), val);
+   } else {
+   val = (MVPP23_PORT2_FIFO_TRSH / MVPP2_RX_FC_TRSH_UNIT)
+   << MVPP2_RX_FC_TRSH_OFFS;
+   val &= MVPP2_RX_FC_TRSH_MASK;
+   mvpp2_write(priv, MVPP2_RX_FC_REG(port), val);
+  

[PATCH RFC net-next 19/19] net: mvpp2: add TX FC firmware check

[stefanc]

From: Stefan Chulski 

Patch check that TX FC firmware is running in CM3.
If not, global TX FC would be disabled.

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h  |  1 +
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 39 
 2 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 3451618..1a65f2c 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -829,6 +829,7 @@
 
 #define MSS_THRESHOLD_STOP 768
 #define MSS_THRESHOLD_START1024
+#define MSS_FC_MAX_TIMEOUT 5000
 
 /* RX buffer constants */
 #define MVPP2_SKB_SHINFO_SIZE \
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 3607382..1690142 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -946,6 +946,34 @@ void mvpp2_bm_pool_update_fc(struct mvpp2_port *port,
spin_unlock_irqrestore(&port->priv->mss_spinlock, flags);
 }
 
+static int mvpp2_enable_global_fc(struct mvpp2 *priv)
+{
+   int val, timeout = 0;
+
+   /* Enable global flow control. In this stage global
+* flow control enabled, but still disabled per port.
+*/
+   val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
+   val |= FLOW_CONTROL_ENABLE_BIT;
+   mvpp2_cm3_write(priv, MSS_FC_COM_REG, val);
+
+   /* Check if Firmware running and disable FC if not*/
+   val |= FLOW_CONTROL_UPDATE_COMMAND_BIT;
+   mvpp2_cm3_write(priv, MSS_FC_COM_REG, val);
+
+   while (timeout < MSS_FC_MAX_TIMEOUT) {
+   val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
+
+   if (!(val & FLOW_CONTROL_UPDATE_COMMAND_BIT))
+   return 0;
+   usleep_range(10, 20);
+   timeout++;
+   }
+
+   priv->global_tx_fc = false;
+   return -EOPNOTSUPP;
+}
+
 /* Release buffer to BM */
 static inline void mvpp2_bm_pool_put(struct mvpp2_port *port, int pool,
 dma_addr_t buf_dma_addr,
@@ -7307,7 +7335,7 @@ static int mvpp2_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *base;
int i, shared;
-   int err, val;
+   int err;
 
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -7533,13 +7561,10 @@ static int mvpp2_probe(struct platform_device *pdev)
goto err_port_probe;
}
 
-   /* Enable global flow control. In this stage global
-* flow control enabled, but still disabled per port.
-*/
if (priv->global_tx_fc && priv->hw_version != MVPP21) {
-   val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
-   val |= FLOW_CONTROL_ENABLE_BIT;
-   mvpp2_cm3_write(priv, MSS_FC_COM_REG, val);
+   err = mvpp2_enable_global_fc(priv);
+   if (err)
+   dev_warn(&pdev->dev, "CM3 firmware not running, TX FC 
disabled\n");
}
 
mvpp2_dbgfs_init(priv, pdev->name);
-- 
1.9.1

[PATCH RFC net-next 18/19] net: mvpp2: add ring size validation before enabling FC

[stefanc]

From: Stefan Chulski 

This patch add ring size validation before enabling FC.
1. Flow control cannot be enabled if ring size is below start
threshold.
2. Flow control disabled if ring size set below start
threshold.

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 06e1000..3607382 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -5372,6 +5372,15 @@ static int mvpp2_ethtool_set_ringparam(struct net_device 
*dev,
if (err)
return err;
 
+   if (ring->rx_pending < MSS_THRESHOLD_START && port->tx_fc) {
+   netdev_warn(dev, "TX FC disabled. Ring size is less than %d\n",
+   MSS_THRESHOLD_START);
+   port->tx_fc = false;
+   mvpp2_rxq_disable_fc(port);
+   if (port->priv->hw_version == MVPP23)
+   mvpp23_rx_fifo_fc_en(port->priv, port->id, false);
+   }
+
if (!netif_running(dev)) {
port->rx_ring_size = ring->rx_pending;
port->tx_ring_size = ring->tx_pending;
@@ -5439,6 +5448,13 @@ static int mvpp2_ethtool_set_pause_param(struct 
net_device *dev,
 
if (pause->tx_pause && port->priv->global_tx_fc &&
bm_underrun_protect) {
+   if (port->rx_ring_size < MSS_THRESHOLD_START) {
+   netdev_err(dev, "TX FC cannot be supported.");
+   netdev_err(dev, "Ring size is less than %d\n",
+  MSS_THRESHOLD_START);
+   return -EINVAL;
+   }
+
port->tx_fc = true;
mvpp2_rxq_enable_fc(port);
if (port->priv->percpu_pools) {
-- 
1.9.1

[PATCH RFC net-next 17/19] net: mvpp2: set 802.3x GoP Flow Control mode

[stefanc]

From: Stefan Chulski 

This patch fix GMAC TX flow control autoneg.
Flow control autoneg wrongly were disabled with enabled TX
flow control.

Signed-off-by: Stefan Chulski 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 757dfe0..06e1000 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -6321,7 +6321,7 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, 
unsigned int mode,
old_ctrl4 = ctrl4 = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
 
ctrl0 &= ~MVPP2_GMAC_PORT_TYPE_MASK;
-   ctrl2 &= ~(MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK);
+   ctrl2 &= ~(MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK | 
MVPP2_GMAC_FLOW_CTRL_MASK);
 
/* Configure port type */
if (phy_interface_mode_is_8023z(state->interface)) {
-- 
1.9.1

Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD

[Oliver Graute]

On 09/01/21, Fabio Estevam wrote:
> Hi Oliver,
> 
> On Fri, Jan 8, 2021 at 7:24 PM Oliver Graute  wrote:
> >
> > On 19/12/20, Oliver Graute wrote:
> > > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
> > > to panel-simple.
> > >
> > > The panel spec from Variscite can be found at:
> > > https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf
> >
> > some clue what bus_format and bus_flags I have to use?
> >
> > [   42.505156] panel-simple panel-lcd: Specify missing bus_flags
> > [   42.511090] panel-simple panel-lcd: Specify missing bus_format
> > [   42.615131] mxsfb 21c8000.lcdif: Cannot connect bridge: -517
> 
> Does this patch work?
> https://pastebin.com/raw/diTMVsh8

the first two errors are gone. But I still get this:

[   42.387107] mxsfb 21c8000.lcdif: Cannot connect bridge: -517

The panel is still off perhaps I miss something else. 

Best Regards,

Oliver

Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E

[Chen-Yu Tsai]

Hi,

On Sun, Jan 10, 2021 at 10:45 PM Johan Jonker  wrote:
>
> Hi Chen-Yu,
>
> Some comments, have a look if it is useful...
>
> On 1/10/21 4:58 AM, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai 
> >
> > Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
> > As the official wiki page puts it, "E for Ethernets".
> >
> > It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
> > directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
> > a power-only USB type-C port, a 3.5mm headphone jack for audio output,
>
> > two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
> > and PoE header.
> >
> > The board comes in multiple configurations, differing in the amount of
> > onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
> > 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
> > can all share the same device tree.
> >
> > The USB 2.0 OTG controller is available on the 40-pin header. This is
> > not enabled in the device tree, since it is possible to use it in a
> > host-only configuration, or in OTG mode with an extra pin from the
> > header as the ID pin.
> >
> > The device tree is based on the one of the Rock64, with various parts
> > modified to match the ROCK Pi E, and some parts updated to newer styles,
> > such as the gmac2io node's mdio sub-node.
> >
> > Add a new device tree file for the new board.
> >
> > Signed-off-by: Chen-Yu Tsai 
> > ---
> >  arch/arm64/boot/dts/rockchip/Makefile |   1 +
> >  .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++
> >  2 files changed, 370 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
> > b/arch/arm64/boot/dts/rockchip/Makefile
> > index 622d320ddd13..62d3abc17a24 100644
> > --- a/arch/arm64/boot/dts/rockchip/Makefile
> > +++ b/arch/arm64/boot/dts/rockchip/Makefile
> > @@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
> > +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts 
> > b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> > new file mode 100644
> > index ..7818d2e8180c
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> > @@ -0,0 +1,369 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * (C) Copyright 2020 Chen-Yu Tsai 
> > + *
> > + * Based on ./rk3328-rock64.dts, which is
> > + *
> > + * Copyright (c) 2017 PINE64
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include "rk3328.dtsi"
> > +
> > +/ {
> > + model = "Radxa ROCK Pi E";
> > + compatible = "radxa,rockpi-e", "rockchip,rk3328";
> > +
> > + chosen {
> > + stdout-path = "serial2:150n8";
> > + };
> > +
> > + gmac_clkin: external-gmac-clock {
> > + compatible = "fixed-clock";
> > + clock-frequency = <12500>;
> > + clock-output-names = "gmac_clkin";
> > + #clock-cells = <0>;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-0 = <&led_pin>;
> > + pinctrl-names = "default";
> > +
> > + led-0 {
>
> > + /* schematic say green but the actual thing is blue */
>
> In rockpie-v1.2-20200427-sch.pdf this led is already called "LED_BLUE",
> so comment maybe not needed anymore?

Thanks. Did not notice there was a new revision.

> > + color = ;
> > + gpios = <&gpio3 RK_PA5 GPIO_ACTIVE_LOW>;
> > + linux,default-trigger = "heartbeat";
> > + };> +   };
> > +
> > + vcc_sd: sdmmc-regulator {
> > + compatible = "regulator-fixed";
> > + gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&sdmmc0m1_pin>;
>
> > + regulator-boot-on;
> > + regulator-name = "vcc_sd";
>
> regulator-name above other regulator properties

That is actually what I was used to, but some other rockchip dts files
have all the properties sorted alphabetically. So I stuck with what I
saw.

> regulator voltage missing
> make things as complete as possible
>
> from fixed-regulator.yaml:
>
> description:
>   Any property defined as part of the core regulator binding, defined in
>   regulator.yaml, can also be used. However a fixed voltage regulator is
>   expected to have the regulator-min-microvolt and regulator-max-microvolt
>   to be the same.

However this is

Re: [PATCH v5 09/15] lib/test_printf.c: Use helper function to unwind array of software_nodes

[Andy Shevchenko]

On Sun, Jan 10, 2021 at 1:16 PM Laurent Pinchart
 wrote:
> On Sat, Jan 09, 2021 at 11:07:33AM +0200, Andy Shevchenko wrote:
> > On Saturday, January 9, 2021, Laurent Pinchart wrote:
> > > Could you please let us know if you're fine with this patch getting
> > > merged in v5.12 through the linux-media tree ? The cover letter contains
> > > additional details (in a nutshell, this is a cross-tree series and we
> > > would like to avoid topic branches if possible).
> >
> > There is already a tag by Petr.
>
> I saw that, but looking at the corresponding e-mail, there was no clear
> acknowledgement that we could merge this patch through a different tree.

Fair point.

One question though, what so wrong with topic branches.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/2] mm: fix initialization of struct page for holes in memory layout

[Mike Rapoport]

On Wed, Jan 06, 2021 at 04:04:21PM -0500, Qian Cai wrote:
> On Wed, 2021-01-06 at 10:05 +0200, Mike Rapoport wrote:
> > I think we trigger PF_POISONED_CHECK() in PageSlab(), then fffe
> > is "accessed" from VM_BUG_ON_PAGE().
> > 
> > It seems to me that we are not initializing struct pages for holes at the 
> > node
> > boundaries because zones are already clamped to exclude those holes.
> > 
> > Can you please try to see if the patch below will produce any useful info:
> 
> [0.00] init_unavailable_range: spfn: 8c, epfn: 9b, zone: DMA, node: 0
> [0.00] init_unavailable_range: spfn: 1f7be, epfn: 1f9fe, zone: DMA32, 
> node: 0
> [0.00] init_unavailable_range: spfn: 28784, epfn: 288e4, zone: DMA32, 
> node: 0
> [0.00] init_unavailable_range: spfn: 298b9, epfn: 298bd, zone: DMA32, 
> node: 0
> [0.00] init_unavailable_range: spfn: 29923, epfn: 29931, zone: DMA32, 
> node: 0
> [0.00] init_unavailable_range: spfn: 29933, epfn: 29941, zone: DMA32, 
> node: 0
> [0.00] init_unavailable_range: spfn: 29945, epfn: 29946, zone: DMA32, 
> node: 0
> [0.00] init_unavailable_range: spfn: 29ff9, epfn: 2a823, zone: DMA32, 
> node: 0
> [0.00] init_unavailable_range: spfn: 33a23, epfn: 33a53, zone: DMA32, 
> node: 0
> [0.00] init_unavailable_range: spfn: 78000, epfn: 10, zone: 
> DMA32, node: 0
> ...
> [  572.222563][ T2302] kpagecount_read: pfn 47f380 is poisoned
...
> [  590.570032][ T2302] kpagecount_read: pfn 47 is poisoned
> [  604.268653][ T2302] kpagecount_read: pfn 87ff80 is poisoned
...
> [  604.611698][ T2302] kpagecount_read: pfn 87ffbc is poisoned
> [  617.484205][ T2302] kpagecount_read: pfn c7ff80 is poisoned
...
> [  618.212344][ T2302] kpagecount_read: pfn c7 is poisoned
> [  633.134228][ T2302] kpagecount_read: pfn 107ff80 is poisoned
...
> [  633.874087][ T2302] kpagecount_read: pfn 107 is poisoned
> [  647.686412][ T2302] kpagecount_read: pfn 147ff80 is poisoned
...
> [  648.425548][ T2302] kpagecount_read: pfn 147 is poisoned
> [  663.692630][ T2302] kpagecount_read: pfn 187ff80 is poisoned
...
> [  664.432671][ T2302] kpagecount_read: pfn 187 is poisoned
> [  675.462757][ T2302] kpagecount_read: pfn 1c7ff80 is poisoned
...
> [  676.202548][ T2302] kpagecount_read: pfn 1c7 is poisoned
> [  687.121605][ T2302] kpagecount_read: pfn 207ff80 is poisoned
...
> [  687.860981][ T2302] kpagecount_read: pfn 207 is poisoned

The e820 map has a hole near the end of each node and these holes are not
initialized with init_unavailable_range() after it was interleaved with
memmap initialization because such holes are not accounted by
zone->spanned_pages.

Yet, I'm still cannot really understand how this never triggered 

VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page);

before v5.7 as all the struct pages for these holes would have zone=0 and
node=0 ... 

@Qian, can you please boot your system with memblock=debug and share the
logs?

-- 
Sincerely yours,
Mike.

Re: dmaengine : xilinx_dma two issues

[Lars-Peter Clausen]

On 1/10/21 4:16 PM, Paul Thomas wrote:

On Fri, Jan 8, 2021 at 1:36 PM Radhey Shyam Pandey  wrote:

-Original Message-
From: Paul Thomas 
Sent: Friday, January 8, 2021 9:27 PM
To: Radhey Shyam Pandey 
Cc: Dan Williams ; Vinod Koul
; Michal Simek ; Matthew Murrian
; Romain Perier
; Krzysztof Kozlowski ; Marc
Ferland ; Sebastian von Ohr
; dmaeng...@vger.kernel.org; Linux ARM ; linux-kernel ; dave.ji...@intel.com; Shravya Kumbham
; git 
Subject: Re: dmaengine : xilinx_dma two issues

Hi All,

On Fri, Jan 8, 2021 at 2:13 AM Radhey Shyam Pandey 
wrote:

-Original Message-
From: Radhey Shyam Pandey
Sent: Monday, January 4, 2021 10:50 AM
To: Paul Thomas ; Dan Williams
; Vinod Koul ; Michal
Simek ; Matthew Murrian
; Romain Perier
; Krzysztof Kozlowski ;
Marc Ferland ; Sebastian von Ohr
; dmaeng...@vger.kernel.org; Linux ARM ; linux-kernel ; Shravya Kumbham ; git

Subject: RE: dmaengine : xilinx_dma two issues


-Original Message-
From: Paul Thomas 
Sent: Monday, December 28, 2020 10:14 AM
To: Dan Williams ; Vinod Koul
; Michal Simek ; Radhey
Shyam Pandey ; Matthew Murrian
; Romain Perier

;

Krzysztof Kozlowski ; Marc Ferland
; Sebastian von Ohr ;
dmaeng...@vger.kernel.org; Linux ARM ; linux-kernel 
Subject: dmaengine : xilinx_dma two issues

Hello,

I'm trying to get the 5.10 kernel up and running for our system,
and I'm running into a couple of issues with xilinx_dma.

+ (Xilinx mailing list)

Thanks for bringing the issues to our notice. Replies inline.


First, commit 14ccf0aab46e 'dmaengine: xilinx_dma: In dma channel
probe fix node order dependency' breaks our usage. Before this
commit a

call to:

dma_request_chan(&indio_dev->dev, "axi_dma_0"); returns fine, but
after that commit it returns -19. The reason for this seems to be
that the only channel that is setup is channel 1 (chan->id is 1 in

xilinx_dma_chan_probe()).

However in
of_dma_xilinx_xlate() chan_id is gets set to 0 (int chan_id =
dma_spec-

args[0];), which causes the:

!xdev->chan[chan_id]
test to fail in of_dma_xilinx_xlate()

What is the channel number passed in dmaclient DT?

Is this a question for me?

Yes, please also share the dmaclient DT client node. Need to see
channel number passed to dmas property. Something like below-

dmas = <& axi_dma_0 1>
dma-names = "axi_dma_0"

OK, I think I need to revisit this and clean it up some. Currently In
the driver (a custom iio adc driver) it is hard coded:
dma_request_chan(&indio_dev->dev, "axi_dma_0");

However, the DT also has the entries (currently unused by the driver):
 dmas = <&axi_dma_0 0>;
 dma-names = "axi_dma_0";

I'll go back and clean up our driver to do something like adi-axi-adc.c does:

 if (!device_property_present(dev, "dmas"))
 return 0;

 if (device_property_read_string(dev, "dma-names", &dma_name))
 dma_name = "axi_dma_0";

Should the dmas node get used by the driver? I see the second argument
is: '0' for write/tx and '1' for read/rx channel. So I should be
setting this to 1 like this?
 dmas = <&axi_dma_0 1>;
 dma-names = "axi_dma_0";

But where does that field get used?


This got broken in "dmaengine: xilinx_dma: In dma channel probe fix node 
order dependency" 
. 
Before if there was only one channel that channel was always at index 0. 
Regardless of whether the channel was RX or TX. But after that change 
the RX channel is always at offset 1, regardless of whether the DMA has 
one or two channels. This is a breakage in ABI.


If you have the choice I'd recommend to not use the Xilinx DMA, it gets 
broken pretty much every other release.


- Lars

Re: [PATCH 0/8] FPGA DFL Changes for 5.12

[Tom Rix]

On 1/7/21 8:09 AM, Tom Rix wrote:
> On 1/6/21 8:37 PM, Moritz Fischer wrote:
>> This is a resend of the previous (unfortunately late) patchset of
>> changes for FPGA DFL.
> Is there something I can do to help ?
>
> I am paid to look after linux-fpga, so i have plenty of time.
>
> Some ideas of what i am doing now privately i can do publicly.
>
> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a 
> pullable state.
>
> 2. an in-flight dev branch for the outstanding patches 

I have setup these branches based on Greg's char-misc-next

fpga-next, which is char-misc-next base for fpga-testing

fpga-testing, all the in-flight patches that would apply with automatic merge 
conflict resolution

These are respectively

https://github.com/trixirt/linux-fpga/tree/fpga-next

https://github.com/trixirt/linux-fpga/tree/fpga-testing


There are two trivial changes, that could go to 5.12 now.

fpga: dfl: fme: Constify static attribute_group structs

fpga: Use DEFINE_SPINLOCK() for spinlock

respectively

https://lore.kernel.org/linux-fpga/20210108235414.48017-1-rikard.falkeb...@gmail.com/

https://lore.kernel.org/linux-fpga/20201228135135.28788-1-zhengyongj...@huawei.com/


There are a couple of patchsets that conflict

https://lore.kernel.org/linux-fpga/20210105230855.15019-7-russell.h.wei...@intel.com/

https://lore.kernel.org/linux-fpga/20201203171548.1538178-3-matthew.gerl...@linux.intel.com/

Which I will follow up on.


And the xilinx patchset

https://lore.kernel.org/linux-fpga/20201217075046.28553-1-son...@xilinx.com/

Which is being split/worked on offline.


If I have missed any patchset, poke me.

Tom


>
> Tom
>
>

Re: EDAC driver for ARMv8 RAS extension is being worked on

[Manivannan Sadhasivam]

On Sun, Jan 10, 2021 at 04:29:43PM +0100, Borislav Petkov wrote:
> On Sun, Jan 10, 2021 at 08:41:49PM +0530, Manivannan Sadhasivam wrote:
> > I've collected the feedback on those submissions and came up with the idea 
> > of
> > a single "armv8_ras_edac" driver which will work for both Devicetree and 
> > ACPI
> 
> "ras" and "edac" both is too much. Just call it armv8_edac or arm64_edac or 
> so.
> 

Okay, sure.

Thanks,
Mani

> -- 
> Regards/Gruss,
> Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

Re: Old platforms: bring out your dead

[Neil Armstrong]

Hi Arnd,

Le 08/01/2021 à 23:55, Arnd Bergmann a écrit :
> After v5.10 was officially declared an LTS kernel, I had a look around
> the Arm platforms that look like they have not seen any patches from
> their maintainers or users that are actually running the hardware for
> at least five years (2015 or earlier). I made some statistics and lists
> for my lwn.net article last year [1], so I'd thought I'd share a summary
> here for discussion about what we should remove. As I found three
> years ago when I removed several CPU architectures, it makes sense
> to do this in bulk, to simplify a scripted search for device drivers, header
> files and Kconfig options that become unused in the process.

...

> * oxnas -- added in 2016, but already old then, few changes later

There is still active users in the openwrt community, so it would be goods to 
keep it for now.
And we have an OX820 board in KerneCI so it's still maintained & boot-tested.

Neil

Re: [PATCH v5 09/15] lib/test_printf.c: Use helper function to unwind array of software_nodes

[Laurent Pinchart]

On Sun, Jan 10, 2021 at 05:38:03PM +0200, Andy Shevchenko wrote:
> On Sun, Jan 10, 2021 at 1:16 PM Laurent Pinchart wrote:
> > On Sat, Jan 09, 2021 at 11:07:33AM +0200, Andy Shevchenko wrote:
> > > On Saturday, January 9, 2021, Laurent Pinchart wrote:
> > > > Could you please let us know if you're fine with this patch getting
> > > > merged in v5.12 through the linux-media tree ? The cover letter contains
> > > > additional details (in a nutshell, this is a cross-tree series and we
> > > > would like to avoid topic branches if possible).
> > >
> > > There is already a tag by Petr.
> >
> > I saw that, but looking at the corresponding e-mail, there was no clear
> > acknowledgement that we could merge this patch through a different tree.
> 
> Fair point.
> 
> One question though, what so wrong with topic branches.

They're not wrong, they just add more complexity as all maintainers
involved would need to create a topic branch based on v5.11-rc1 and
merge it in their respective tree. It's certainly doable, but when
there's no risk of conflict, merging the whole series through a single
tree is just easier.

-- 
Regards,

Laurent Pinchart

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sun, Jan 10, 2021 at 4:51 PM Neil Armstrong  wrote:
>
> Hi Arnd,
>
> Le 08/01/2021 à 23:55, Arnd Bergmann a écrit :
> > After v5.10 was officially declared an LTS kernel, I had a look around
> > the Arm platforms that look like they have not seen any patches from
> > their maintainers or users that are actually running the hardware for
> > at least five years (2015 or earlier). I made some statistics and lists
> > for my lwn.net article last year [1], so I'd thought I'd share a summary
> > here for discussion about what we should remove. As I found three
> > years ago when I removed several CPU architectures, it makes sense
> > to do this in bulk, to simplify a scripted search for device drivers, header
> > files and Kconfig options that become unused in the process.
>
> ...
>
> > * oxnas -- added in 2016, but already old then, few changes later
>
> There is still active users in the openwrt community, so it would be goods to 
> keep it for now.
> And we have an OX820 board in KerneCI so it's still maintained & boot-tested.

Ok, taken off the list now.

Thanks for the clarification,

  Arnd

[PATCH] arm64: dts: rockchip: more user friendly name of sound nodes

[Katsuhiro Suzuki]

This patch changes device name to more user friendly name of
Analog and SPDIF sound nodes for rk3399-rockpro64.

Signed-off-by: Katsuhiro Suzuki 
---
 arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
index 58097245994a..5ab0b9edfc88 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
@@ -72,13 +72,13 @@ sdio_pwrseq: sdio-pwrseq {
 
sound {
compatible = "audio-graph-card";
-   label = "rockchip,rk3399";
+   label = "Analog";
dais = <&i2s1_p0>;
};
 
sound-dit {
compatible = "audio-graph-card";
-   label = "rockchip,rk3399";
+   label = "SPDIF";
dais = <&spdif_p0>;
};
 
-- 
2.29.2

Re: [PATCH v8 2/3] ARM: dts: Add support for i.MX6 UltraLite DART Variscite Customboard

[Oliver Graute]

On 09/01/21, Fabio Estevam wrote:
> On Fri, Jan 8, 2021 at 7:23 PM Oliver Graute  wrote:
> 
> > +   panel1: panel-lcd {
> > +   compatible = "sgd,gktw70sdad1sd";
> > +
> > +   backlight = <&backlight_lcd>;
> > +   power-supply = <®_touch_3v3>;
> > +   label = "gktw70sdad1sd";
> > +
> > +   display-timing {
> 
> If you pass the compatible, then you don't need to add the
> display-timing in the device tree.

thx I`ll drop it

Best Regards,

Oliver

Re: [PATCH v3 3/3] dt-bindings: arm: fsl: Add Variscite i.MX6UL compatibles

[Oliver Graute]

On 09/01/21, Fabio Estevam wrote:
> On Fri, Jan 8, 2021 at 7:23 PM Oliver Graute  wrote:
> 
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
> > b/Documentation/devicetree/bindings/arm/fsl.yaml
> > index 05906e2..5f74d78 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -240,6 +240,7 @@ properties:
> >- technexion,imx6ul-pico-dwarf   # TechNexion i.MX6UL 
> > Pico-Dwarf
> >- technexion,imx6ul-pico-hobbit  # TechNexion i.MX6UL 
> > Pico-Hobbit
> >- technexion,imx6ul-pico-pi  # TechNexion i.MX6UL Pico-Pi
> > +  - variscite,imx6ul-var-6ulcustomboard # i.MX UltraLite 
> > Carrier-board
> 
> You missed to add a "6" in the description: i.MX6 UltraLite Carrier-board

I will add it.

thx

Best regards,

Oliver

Re: [PATCH 2/2] scsi: ufs: Protect PM ops and err_handler from user access through sysfs

[Bean Huo]

On Sat, 2021-01-09 at 12:51 +0800, Can Guo wrote:
> On 2021-01-09 12:45, Can Guo wrote:
> > On 2021-01-08 19:29, Bean Huo wrote:
> > > On Wed, 2021-01-06 at 09:20 +0800, Can Guo wrote:
> > > > Hi Bean,
> > > > 
> > > > On 2021-01-06 02:38, Bean Huo wrote:
> > > > > On Tue, 2021-01-05 at 09:07 +0800, Can Guo wrote:
> > > > > > On 2021-01-05 04:05, Bean Huo wrote:
> > > > > > > On Sat, 2021-01-02 at 05:59 -0800, Can Guo wrote:
> > > > > > > > + * @shutting_down: flag to check if shutdown has been
> > > > > > > > invoked
> > > > > > > 
> > > > > > > I am not much sure if this flag is need, since once PM
> > > > > > > going in
> > > > > > > shutdown path, what will be returnded by
> > > > > > > pm_runtime_get_sync()?
> > > > > > > 
> > > > > > > If pm_runtime_get_sync() will fail, just check its
> > > > > > > return.
> > > > > > > 
> > > > > > 
> > > > > > That depends. During/after shutdown, for UFS's case only,
> > > > > > pm_runtime_get_sync(hba->dev) will most likely return 0,
> > > > > > because it is already RUNTIME_ACTIVE, pm_runtime_get_sync()
> > > > > > will directly return 0... meaning you cannot count on it.
> > > > > > 
> > > > > > Check Stanley's change -
> > > > > > https://lore.kernel.org/patchwork/patch/1341389/
> > > > > > 
> > > > > > Can Guo.
> > > > > 
> > > > > Can,
> > > > > 
> > > > > Thanks for pointing out that.
> > > > > 
> > > > > Based on my understanding, that patch is redundent. maybe I
> > > > > misundestood Linux shutdown sequence.
> > > > 
> > > > Sorry, do you mean Stanley's change is redundant?
> > > 
> > > yes.
> > > 
> > 
> > No, it is definitely needed. As Stanley replied you in another
> > thread, it is not protecting I/Os from user layer, but from
> > other subsystems during shutdown.
> > 
> > > > 
> > > > > 
> > > > > I checked the shutdown flow:
> > > > > 
> > > > > 1. Set the "system_state" variable
> > > > > 2. Disable usermod to ensure that no user from userspace can
> > > > > start
> > > > > a
> > > > > request
> > > > 
> > > > I hope it is like what you interpreted, but step #2 only stops
> > > > UMH(#265)
> > > > but not all user space activities. Whereas, UMH is for kernel
> > > > space
> > > > calling
> > > > user space.
> > > 
> > > 
> > > Can,
> > > 
> > > I did further study and homework on the Linux shutdown in the
> > > last few
> > > days. Yes, you are right, usermodehelper_disable() is to prevent
> > > executing the process from the kernel space.
> > > 
> > > But I didn't reproduce this "maybe" race issue while shutdown. no
> > > matter how I torment my system, once Linux shutdown/halt/reboot 
> > > starts,
> > > nobody can access the sysfs node. I create 10 processes in the
> > > user
> > > space and constantly access UFS sysfs node, also, fio is running
> > > in 
> > > the
> > > background for the normal data read/write. there is a shutdown
> > > thread
> > > that will randomly trigger shutdown/halt/reboot. but no race
> > > issue
> > > appears.
> > > 
> > > I don't know if this is a hypothetical issue(the race between
> > > shutdown
> > > flow and sysfs node access), it may not really exist in the Linux
> > > envriroment. everytime, the shutdonw flow will be:
> > > 
> > > e10_sync_handler()->e10_svc()->do_e10_svc()->__do_sys_reboot()-
> > > > kernel_poweroff/kernel_halt()->device_shutdown()-
> > > > >platform_shutdown()-
> > > > ufshcd_platform_shutdown()->ufshcd_shutdown().
> > > 
> > > I think before going into the kernel shutdown, the userspace
> > > cannot
> > > issue new requests anymore. otherwise, this would be a big issue.
> > > 
> > > pm_runtime_get_sync() will return 0 or failure while shutdown?
> > > the
> > > answer is not important now, maybe as you said, it is always 0.
> > > But in
> > > my testing, it didn't get there the system has been shutdown.
> > > Which
> > > means once shutdonw starts, sysfs node access path cannot reach
> > > pm_runtime_get_sync(). (note, I don't know if sysfs node access
> > > thread
> > > has been disabled or not)
> > > 
> > > 
> > > Responsibly say, I didn't reproduce this issue on my system
> > > (ubuntu),
> > > maybe you are using Android. I am not an expert on this topic, if
> > > you
> > > have the best idea on how to reproduce this issue. please please
> > > let 
> > > me
> > > try. appreciate it!
> > > 
> > 
> > When you do a reboot/shutdown/poweroff, how your system behaves
> > highly
> > depends on how the reboot cmd is implemented in C code under
> > /sbin/.
> > 
> > On Ubuntu, reboot looks like:
> > $ reboot --help
> > reboot [OPTIONS...] [ARG]
> > 
> > Reboot the system.
> > 
> >   --help  Show this help
> >   --halt  Halt the machine
> >-p --poweroff  Switch off the machine
> >   --rebootReboot the machine
> >-f --force Force immediate halt/power-off/reboot
> >-w --wtmp-only Don't halt/power-off/reboot, just write wtmp
> > record
> >-d --no-wtmp   Don't write wtmp record
> >   --no-wall   Don't send wall message before halt/power-
> > off/reboo

[PATCH] docs: filesystems: vfs: Correct the struct name

[winndows]

From: Liao Pingfang 

The struct name should be file_system_type instead of
file_system_operations.

Signed-off-by: Liao Pingfang 
---
 Documentation/filesystems/vfs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/filesystems/vfs.rst 
b/Documentation/filesystems/vfs.rst
index ca52c82..18d69a4 100644
--- a/Documentation/filesystems/vfs.rst
+++ b/Documentation/filesystems/vfs.rst
@@ -112,7 +112,7 @@ members are defined:
 
 .. code-block:: c
 
-   struct file_system_operations {
+   struct file_system_type {
const char *name;
int fs_flags;
struct dentry *(*mount) (struct file_system_type *, int,
-- 
1.8.3.1

Re: [PATCH 2/2] scsi: ufs: Protect PM ops and err_handler from user access through sysfs

[Bean Huo]

On Sat, 2021-01-02 at 05:59 -0800, Can Guo wrote:
> + * @shutting_down: flag to check if shutdown has been invoked
> + * @host_sem: semaphore used to serialize concurrent contexts
>   * @eh_wq: Workqueue that eh_work works on
>   * @eh_work: Worker to handle UFS errors that require s/w attention
>   * @eeh_work: Worker to handle exception events
> @@ -751,7 +753,8 @@ struct ufs_hba {
> u32 intr_mask;
> u16 ee_ctrl_mask;
> bool is_powered;
> -   struct semaphore eh_sem;
> +   bool shutting_down;
> +   struct semaphore host_sem;
>  
> /* Work Queues */
> struct workqueue_struct *eh_wq;
> @@ -875,6 +878,11 @@ static inline bool ufshcd_is_wb_allowed(struct
> ufs_hba *hba)
> return hba->caps & UFSHCD_CAP_WB_EN;
>  }
>  
> +static inline bool ufshcd_is_sysfs_allowed(struct ufs_hba *hba)
> +{
> +   return !hba->shutting_down;
> +}
> +


Can,

Instead adding new shutting_down flag, can we use availible variable
system_state?

Thanks,
Bean

Re: [RFC v2] nvfs: a filesystem for persistent memory

[Al Viro]

On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote:
> Hi
> 
> I announce a new version of NVFS - a filesystem for persistent memory.
>   http://people.redhat.com/~mpatocka/nvfs/
Utilities, AFAICS

>   git://leontynka.twibright.com/nvfs.git
Seems to hang on git pull at the moment...  Do you have it anywhere else?

> I found out that on NVFS, reading a file with the read method has 10% 
> better performance than the read_iter method. The benchmark just reads the 
> same 4k page over and over again - and the cost of creating and parsing 
> the kiocb and iov_iter structures is just that high.

Apples and oranges...  What happens if you take

ssize_t read_iter_locked(struct file *file, struct iov_iter *to, loff_t *ppos)
{
struct inode *inode = file_inode(file);
struct nvfs_memory_inode *nmi = i_to_nmi(inode);
struct nvfs_superblock *nvs = inode->i_sb->s_fs_info;
ssize_t total = 0;
loff_t pos = *ppos;
int r;
int shift = nvs->log2_page_size;
size_t i_size;

i_size = inode->i_size;
if (pos >= i_size)
return 0;
iov_iter_truncate(to, i_size - pos);

while (iov_iter_count(to)) {
void *blk, *ptr;
size_t page_mask = (1UL << shift) - 1;
unsigned page_offset = pos & page_mask;
unsigned prealloc = (iov_iter_count(to) + page_mask) >> shift;
unsigned size;

blk = nvfs_bmap(nmi, pos >> shift, &prealloc, NULL, NULL, NULL);
if (unlikely(IS_ERR(blk))) {
r = PTR_ERR(blk);
goto ret_r;
}
size = ((size_t)prealloc << shift) - page_offset;
ptr = blk + page_offset;
if (unlikely(!blk)) {
size = min(size, (unsigned)PAGE_SIZE);
ptr = empty_zero_page;
}
size = copy_to_iter(to, ptr, size);
if (unlikely(!size)) {
r = -EFAULT;
goto ret_r;
}

pos += size;
total += size;
} while (iov_iter_count(to));

r = 0;

ret_r:
*ppos = pos;

if (file)
file_accessed(file);

return total ? total : r;
}

and use that instead of your nvfs_rw_iter_locked() in your
->read_iter() for DAX read case?  Then the same with
s/copy_to_iter/_copy_to_iter/, to see how much of that is
"hardening" overhead.

Incidentally, what's the point of sharing nvfs_rw_iter() for
read and write cases?  They have practically no overlap -
count the lines common for wr and !wr cases.  And if you
do the same in nvfs_rw_iter_locked(), you'll see that the
shared parts _there_ are bloody pointless on the read side.
Not that it had been more useful on the write side, really,
but that's another story (nvfs_write_pages() handling of
copyin is... interesting).  Let's figure out what's going
on with the read overhead first...

lib/iov_iter.c primitives certainly could use massage for
better code generation, but let's find out how much of the
PITA is due to those and how much comes from you fighing
the damn thing instead of using it sanely...

Re: [PATCH v1] drm/panel: simple: add SGD GKTW70SDAD1SD

[Fabio Estevam]

Hi Oliver,

On Sun, Jan 10, 2021 at 12:35 PM Oliver Graute  wrote:

> the first two errors are gone. But I still get this:
>
> [   42.387107] mxsfb 21c8000.lcdif: Cannot connect bridge: -517
>
> The panel is still off perhaps I miss something else.

Some suggestions:

- Take a look at arch/arm/boot/dts/imx6ul-14x14-evk.dtsi as a
reference as it has display functional
- Use imx_v6_v7_defconfig to make sure all the required drivers are selected
- If it still does not work, share the dts and schematics

Re: [PATCH 4/4] Input: omap4-keypad - simplify probe with devm

[Tony Lindgren]

* Dmitry Torokhov  [210110 06:31]:
> I do not quite like that we need to keep this in remove(). I had the
> patch below for quite some time, could you please try it?

Yes seems to work nice :)

> Input: omap4-keypad - switch to use managed resources
> 
> From: Dmitry Torokhov 
> 
> Now that input core supports devres-managed input devices we can clean
> up this driver a bit.
> 
> Signed-off-by: Dmitry Torokhov 

Tested-by: Tony Lindgren 


> ---
>  drivers/input/keyboard/omap4-keypad.c |  139 
> +
>  1 file changed, 55 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/input/keyboard/omap4-keypad.c 
> b/drivers/input/keyboard/omap4-keypad.c
> index b17ac2a295b9..d36774a55a10 100644
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -252,8 +252,14 @@ static int omap4_keypad_check_revision(struct device 
> *dev,
>   return 0;
>  }
>  
> +static void omap4_disable_pm(void *d)
> +{
> + pm_runtime_disable(d);
> +}
> +
>  static int omap4_keypad_probe(struct platform_device *pdev)
>  {
> + struct device *dev = &pdev->dev;
>   struct omap4_keypad *keypad_data;
>   struct input_dev *input_dev;
>   struct resource *res;
> @@ -271,33 +277,30 @@ static int omap4_keypad_probe(struct platform_device 
> *pdev)
>   if (irq < 0)
>   return irq;
>  
> - keypad_data = kzalloc(sizeof(struct omap4_keypad), GFP_KERNEL);
> + keypad_data = devm_kzalloc(dev, sizeof(struct omap4_keypad),
> +GFP_KERNEL);
>   if (!keypad_data) {
> - dev_err(&pdev->dev, "keypad_data memory allocation failed\n");
> + dev_err(dev, "keypad_data memory allocation failed\n");
>   return -ENOMEM;
>   }
>  
>   keypad_data->irq = irq;
>  
> - error = omap4_keypad_parse_dt(&pdev->dev, keypad_data);
> + error = omap4_keypad_parse_dt(dev, keypad_data);
>   if (error)
> - goto err_free_keypad;
> + return error;
>  
> - res = request_mem_region(res->start, resource_size(res), pdev->name);
> - if (!res) {
> - dev_err(&pdev->dev, "can't request mem region\n");
> - error = -EBUSY;
> - goto err_free_keypad;
> - }
> + keypad_data->base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(keypad_data->base))
> + return PTR_ERR(keypad_data->base);
>  
> - keypad_data->base = ioremap(res->start, resource_size(res));
> - if (!keypad_data->base) {
> - dev_err(&pdev->dev, "can't ioremap mem resource\n");
> - error = -ENOMEM;
> - goto err_release_mem;
> - }
> + pm_runtime_enable(dev);
>  
> - pm_runtime_enable(&pdev->dev);
> + error = devm_add_action_or_reset(dev, omap4_disable_pm, dev);
> + if (error) {
> + dev_err(dev, "unable to register cleanup action\n");
> + return error;
> + }
>  
>   /*
>* Enable clocks for the keypad module so that we can read
> @@ -307,27 +310,26 @@ static int omap4_keypad_probe(struct platform_device 
> *pdev)
>   if (error) {
>   dev_err(&pdev->dev, "pm_runtime_get_sync() failed\n");
>   pm_runtime_put_noidle(&pdev->dev);
> - } else {
> - error = omap4_keypad_check_revision(&pdev->dev,
> - keypad_data);
> - if (!error) {
> - /* Ensure device does not raise interrupts */
> - omap4_keypad_stop(keypad_data);
> - }
> - pm_runtime_put_sync(&pdev->dev);
> + return error;
> + }
> +
> + error = omap4_keypad_check_revision(&pdev->dev,
> + keypad_data);
> + if (!error) {
> + /* Ensure device does not raise interrupts */
> + omap4_keypad_stop(keypad_data);
>   }
> +
> + pm_runtime_put_sync(&pdev->dev);
>   if (error)
> - goto err_pm_disable;
> + return error;
>  
>   /* input device allocation */
> - keypad_data->input = input_dev = input_allocate_device();
> - if (!input_dev) {
> - error = -ENOMEM;
> - goto err_pm_disable;
> - }
> + keypad_data->input = input_dev = devm_input_allocate_device(dev);
> + if (!input_dev)
> + return -ENOMEM;
>  
>   input_dev->name = pdev->name;
> - input_dev->dev.parent = &pdev->dev;
>   input_dev->id.bustype = BUS_HOST;
>   input_dev->id.vendor = 0x0001;
>   input_dev->id.product = 0x0001;
> @@ -344,84 +346,53 @@ static int omap4_keypad_probe(struct platform_device 
> *pdev)
>  
>   keypad_data->row_shift = get_count_order(keypad_data->cols);
>   max_keys = keypad_data->rows << keypad_data->row_shift;
> - keypad_data->keymap = kcalloc(max_keys,
> -   sizeof(keypad_data->keymap[0]),
> -   

Re: Old platforms: bring out your dead

[Andrew Lunn]

> For this platform, I'm most interested in whether there are still users
> that rely on board files instead of DT. AFAIU we could just fold
> the DT variant into arch-mvebu like kirkwood was, right?

Hi Arnd

I'm actually booting my device using a board file. But Debian
flash-kernel is pretty unhappy about that. The bootloader i have on
this machine is too old to passed DT blob. I will test appended DT
blob still works. And see if we have any board files which also don't
have a DT representation.

 Andrew

Re: [PATCH 3/4] Input: omap4-keypad - use PM runtime to check keys for errata

[Tony Lindgren]

* Dmitry Torokhov  [210110 06:34]:
> Hi Tony,
> 
> On Wed, Jan 06, 2021 at 02:58:21PM +0200, Tony Lindgren wrote:
> > @@ -301,6 +348,7 @@ static int omap4_keypad_probe(struct platform_device 
> > *pdev)
> > }
> >  
> > keypad_data->irq = irq;
> > +   mutex_init(&keypad_data->lock);
> >  
> > error = omap4_keypad_parse_dt(&pdev->dev, keypad_data);
> > if (error)
> > @@ -320,6 +368,8 @@ static int omap4_keypad_probe(struct platform_device 
> > *pdev)
> > goto err_release_mem;
> > }
> >  
> > +   pm_runtime_use_autosuspend(&pdev->dev);
> > +   pm_runtime_set_autosuspend_delay(&pdev->dev, OMAP4_KEYPAD_AUTOIDLE_MS);
> 
> This, and corresponding changes in open() and close() seem like a
> separate improvement. Do you mind splitting them into a separate patch,
> and have the missing key release fix go on top of it?

Sure will do.

Thanks,

Tony

Re: [RFC v2] nvfs: a filesystem for persistent memory

[Al Viro]

On Sun, Jan 10, 2021 at 04:20:08PM +, Al Viro wrote:
> On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote:
> > Hi
> > 
> > I announce a new version of NVFS - a filesystem for persistent memory.
> > http://people.redhat.com/~mpatocka/nvfs/
> Utilities, AFAICS
> 
> > git://leontynka.twibright.com/nvfs.git
> Seems to hang on git pull at the moment...  Do you have it anywhere else?

D'oh...  In case it's not obvious from the rest of reply, I have managed to
grab it - and forgot to remove the question before sending the comments.
My apologies for the confusion; I plead the lack of coffee...

[PATCH v2] arm64: dts: imx8mq: Add clock parents for mipi dphy

[Guido Günther]

This makes sure the clock tree setup for the dphy is not dependent on
other components.

Without this change bringing up the display can fail like

  kernel: phy phy-30a00300.dphy.2: Invalid CM/CN/CO values: 165/217/1
  kernel: phy phy-30a00300.dphy.2: for hs_clk/ref_clk=451656000/59398 ~ 
165/217

if LCDIF doesn't set up that part of the clock tree first. This was
noticed when testing the Librem 5 devkit with defconfig. It doesn't
happen when modules are built in.

Signed-off-by: Guido Günther 

---
Changes from v1:
- as per review comment from Shawn Guo
  https://lore.kernel.org/linux-arm-kernel/20210110124629.GO28365@dragon/
  Set clock rate for IMX8MQ_VIDEO_PLL1 too. Otherwise we end up with
  a close but not exact clock rate.

 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index a841a023e8e0..50ae17f65a51 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1016,9 +1016,14 @@ dphy: dphy@30a00300 {
reg = <0x30a00300 0x100>;
clocks = <&clk IMX8MQ_CLK_DSI_PHY_REF>;
clock-names = "phy_ref";
-   assigned-clocks = <&clk IMX8MQ_CLK_DSI_PHY_REF>;
-   assigned-clock-parents = <&clk 
IMX8MQ_VIDEO_PLL1_OUT>;
-   assigned-clock-rates = <2400>;
+   assigned-clocks = <&clk 
IMX8MQ_VIDEO_PLL1_REF_SEL>,
+ <&clk 
IMX8MQ_VIDEO_PLL1_BYPASS>,
+ <&clk IMX8MQ_CLK_DSI_PHY_REF>,
+ <&clk IMX8MQ_VIDEO_PLL1>;
+   assigned-clock-parents = <&clk IMX8MQ_CLK_25M>,
+ <&clk IMX8MQ_VIDEO_PLL1>,
+ <&clk IMX8MQ_VIDEO_PLL1_OUT>;
+   assigned-clock-rates = <0>, <0>, <2400>, 
<59400>;
#phy-cells = <0>;
power-domains = <&pgc_mipi>;
status = "disabled";
-- 
2.29.2

Re: [PATCH 1/2] clk: imx: enable the earlycon uart clocks by parsing from dt

[Adam Ford]

On Mon, Jan 4, 2021 at 1:12 AM Sascha Hauer  wrote:
>
> Hi Adam,
>
> On Tue, Dec 29, 2020 at 08:51:28AM -0600, Adam Ford wrote:
> > Remove the earlycon uart clocks that are hard cord in platforms
> > clock driver, instead of parsing the earlycon uart port from dt
>
> "instead parse the earlycon uart..."
>
> Otherwise it's confusing what you mean here.
>
> > and enable these clocks from clock property in dt node.
> >
> > Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate 
> > protection")
> > Signed-off-by: Fugang Duan 
> > Signed-off-by: Adam Ford 
> > ---
> > Based on NXP's code base and adapted for 5.11-rc1.
> > https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/clk/imx/clk.c?h=imx_5.4.47_2.2.0&id=754ae82cc55b7445545fc2f092a70e0f490e9c1b
> >
> > The original signed-off was retained.
> > Added the fixes tag.
> > ---
> >  drivers/clk/imx/clk.c | 43 +--
> >  1 file changed, 29 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
> > index 47882c51cb85..c32b46890945 100644
> > --- a/drivers/clk/imx/clk.c
> > +++ b/drivers/clk/imx/clk.c
> > @@ -148,7 +148,7 @@ void imx_cscmr1_fixup(u32 *val)
> >
> >  #ifndef MODULE
> >  static int imx_keep_uart_clocks;
> > -static struct clk ** const *imx_uart_clocks;
> > +static bool imx_uart_clks_on;
> >
> >  static int __init imx_keep_uart_clocks_param(char *str)
> >  {
> > @@ -161,25 +161,40 @@ __setup_param("earlycon", imx_keep_uart_earlycon,
> >  __setup_param("earlyprintk", imx_keep_uart_earlyprintk,
> > imx_keep_uart_clocks_param, 0);
> >
> > -void imx_register_uart_clocks(struct clk ** const clks[])
> > +static void imx_earlycon_uart_clks_onoff(bool is_on)
>
> "is_on" sounds like it's the current state of the clock, but actually
> the variable is used for the desired state, so I suggest using plain
> "on" as name.

Sascha,

I think I'll try to keep the existing structure of imx/clk.c in place
so this function won't be needed.  It was part of NXP's custom kernel,
but I have a different idea that I'll explain below.
>
> >  {
> > - if (imx_keep_uart_clocks) {
> > - int i;
> > + struct clk *uart_clk;
> > + int i = 0;
> >
> > - imx_uart_clocks = clks;
> > - for (i = 0; imx_uart_clocks[i]; i++)
> > - clk_prepare_enable(*imx_uart_clocks[i]);
> > - }
> > + if (!imx_keep_uart_clocks || (!is_on && !imx_uart_clks_on))
> > + return;
> > +
> > + /* only support dt */
> > + if (!of_stdout)
> > + return;
> > +
> > + do {
> > + uart_clk = of_clk_get(of_stdout, i++);
>
> of_clk_get() allocates memory and gets you a reference to the clock. You
> have to release the clock with clk_put(). I think what you have to do
> here is to fill an array with clks when called from
> imx_register_uart_clocks() and when called from imx_clk_disable_uart()
> use that array to clk_disable_unprepare()/clk_put() the clocks.

I have another revision pending which modifies
imx_register_uart_clocks() to receive the number of available UART
clocks from the calling SoC. It will then allocate an array of clock
structures equal to that size.   Instead of enabling all UART clocks,
it will then go through of_clk_get(of_stdout, ...) to fill the array
and keep track of the number of devices it's assigned to the array.
Most likely the array will be larger than the number of of_stdout
entries.

Because it keeps track of the number of enabled UART's, it will use
that to go through the array and only try to unprepare/disable and put
that many clocks.  Once all the clocks have been disabled and put, the
entire clock array will be freed.

It will be more closely related to how the current imx/clk.c file is
now instead of using NXP's custom kernel, but it will also allow me to
remove the static arrays setting up the UART clocks for each SoC.

Does that sound OK to you?

I need to run some tests on my i.MX6Q board before I submit it, but
tests on my i.MX8MM are looking promising.  I can re-parent the UART
that I need reparented, and it fails if I try to reparent when that
UART is assigned to stdout.

adam
>
> Sascha
>
> > + if (IS_ERR(uart_clk))
> > + break;
> > +
> > + if (is_on)
> > + clk_prepare_enable(uart_clk);
> > + else
> > + clk_disable_unprepare(uart_clk);
> > + } while (true);
> > +
> > + if (is_on)
> > + imx_uart_clks_on = true;
> > +}
> > +void imx_register_uart_clocks(struct clk ** const clks[])
> > +{
> > + imx_earlycon_uart_clks_onoff(true);
> >  }
> >
> >  static int __init imx_clk_disable_uart(void)
> >  {
> > - if (imx_keep_uart_clocks && imx_uart_clocks) {
> > - int i;
> > -
> > - for (i = 0; imx_uart_clocks[i]; i++)
> > - clk_disable_unprepare(*imx_uart_clocks[i]);
> > - }
> > + imx_

Re: [PATCH] arm64: dts: imx8mq: Add clock parents for mipi dphy

[Guido Günther]

Hi,
On Sun, Jan 10, 2021 at 08:46:29PM +0800, Shawn Guo wrote:
> On Fri, Dec 18, 2020 at 06:50:05PM +0100, Guido Günther wrote:
> > This makes sure the clock tree setup for the dphy is not dependent on
> > other components.
> > 
> > Without this change bringing up the display can fail like
> > 
> >   kernel: phy phy-30a00300.dphy.2: Invalid CM/CN/CO values: 165/217/1
> >   kernel: phy phy-30a00300.dphy.2: for hs_clk/ref_clk=451656000/59398 ~ 
> > 165/217
> > 
> > if LCDIF doesn't set up that part of the clock tree first. This was
> > noticed when testing the Librem 5 devkit with defconfig. It doesn't
> > happen when modules are built in.
> > 
> > Signed-off-by: Guido Günther 
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mq.dtsi | 11 ---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi 
> > b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > index a841a023e8e0..ca0847e8f13c 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > @@ -1016,9 +1016,14 @@ dphy: dphy@30a00300 {
> > reg = <0x30a00300 0x100>;
> > clocks = <&clk IMX8MQ_CLK_DSI_PHY_REF>;
> > clock-names = "phy_ref";
> > -   assigned-clocks = <&clk IMX8MQ_CLK_DSI_PHY_REF>;
> > -   assigned-clock-parents = <&clk 
> > IMX8MQ_VIDEO_PLL1_OUT>;
> > -   assigned-clock-rates = <2400>;
> > +   assigned-clocks = <&clk 
> > IMX8MQ_VIDEO_PLL1_REF_SEL>,
> > + <&clk 
> > IMX8MQ_VIDEO_PLL1_BYPASS>,
> > + <&clk IMX8MQ_CLK_DSI_PHY_REF>,
> > + <&clk IMX8MQ_VIDEO_PLL1>;
> 
> You do not seem to set parent or rate on IMX8MQ_VIDEO_PLL1.  Why do you
> have it here?

Good point. I've added a clock rate for IMX8MQ_VIDEO_PLL1 since
then the clock tree reproduces exactly with and with the DSI host
controller disabled in DT (otherwise we end up with a rate of 22MHz
instead of 24Mhz).

Cheers,
 -- Guido

> 
> Shawn
> 
> > +   assigned-clock-parents = <&clk IMX8MQ_CLK_25M>,
> > + <&clk IMX8MQ_VIDEO_PLL1>,
> > + <&clk IMX8MQ_VIDEO_PLL1_OUT>;
> > +   assigned-clock-rates = <0>, <0>, <2400>;
> > #phy-cells = <0>;
> > power-domains = <&pgc_mipi>;
> > status = "disabled";
> > -- 
> > 2.29.2
> > 
> 

Re: [PATCH RFC net-next 03/19] net: mvpp2: add CM3 SRAM memory map

[Andrew Lunn]

> +static int mvpp2_get_sram(struct platform_device *pdev,
> +   struct mvpp2 *priv)
> +{
> + struct device_node *dn = pdev->dev.of_node;
> + struct resource *res;
> +
> + if (has_acpi_companion(&pdev->dev)) {
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> + if (!res) {
> + dev_warn(&pdev->dev, "ACPI is too old, TX FC 
> disabled\n");
> + return 0;
> + }
> + priv->cm3_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(priv->cm3_base))
> + return PTR_ERR(priv->cm3_base);
> + } else {
> + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> + if (!priv->sram_pool) {
> + dev_warn(&pdev->dev, "DT is too old, TX FC disabled\n");
> + return 0;
> + }
> + priv->cm3_base = (void __iomem *)gen_pool_alloc(priv->sram_pool,
> + MSS_SRAM_SIZE);
> + if (!priv->cm3_base)
> + return -ENOMEM;

Should there be -EPROBE_DEFER handling in here somewhere? The SRAM is
a device, so it might not of been probed yet?

  Andrew

Re: [PATCH 0/8] FPGA DFL Changes for 5.12

[Moritz Fischer]

Tom,

On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
> 
> On 1/7/21 8:09 AM, Tom Rix wrote:
> > On 1/6/21 8:37 PM, Moritz Fischer wrote:
> >> This is a resend of the previous (unfortunately late) patchset of
> >> changes for FPGA DFL.
> > Is there something I can do to help ?
> >
> > I am paid to look after linux-fpga, so i have plenty of time.
> >
> > Some ideas of what i am doing now privately i can do publicly.
> >
> > 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a 
> > pullable state.

Is it not? It currently points to v5.11-rc1. If I start applying patches
that require the changes that went into Greg's branch I can merge.
> >
> > 2. an in-flight dev branch for the outstanding patches 
> 
> I have setup these branches based on Greg's char-misc-next
> 
> fpga-next, which is char-misc-next base for fpga-testing
> 
> fpga-testing, all the in-flight patches that would apply with automatic merge 
> conflict resolution
> 
> These are respectively
> 
> https://github.com/trixirt/linux-fpga/tree/fpga-next
> 
> https://github.com/trixirt/linux-fpga/tree/fpga-testing

Feel free to have your own repos/branches etc, but I'd like to keep the
offical trees on kernel.org.

Tbh I'd much rather see the patchwork instance be cleaned up if you want
to do stuff.
> 
> 
> There are two trivial changes, that could go to 5.12 now.
> 
> fpga: dfl: fme: Constify static attribute_group structs
> 
> fpga: Use DEFINE_SPINLOCK() for spinlock
> 
> respectively
> 
> https://lore.kernel.org/linux-fpga/20210108235414.48017-1-rikard.falkeb...@gmail.com/
> 
> https://lore.kernel.org/linux-fpga/20201228135135.28788-1-zhengyongj...@huawei.com/

I was going to pick them up monday ...
> 
> 
> There are a couple of patchsets that conflict
> 
> https://lore.kernel.org/linux-fpga/20210105230855.15019-7-russell.h.wei...@intel.com/
> 
> https://lore.kernel.org/linux-fpga/20201203171548.1538178-3-matthew.gerl...@linux.intel.com/

Conflict between what and what?
 
> And the xilinx patchset
> 
> https://lore.kernel.org/linux-fpga/20201217075046.28553-1-son...@xilinx.com/
> 
> Which is being split/worked on offline.

I'm not sure what that means.
> 
> 
> If I have missed any patchset, poke me.
> 
> Tom

- Moritz

RE: [EXT] Re: [PATCH RFC net-next 03/19] net: mvpp2: add CM3 SRAM memory map

[Stefan Chulski]

> -Original Message-
> From: Andrew Lunn 
> Sent: Sunday, January 10, 2021 7:05 PM
> To: Stefan Chulski 
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@vger.kernel.org; k...@kernel.org;
> li...@armlinux.org.uk; m...@semihalf.com; rmk+ker...@armlinux.org.uk;
> aten...@kernel.org
> Subject: [EXT] Re: [PATCH RFC net-next 03/19] net: mvpp2: add CM3 SRAM
> memory map
> 
> External Email
> 
> --
> > +static int mvpp2_get_sram(struct platform_device *pdev,
> > + struct mvpp2 *priv)
> > +{
> > +   struct device_node *dn = pdev->dev.of_node;
> > +   struct resource *res;
> > +
> > +   if (has_acpi_companion(&pdev->dev)) {
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> > +   if (!res) {
> > +   dev_warn(&pdev->dev, "ACPI is too old, TX FC
> disabled\n");
> > +   return 0;
> > +   }
> > +   priv->cm3_base = devm_ioremap_resource(&pdev->dev,
> res);
> > +   if (IS_ERR(priv->cm3_base))
> > +   return PTR_ERR(priv->cm3_base);
> > +   } else {
> > +   priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > +   if (!priv->sram_pool) {
> > +   dev_warn(&pdev->dev, "DT is too old, TX FC
> disabled\n");
> > +   return 0;
> > +   }
> > +   priv->cm3_base = (void __iomem *)gen_pool_alloc(priv-
> >sram_pool,
> > +
>   MSS_SRAM_SIZE);
> > +   if (!priv->cm3_base)
> > +   return -ENOMEM;
> 
> Should there be -EPROBE_DEFER handling in here somewhere? The SRAM is a
> device, so it might not of been probed yet?

No, firmware probed during bootloader boot and we can use SRAM. SRAM memory can 
be safely used. 

Regards.

Re: [PATCH RFC net-next 06/19] net: mvpp2: increase BM pool size to 2048 buffers

[Andrew Lunn]

On Sun, Jan 10, 2021 at 05:30:10PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski 
> 
> BM pool size increased to support Firmware Flow Control.
> Minimum depletion thresholds to support FC is 1024 buffers.
> BM pool size increased to 2048 to have some 1024 buffers
> space between depletion thresholds and BM pool size.
> 
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index 89b3ede..8dc669d 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -851,8 +851,8 @@ enum mvpp22_ptp_packet_format {
>  #define MVPP22_PTP_TIMESTAMPQUEUESELECT  BIT(18)
>  
>  /* BM constants */
> -#define MVPP2_BM_JUMBO_BUF_NUM   512
> -#define MVPP2_BM_LONG_BUF_NUM1024
> +#define MVPP2_BM_JUMBO_BUF_NUM   2048
> +#define MVPP2_BM_LONG_BUF_NUM2048

Hi Stefan

Jumbo used to be 1/2 of regular. Do you know why?

It would be nice to have a comment in the commit message about why it
is O.K. to change the ratio of jumbo to regular frames, and what if
anything this does for memory requirements.

 Andrew
 

Re: linux-next: Fixes tag needs some work in the nfs tree

[Trond Myklebust]

Hi Stephen,

On Sun, 2021-01-10 at 13:14 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> In commit
> 
>   2cc8aca9d547 ("NFS: Adjust fs_context error logging")
> 
> Fixes tag
> 
>   Fixes: Fixes: ce8866f0913f ("NFS: Attach supplementary error
> information to fs_context.")
> 
> has these problem(s):
> 
>   - No SHA1 recognised
> 
> See duplicate "Fixes: " :-(
> 

Sorry, that was my fault. I added the 'Fixes' tag when I applied the
patch. and failed to notice the copy-paste error.
I'll fix up the commit changelog.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.mykleb...@hammerspace.com

Re: [PATCH] mm: Fix potential pte_unmap_unlock pte error

[Andi Kleen]

On Sat, Jan 09, 2021 at 03:01:18AM -0500, Miaohe Lin wrote:
> Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged
> high MMIO PROT_NONE mappings"), when the first pfn modify is not allowed,
> we would break the loop with pte unchanged. Then the wrong pte - 1 would
> be passed to pte_unmap_unlock.

Thanks.

While the fix is correct, I'm not sure if it actually is a real bug. Is there
any architecture that would do something else than unlocking the underlying
page?  If it's just the underlying page then it should be always the same
page, so no bug.

That said of course the change is the right thing for main line, but probably 
doesn't
need to be backported.

-Andi

Re: [PATCH v2 06/34] dt-bindings: Add bindings for Keem Bay VPU IPC driver

[Rob Herring]

On Fri, 08 Jan 2021 13:25:32 -0800, mgr...@linux.intel.com wrote:
> From: Paul Murphy 
> 
> Add DT bindings documentation for the Keem Bay VPU IPC driver.
> 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Reviewed-by: Mark Gross 
> Signed-off-by: Paul Murphy 
> Co-developed-by: Daniele Alessandrelli 
> Signed-off-by: Daniele Alessandrelli 
> ---
>  .../soc/intel/intel,keembay-vpu-ipc.yaml  | 153 ++
>  1 file changed, 153 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/soc/intel/intel,keembay-vpu-ipc.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/soc/intel/intel,keembay-vpu-ipc.yaml:21:9: 
[warning] wrong indentation: expected 10 but found 8 (indentation)

dtschema/dtc warnings/errors:

See https://patchwork.ozlabs.org/patch/1423960

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH 2/2] dt-bindings: pinctrl: Add bindings for Awinic AW9523/AW9523B

[Rob Herring]

On Sat, 09 Jan 2021 15:02:04 +0100, AngeloGioacchino Del Regno wrote:
> Add bindings for the Awinic AW9523/AW9523B I2C GPIO Expander driver.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  .../pinctrl/awinic,aw9523-pinctrl.yaml| 111 ++
>  1 file changed, 111 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.yaml:102:1: 
[error] syntax error: found character '\t' that cannot start any token (syntax)

dtschema/dtc warnings/errors:
./Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.yaml:  while 
scanning a block scalar
  in "", line 94, column 5
found a tab character where an indentation space is expected
  in "", line 102, column 1
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.yaml:
 ignoring, error parsing file
warning: no schema found in file: 
./Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.yaml
Traceback (most recent call last):
  File "/usr/local/bin/dt-extract-example", line 45, in 
binding = yaml.load(open(args.yamlfile, encoding='utf-8').read())
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line 343, 
in load
return constructor.get_single_data()
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", 
line 111, in get_single_data
node = self.composer.get_single_node()
  File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node
  File "_ruamel_yaml.pyx", line 724, in _ruamel_yaml.CParser._compose_document
  File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 889, in 
_ruamel_yaml.CParser._compose_mapping_node
  File "_ruamel_yaml.pyx", line 773, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 848, in 
_ruamel_yaml.CParser._compose_sequence_node
  File "_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event
ruamel.yaml.scanner.ScannerError: while scanning a block scalar
  in "", line 94, column 5
found a tab character where an indentation space is expected
  in "", line 102, column 1
make[1]: *** [Documentation/devicetree/bindings/Makefile:20: 
Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.example.dts] 
Error 1
make[1]: *** Deleting file 
'Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.example.dts'
make: *** [Makefile:1370: dt_binding_check] Error 2

See https://patchwork.ozlabs.org/patch/1424120

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH v2 08/15] dt-bindings: avs: cpr: Convert binding to YAML schema

[Rob Herring]

On Sat, 09 Jan 2021 19:03:52 +0100, AngeloGioacchino Del Regno wrote:
> Convert the qcom,cpr.txt document to YAML schema and place it in the
> appropriate directory, since this driver was moved from power/avs
> to soc/qcom, but forgets to move the documentation.
> 
> Fixes: a7305e684fcf ("PM: AVS: qcom-cpr: Move the driver to the qcom specific 
> drivers")
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  .../bindings/power/avs/qcom,cpr.txt   | 131 +-
>  .../bindings/soc/qcom/qcom,cpr.yaml   | 116 
>  MAINTAINERS   |   2 +-
>  3 files changed, 118 insertions(+), 131 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml:36:5: [warning] 
wrong indentation: expected 6 but found 4 (indentation)

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,cpr.example.dt.yaml:
 power-controller@b018000: nvmem-cells: [[4294967295], [4294967295], 
[4294967295], [4294967295], [4294967295], [4294967295], [4294967295], 
[4294967295], [4294967295], [4294967295], [4294967295], [4294967295], 
[4294967295]] is too long
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,cpr.example.dt.yaml:
 power-controller@b018000: nvmem-cell-names: ['cpr_quotient_offset1', 
'cpr_quotient_offset2', 'cpr_quotient_offset3', 'cpr_init_voltage1', 
'cpr_init_voltage2', 'cpr_init_voltage3', 'cpr_quotient1', 'cpr_quotient2', 
'cpr_quotient3', 'cpr_ring_osc1', 'cpr_ring_osc2', 'cpr_ring_osc3', 
'cpr_fuse_revision'] is too long
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,cpr.yaml

See https://patchwork.ozlabs.org/patch/1424131

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH 4/7] dt-bindings: regulator: qcom-labibb: Document soft start properties

[Rob Herring]

On Sat, 09 Jan 2021 14:29:18 +0100, AngeloGioacchino Del Regno wrote:
> Document properties to configure soft start and discharge resistor
> for LAB and IBB respectively.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  .../bindings/regulator/qcom-labibb-regulator.yaml | 8 
>  1 file changed, 8 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml:
 properties:ibb:properties:qcom,discharge-resistor-kohms: 'oneOf' conditional 
failed, one must be fixed:
'type' is a required property
Additional properties are not allowed ('default', 'enum' were 
unexpected)
Additional properties are not allowed ('default' was unexpected)

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml:
 properties:ibb:properties:qcom,discharge-resistor-kohms: 'oneOf' conditional 
failed, one must be fixed:
'$ref' is a required property
'allOf' is a required property
300 is not of type 'string'
64 is not of type 'string'
32 is not of type 'string'
16 is not of type 'string'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml:
 ignoring, error in schema: properties: ibb: properties: 
qcom,discharge-resistor-kohms
warning: no schema found in file: 
./Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml

See https://patchwork.ozlabs.org/patch/1424112

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH v2 19/34] xlink-core: Add xlink core device tree bindings

[Rob Herring]

On Fri, 08 Jan 2021 13:25:45 -0800, mgr...@linux.intel.com wrote:
> From: Seamus Kelly 
> 
> Add device tree bindings for keembay-xlink.
> 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Reviewed-by: Mark Gross 
> Signed-off-by: Seamus Kelly 
> Signed-off-by: Ryan Carnaghi 
> ---
>  .../bindings/misc/intel,keembay-xlink.yaml| 27 +++
>  1 file changed, 27 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/misc/intel,keembay-xlink.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/misc/intel,keembay-xlink.yaml:21:9: 
[warning] wrong indentation: expected 10 but found 8 (indentation)

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/misc/intel,keembay-xlink.yaml:
 'additionalProperties' is a required property
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/misc/intel,keembay-xlink.yaml:
 ignoring, error in schema: 
warning: no schema found in file: 
./Documentation/devicetree/bindings/misc/intel,keembay-xlink.yaml

See https://patchwork.ozlabs.org/patch/1423961

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH v2 15/15] dt-bindings: cpufreq: qcom-hw: Add bindings for 8998

[Rob Herring]

On Sat, 09 Jan 2021 19:03:59 +0100, AngeloGioacchino Del Regno wrote:
> The OSM programming addition has been done under the
> qcom,cpufreq-hw-8998 compatible name: specify the requirement
> of two additional register spaces for this functionality.
> This implementation, with the same compatible, has been
> tested on MSM8998 and SDM630.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  .../bindings/cpufreq/cpufreq-qcom-hw.yaml | 44 ---
>  1 file changed, 39 insertions(+), 5 deletions(-)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml:73:2: 
[warning] wrong indentation: expected 2 but found 1 (indentation)

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.example.dt.yaml:
 cpufreq@17d43000: reg: [[399781888, 5120], [399792128, 5120]] is too short
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml

See https://patchwork.ozlabs.org/patch/1424138

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH v2 17/34] xlink-ipc: Add xlink ipc device tree bindings

[Rob Herring]

On Fri, 08 Jan 2021 13:25:43 -0800, mgr...@linux.intel.com wrote:
> From: Seamus Kelly 
> 
> Add device tree bindings for the xLink IPC driver which enables xLink to
> control and communicate with the VPU IP present on the Intel Keem Bay
> SoC.
> 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> Reviewed-by: Mark Gross 
> Signed-off-by: Seamus Kelly 
> Signed-off-by: Ryan Carnaghi 
> ---
>  .../misc/intel,keembay-xlink-ipc.yaml | 49 +++
>  1 file changed, 49 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/misc/intel,keembay-xlink-ipc.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/misc/intel,keembay-xlink-ipc.yaml:21:9: 
[warning] wrong indentation: expected 10 but found 8 (indentation)

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/misc/intel,keembay-xlink-ipc.yaml:
 'additionalProperties' is a required property
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/misc/intel,keembay-xlink-ipc.yaml:
 ignoring, error in schema: 
warning: no schema found in file: 
./Documentation/devicetree/bindings/misc/intel,keembay-xlink-ipc.yaml

See https://patchwork.ozlabs.org/patch/1423958

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH 1/2] dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML

[Rob Herring]

On Fri, 08 Jan 2021 23:40:06 +0100, Jonathan Neuschäfer wrote:
> The general trend is to have devicetree bindings in YAML format, to
> allow automatic validation of bindings and devicetrees.
> 
> Convert the NPCM SoC family's binding to YAML before it accumulates more
> entries.
> 
> The nuvoton,npcm750-evb compatible string is introduced to keep the
> structure of the binding a little simpler.
> 
> Signed-off-by: Jonathan Neuschäfer 
> ---
> 
> If someone else wants to be listed as the maintainer, please let me
> know.
> ---
>  .../devicetree/bindings/arm/npcm/npcm.txt |  6 -
>  .../devicetree/bindings/arm/npcm/npcm.yaml| 23 +++
>  2 files changed, 23 insertions(+), 6 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/arm/npcm/npcm.yaml:20:13: [warning] wrong 
indentation: expected 14 but found 12 (indentation)

dtschema/dtc warnings/errors:
./Documentation/devicetree/bindings/arm/npcm/npcm.yaml: $id: relative 
path/filename doesn't match actual path or filename
expected: http://devicetree.org/schemas/arm/npcm/npcm.yaml#

See https://patchwork.ozlabs.org/patch/1423975

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

[PATCH] arm/kasan: kasan_alloc a more precise size for pte

[Hailong Liu]

From: Hailong Liu 

The *PTE_HWTABLE_OFF + PTE_HWTABLE_SIZE* may be a more accurate and
meaningful size for PTE tables than *PAGE_SIZE* when populating the
PMD entries for arm.

Signed-off-by: Hailong Liu 
---
 arch/arm/mm/kasan_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 9c348042a724..c2a697704d6c 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -99,7 +99,7 @@ static void __init kasan_pmd_populate(pud_t *pudp, unsigned 
long addr,
 * allocated.
 */
void *p = early ? kasan_early_shadow_pte :
-   kasan_alloc_block(PAGE_SIZE);
+   kasan_alloc_block(PTE_HWTABLE_OFF + 
PTE_HWTABLE_SIZE);
 
if (!p) {
panic("%s failed to allocate shadow block for 
address 0x%lx\n",
-- 
2.17.1

Re: depmod fixes for linux-stable releases

[Sedat Dilek]

On Sun, Jan 10, 2021 at 11:19 AM Sasha Levin  wrote:
>
> On Sat, Jan 09, 2021 at 05:23:22PM -0800, Linus Torvalds wrote:
> >Ack, I think 436e980e2ed5 ("kbuild: don't hardcode depmod path") is
> >stable material even if it doesn't fix a bug.
> >
> >Not only does the fix for that commit not make sense without the
> >commit in the first place, but any environment that sets depmod
> >somewhere else might well be an environment that still wants stable
> >kernels.
> >
> >It may not be the traditional case, but there's little reason for the
> >kernel build to force that /sbin/depmod location.
>
> I'll take it, thanks!
>

Thanks for pushing (and correcting the stable-ML email-address).

- Sedat -

RE: [PATCH v8 03/20] dlb: add resource and device initialization

[Chen, Mike Ximing]

> -Original Message-
> From: Greg KH 
> Sent: Thursday, January 7, 2021 2:40 PM
> To: Chen, Mike Ximing 
> Cc: linux-kernel@vger.kernel.org; a...@arndb.de; Williams, Dan J
> ; pierre-louis.boss...@linux.intel.com; Gage Eads
> 
> Subject: Re: [PATCH v8 03/20] dlb: add resource and device initialization
> 
> On Mon, Jan 04, 2021 at 08:58:22PM -0600, Mike Ximing Chen wrote:
> > Introduce dlb_bitmap_* functions, a thin convenience layer wrapping the
> > Linux bitmap interfaces, used by the bitmaps in the dlb hardware types.
> 
> No, you created custom #defines:
> 
> > --- a/drivers/misc/dlb/dlb_hw_types.h
> > +++ b/drivers/misc/dlb/dlb_hw_types.h
> > @@ -5,6 +5,15 @@
> >  #define __DLB_HW_TYPES_H
> >
> >  #include 
> > +#include 
> > +
> > +#include "dlb_bitmap.h"
> > +
> > +#define BITS_SET(x, val, mask) (x = ((x) & ~(mask)) \
> > +| (((val) << (mask##_LOC)) & (mask)))
> > +#define BITS_CLR(x, mask)  ((x) &= ~(mask))
> > +#define BIT_SET(x, mask)((x) |= (mask))
> > +#define BITS_GET(x, mask)   (((x) & (mask)) >> (mask##_LOC))
> 
> We have functions for this, use them, don't create custom macros for
> them.  Use the Linux functions please.
> 
> thanks,
> 
> greg k-h

FIELD_GET(_mask, _val) and FIELD_PREP(_mask, _val) in include/linux/bitfield.h 
are similar to our BITS_GET() and BITS_SET().  However in our case, mask##_LOC 
is a known constant defined in dlb_regs.h.  So we don't need to use 
_buildin_ffs(mask) to calculate the location of mask as FIELD_GET() and 
FIELD_PREP() do.  We can still use FIELD_GET and FIELD_PREP, but our macros are 
a little more efficient. Would it be OK to use them? 

Thanks
Mike

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sun, Jan 10, 2021 at 5:48 PM Andrew Lunn  wrote:
>
> > For this platform, I'm most interested in whether there are still users
> > that rely on board files instead of DT. AFAIU we could just fold
> > the DT variant into arch-mvebu like kirkwood was, right?
>
> Hi Arnd
>
> I'm actually booting my device using a board file. But Debian
> flash-kernel is pretty unhappy about that. The bootloader i have on
> this machine is too old to passed DT blob. I will test appended DT
> blob still works. And see if we have any board files which also don't
> have a DT representation.

It may help to ask for these at
https://github.com/101101000/Debian_on_Buffalo/,
I already contacted them about mv78xx0. I tried to find
out how the Linkstation/Terastation board files map to the
dts files, but couldn't figure it out either. It seems they
want to keep supporting all those machines and can probably
help out ensure that there are dts files for each one.

  Arnd

RE: [EXT] Re: [PATCH RFC net-next 06/19] net: mvpp2: increase BM pool size to 2048 buffers

[Stefan Chulski]

> External Email
> 
> --
> On Sun, Jan 10, 2021 at 05:30:10PM +0200, stef...@marvell.com wrote:
> > From: Stefan Chulski 
> >
> > BM pool size increased to support Firmware Flow Control.
> > Minimum depletion thresholds to support FC is 1024 buffers.
> > BM pool size increased to 2048 to have some 1024 buffers space between
> > depletion thresholds and BM pool size.
> >
> > Signed-off-by: Stefan Chulski 
> > ---
> >  drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> > b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> > index 89b3ede..8dc669d 100644
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> > @@ -851,8 +851,8 @@ enum mvpp22_ptp_packet_format {
> >  #define MVPP22_PTP_TIMESTAMPQUEUESELECTBIT(18)
> >
> >  /* BM constants */
> > -#define MVPP2_BM_JUMBO_BUF_NUM 512
> > -#define MVPP2_BM_LONG_BUF_NUM  1024
> > +#define MVPP2_BM_JUMBO_BUF_NUM 2048
> > +#define MVPP2_BM_LONG_BUF_NUM  2048
> 
> Hi Stefan
> 
> Jumbo used to be 1/2 of regular. Do you know why?
> 
> It would be nice to have a comment in the commit message about why it is
> O.K. to change the ratio of jumbo to regular frames, and what if anything this
> does for memory requirements.
> 
>Andrew

I don't know why it is half(no hardware restrictions for this). I would add to 
commit message new memory requirements for buffer allocations.

Thanks.

Re: [PATCH RFC net-next 14/19] net: mvpp2: add ethtool flow control configuration support

[Andrew Lunn]

> @@ -5373,6 +5402,30 @@ static int mvpp2_ethtool_set_pause_param(struct 
> net_device *dev,
>struct ethtool_pauseparam *pause)
>  {
>   struct mvpp2_port *port = netdev_priv(dev);
> + int i;
> +
> + if (pause->tx_pause && port->priv->global_tx_fc) {
> + port->tx_fc = true;
> + mvpp2_rxq_enable_fc(port);
> + if (port->priv->percpu_pools) {
> + for (i = 0; i < port->nrxqs; i++)
> + mvpp2_bm_pool_update_fc(port, 
> &port->priv->bm_pools[i], true);
> + } else {
> + mvpp2_bm_pool_update_fc(port, port->pool_long, true);
> + mvpp2_bm_pool_update_fc(port, port->pool_short, true);
> + }
> +
> + } else if (port->priv->global_tx_fc) {
> + port->tx_fc = false;
> + mvpp2_rxq_disable_fc(port);
> + if (port->priv->percpu_pools) {
> + for (i = 0; i < port->nrxqs; i++)
> + mvpp2_bm_pool_update_fc(port, 
> &port->priv->bm_pools[i], false);
> + } else {
> + mvpp2_bm_pool_update_fc(port, port->pool_long, false);
> + mvpp2_bm_pool_update_fc(port, port->pool_short, false);
> + }
> + }


This looks wrong. Flow control is normally the result of auto
negotiation. Both ends need to agree to it. Which is why
mvpp2_ethtool_set_pause_param() passes the users request onto phylink.
phylink will handle the autoneg and then ask the MAC to setup flow
control depending on the result in mvpp2_mac_link_up().

Andrew

Re: Old platforms: bring out your dead

[John Paul Adrian Glaubitz]

Hi Arnd!

(Please let's have this cross-posted for more visibility. I only learned about 
this
 while reading Phoronix news)

> I also looked at non-ARM platforms while preparing for my article. Some of
> these look like they are no longer actively maintained or used, but I'm not
> doing anything about those unless the maintainers would like me to:
> 
> * h8300: Steven Rostedt has repeatedly asked about it to be removed
>or fixed in 2020 with no reply. This was killed before in 2013, added back
>in 2015 but has been mostly stale again since 2016

As far as I know, Yoshinori Sato is actively maintaining H8300 support, see:

> https://osdn.net/projects/uclinux-h8/

> * c6x: Added in 2011, this has seen very few updates since, but
> Mark still Acks patches when they come. Like most other DSP platforms,
> the model of running Linux on a DSP appears to have been obsoleted
> by using Linux on ARM with on-chip DSP cores running bare-metal code.
> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
>is currently under review

I don't think this has reached any agreement yet. Multiple people want it to 
stay.

> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove 
> it.
>it's in my backlog but I will get to it. This is separate from PS3,
> which is actively
>maintained and used; spufs will move to ps3
> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009

I'm still using this. Please keep it.

> * powerpc/amigaone: last updated in 2009
> * powerpc/maple: last updated in 2011
> * m68k/{apollo,hp300,sun3,q40} these are all presumably dead and have not
>seen updates in many years (atari/amiga/mac and coldfire are very much
>alive)

Dito. I have both sun3 and hp300 machines.

> * mips/jazz: last updated in 2007
> * mips/cobalt: last updated in 2010
> 
> There might be some value in dropping old CPU support on architectures
> and platforms that are almost exclusively used with more modern CPUs.
> If there are only few users, those can still keep using v5.10 or v5.4 stable
> kernels for a few more years. Again, I'm not doing anything about them,
> except mention them since I did the research.
> These are the oldest one by architecture, and they may have reached
> their best-served-by-date:
> 
> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
>   indications that 486 have no users either on recent kernels.
>   There is still the Vortex86 family of SoCs, and the oldest of those were
>   486SX-class, but all the modern ones are 586-class.
> * Alpha 2106x: First generation that lacks some of the later features.
>   Since all Alphas are ancient by now, it's hard to tell whether these have
>   any fewer users.

I don't see the point in crippling Alpha support. Does this achieve anything?

> * IA64 Merced: first generation Itanium (2001) was quickly replaced by
>   Itanium II in 2002.
> * MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
>   64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
>   supports these in DECstation and Toshiba Txx9, but it appears that most
>   of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
>   later are rather different and widely used.
> * PowerPC 601 (from 1992) just got removed, later 60x, 4xx, 8xx etc
>   are apparently all still used.
> * SuperH SH-2: We discussed removing SH-2 (not J2 or SH-4)
>   support in the past, I don't think there were any objections, but
>   nobody submitted a patch.

Isn't SH-2 basically J-2? I'm not sure what we would gain here.

> * 68000/68328 (Dragonball): these are less capable than the
>   68020+ or the Coldfire MCF5xxx line and similar to the 68360
>   that was removed in 2016.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH RFC net-next 18/19] net: mvpp2: add ring size validation before enabling FC

[Andrew Lunn]

On Sun, Jan 10, 2021 at 05:30:22PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski 
> 
> This patch add ring size validation before enabling FC.
> 1. Flow control cannot be enabled if ring size is below start
> threshold.
> 2. Flow control disabled if ring size set below start
> threshold.

You should also tell phylink if pause is not supported, so it can
change what is auto-negotiated, letting the link partner know.

   Andrew

[RFC PATCH v2 2/8] Add a reference to ucounts for each user

[Alexey Gladkov]

Before this, only the owner of the user namespace had an entry in ucounts.
This entry addressed the user in the given user namespace.

Now we create such an entry in ucounts for all users in the user namespace.
Each user has only one entry for each user namespace.

This commit is in preparation for migrating rlimits to ucounts.

Signed-off-by: Alexey Gladkov 
---
 include/linux/cred.h   |  1 +
 include/linux/user_namespace.h |  2 ++
 kernel/cred.c  | 17 +++--
 kernel/ucount.c| 12 +++-
 kernel/user_namespace.c|  1 +
 5 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/include/linux/cred.h b/include/linux/cred.h
index 18639c069263..307744fcc387 100644
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -144,6 +144,7 @@ struct cred {
 #endif
struct user_struct *user;   /* real user ID subscription */
struct user_namespace *user_ns; /* user_ns the caps and keyrings are 
relative to. */
+   struct ucounts *ucounts;
struct group_info *group_info;  /* supplementary groups for euid/fsgid 
*/
/* RCU deletion */
union {
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 84fefa9247c4..483568a56f7f 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -102,6 +102,8 @@ bool setup_userns_sysctls(struct user_namespace *ns);
 void retire_userns_sysctls(struct user_namespace *ns);
 struct ucounts *inc_ucount(struct user_namespace *ns, kuid_t uid, enum 
ucount_type type);
 void dec_ucount(struct ucounts *ucounts, enum ucount_type type);
+void put_ucounts(struct ucounts *ucounts);
+void set_cred_ucounts(const struct cred *cred, struct user_namespace *ns, 
kuid_t uid);
 
 #ifdef CONFIG_USER_NS
 
diff --git a/kernel/cred.c b/kernel/cred.c
index 421b1149c651..d19e2e97092c 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -119,6 +119,7 @@ static void put_cred_rcu(struct rcu_head *rcu)
if (cred->group_info)
put_group_info(cred->group_info);
free_uid(cred->user);
+   put_ucounts(cred->ucounts);
put_user_ns(cred->user_ns);
kmem_cache_free(cred_jar, cred);
 }
@@ -144,6 +145,9 @@ void __put_cred(struct cred *cred)
BUG_ON(cred == current->cred);
BUG_ON(cred == current->real_cred);
 
+   BUG_ON(cred->ucounts == NULL);
+   BUG_ON(cred->ucounts->ns != cred->user_ns);
+
if (cred->non_rcu)
put_cred_rcu(&cred->rcu);
else
@@ -271,6 +275,9 @@ struct cred *prepare_creds(void)
get_uid(new->user);
get_user_ns(new->user_ns);
 
+   new->ucounts = NULL;
+   set_cred_ucounts(new, new->user_ns, new->euid);
+
 #ifdef CONFIG_KEYS
key_get(new->session_keyring);
key_get(new->process_keyring);
@@ -363,6 +370,7 @@ int copy_creds(struct task_struct *p, unsigned long 
clone_flags)
ret = create_user_ns(new);
if (ret < 0)
goto error_put;
+   set_cred_ucounts(new, new->user_ns, new->euid);
}
 
 #ifdef CONFIG_KEYS
@@ -485,8 +493,11 @@ int commit_creds(struct cred *new)
 * in set_user().
 */
alter_cred_subscribers(new, 2);
-   if (new->user != old->user)
-   atomic_inc(&new->user->processes);
+   if (new->user != old->user || new->user_ns != old->user_ns) {
+   if (new->user != old->user)
+   atomic_inc(&new->user->processes);
+   set_cred_ucounts(new, new->user_ns, new->euid);
+   }
rcu_assign_pointer(task->real_cred, new);
rcu_assign_pointer(task->cred, new);
if (new->user != old->user)
@@ -661,6 +672,7 @@ void __init cred_init(void)
/* allocate a slab in which we can store credentials */
cred_jar = kmem_cache_create("cred_jar", sizeof(struct cred), 0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL);
+   set_cred_ucounts(&init_cred, &init_user_ns, GLOBAL_ROOT_UID);
 }
 
 /**
@@ -704,6 +716,7 @@ struct cred *prepare_kernel_cred(struct task_struct *daemon)
get_uid(new->user);
get_user_ns(new->user_ns);
get_group_info(new->group_info);
+   set_cred_ucounts(new, new->user_ns, new->euid);
 
 #ifdef CONFIG_KEYS
new->session_keyring = NULL;
diff --git a/kernel/ucount.c b/kernel/ucount.c
index 0f2c7c11df19..80a39073bcef 100644
--- a/kernel/ucount.c
+++ b/kernel/ucount.c
@@ -161,7 +161,7 @@ static struct ucounts *get_ucounts(struct user_namespace 
*ns, kuid_t uid)
return ucounts;
 }
 
-static void put_ucounts(struct ucounts *ucounts)
+void put_ucounts(struct ucounts *ucounts)
 {
unsigned long flags;
 
@@ -175,6 +175,16 @@ static void put_ucounts(struct ucounts *ucounts)
kfree(ucounts);
 }
 
+void set_cred_ucounts(const struct cred *cred, struct user_namespace *ns, 
kuid_t uid)
+{
+   if (cred->ucounts) {
+   if (cred->ucounts

[RFC PATCH v2 0/8] Count rlimits in each user namespace

[Alexey Gladkov]

Preface
---
These patches are for binding the rlimit counters to a user in user namespace.
This patch set can be applied on top of:

git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v5.11-rc2

Problem
---
Some rlimits are set per user: RLIMIT_NPROC, RLIMIT_MEMLOCK, RLIMIT_SIGPENDING,
RLIMIT_MSGQUEUE. When several containers are created from one user then
the processes inside the containers influence each other.

Eric W. Biederman mentioned this issue [1][2][3].

For example, there are two containers (A and B) created by one user. The
container A sets RLIMIT_NPROC=1 and starts one process. Everything is fine, but
when container B tries to do the same it will fail because the number of
processes is counted globally for each user and user has one process already.

On the other hand, we cannot simply calculate the rlimits for each container
separately. This will lead to the fact that the user creating a new user
namespace can create a fork bomb.

Introduced changes
--
To address the problem, we bind rlimit counters to each user namespace. The
result is a tree of rlimit counters with the biggest value at the root (aka
init_user_ns). The rlimit counter increment/decrement occurs in the current and
all parent user namespaces.

ToDo

* No documentation.
* No tests.

[1] https://lore.kernel.org/containers/87imd2incs@x220.int.ebiederm.org/
[2] 
https://lists.linuxfoundation.org/pipermail/containers/2020-August/042096.html
[3] 
https://lists.linuxfoundation.org/pipermail/containers/2020-October/042524.html

Changelog
-
v2:
* RLIMIT_MEMLOCK, RLIMIT_SIGPENDING and RLIMIT_MSGQUEUE are migrated to ucounts.
* Added ucounts for pair uid and user namespace into cred.
* Added the ability to increase ucount by more than 1.

v1:
* After discussion with Eric W. Biederman, I increased the size of ucounts to
  atomic_long_t.
* Added ucount_max to avoid the fork bomb.

--

Alexey Gladkov (8):
  Use atomic type for ucounts reference counting
  Add a reference to ucounts for each user
  Increase size of ucounts to atomic_long_t
  Move RLIMIT_NPROC counter to ucounts
  Move RLIMIT_MSGQUEUE counter to ucounts
  Move RLIMIT_SIGPENDING counter to ucounts
  Move RLIMIT_MEMLOCK counter to ucounts
  Move RLIMIT_NPROC check to the place where we increment the counter

 fs/exec.c  |  2 +-
 fs/hugetlbfs/inode.c   | 17 +++---
 fs/io-wq.c | 22 
 fs/io-wq.h |  2 +-
 fs/io_uring.c  |  2 +-
 fs/proc/array.c|  2 +-
 include/linux/cred.h   |  3 ++
 include/linux/hugetlb.h|  3 +-
 include/linux/mm.h |  4 +-
 include/linux/sched/user.h |  6 ---
 include/linux/shmem_fs.h   |  2 +-
 include/linux/signal_types.h   |  4 +-
 include/linux/user_namespace.h | 31 +--
 ipc/mqueue.c   | 29 +-
 ipc/shm.c  | 31 ++-
 kernel/cred.c  | 43 +++
 kernel/exit.c  |  2 +-
 kernel/fork.c  | 12 +++--
 kernel/signal.c| 53 --
 kernel/sys.c   | 13 -
 kernel/ucount.c| 99 +-
 kernel/user.c  |  2 -
 kernel/user_namespace.c|  7 ++-
 mm/memfd.c |  4 +-
 mm/mlock.c | 35 +---
 mm/mmap.c  |  3 +-
 mm/shmem.c |  8 +--
 27 files changed, 268 insertions(+), 173 deletions(-)

-- 
2.29.2

[RFC PATCH v2 5/8] Move RLIMIT_MSGQUEUE counter to ucounts

[Alexey Gladkov]

Signed-off-by: Alexey Gladkov 
---
 include/linux/sched/user.h |  4 
 include/linux/user_namespace.h |  8 
 ipc/mqueue.c   | 29 +++--
 kernel/fork.c  |  1 +
 kernel/ucount.c|  1 +
 kernel/user_namespace.c|  1 +
 6 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/include/linux/sched/user.h b/include/linux/sched/user.h
index d33d867ad6c1..8a34446681aa 100644
--- a/include/linux/sched/user.h
+++ b/include/linux/sched/user.h
@@ -18,10 +18,6 @@ struct user_struct {
 #endif
 #ifdef CONFIG_EPOLL
atomic_long_t epoll_watches; /* The number of file descriptors 
currently watched */
-#endif
-#ifdef CONFIG_POSIX_MQUEUE
-   /* protected by mq_lock */
-   unsigned long mq_bytes; /* How many bytes can be allocated to mqueue? */
 #endif
unsigned long locked_shm; /* How many pages of mlocked shm ? */
unsigned long unix_inflight;/* How many files in flight in unix 
sockets */
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 43c83ed2fc61..2980afed6fb7 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -51,6 +51,7 @@ enum ucount_type {
UCOUNT_INOTIFY_WATCHES,
 #endif
UCOUNT_RLIMIT_NPROC,
+   UCOUNT_RLIMIT_MSGQUEUE,
UCOUNT_COUNTS,
 };
 
@@ -113,6 +114,13 @@ static inline long get_ucounts_value(struct ucounts 
*ucounts, enum ucount_type t
return atomic_long_read(&ucounts->ucount[type]);
 }
 
+static inline struct ucounts *get_ucount(struct ucounts *ucounts)
+{
+   if (ucounts)
+   atomic_inc(&ucounts->count);
+   return ucounts;
+}
+
 bool inc_rlimit_ucounts(struct ucounts *ucounts, enum ucount_type type, long 
v);
 bool inc_rlimit_ucounts_and_test(struct ucounts *ucounts, enum ucount_type 
type, long v, long max);
 void dec_rlimit_ucounts(struct ucounts *ucounts, enum ucount_type type, long 
v);
diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index beff0cfcd1e8..67088f1aa6b0 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -144,7 +144,7 @@ struct mqueue_inode_info {
struct pid *notify_owner;
u32 notify_self_exec_id;
struct user_namespace *notify_user_ns;
-   struct user_struct *user;   /* user who created, for accounting */
+   struct ucounts *ucounts;/* user who created, for accounting */
struct sock *notify_sock;
struct sk_buff *notify_cookie;
 
@@ -292,7 +292,6 @@ static struct inode *mqueue_get_inode(struct super_block 
*sb,
struct ipc_namespace *ipc_ns, umode_t mode,
struct mq_attr *attr)
 {
-   struct user_struct *u = current_user();
struct inode *inode;
int ret = -ENOMEM;
 
@@ -309,6 +308,8 @@ static struct inode *mqueue_get_inode(struct super_block 
*sb,
if (S_ISREG(mode)) {
struct mqueue_inode_info *info;
unsigned long mq_bytes, mq_treesize;
+   struct ucounts *ucounts;
+   bool overlimit;
 
inode->i_fop = &mqueue_file_operations;
inode->i_size = FILENT_SIZE;
@@ -321,7 +322,7 @@ static struct inode *mqueue_get_inode(struct super_block 
*sb,
info->notify_owner = NULL;
info->notify_user_ns = NULL;
info->qsize = 0;
-   info->user = NULL;  /* set when all is ok */
+   info->ucounts = NULL;   /* set when all is ok */
info->msg_tree = RB_ROOT;
info->msg_tree_rightmost = NULL;
info->node_cache = NULL;
@@ -371,19 +372,19 @@ static struct inode *mqueue_get_inode(struct super_block 
*sb,
if (mq_bytes + mq_treesize < mq_bytes)
goto out_inode;
mq_bytes += mq_treesize;
+   ucounts = current_ucounts();
spin_lock(&mq_lock);
-   if (u->mq_bytes + mq_bytes < u->mq_bytes ||
-   u->mq_bytes + mq_bytes > rlimit(RLIMIT_MSGQUEUE)) {
+   overlimit = inc_rlimit_ucounts_and_test(ucounts, 
UCOUNT_RLIMIT_MSGQUEUE,
+   mq_bytes, rlimit(RLIMIT_MSGQUEUE));
+   if (overlimit) {
+   dec_rlimit_ucounts(ucounts, UCOUNT_RLIMIT_MSGQUEUE, 
mq_bytes);
spin_unlock(&mq_lock);
/* mqueue_evict_inode() releases info->messages */
ret = -EMFILE;
goto out_inode;
}
-   u->mq_bytes += mq_bytes;
spin_unlock(&mq_lock);
-
-   /* all is ok */
-   info->user = get_uid(u);
+   info->ucounts = get_ucount(ucounts);
} else if (S_ISDIR(mode)) {
inc_nlink(inode);
/* Some things misbehave if size == 0 on a directory */
@@ -497,7 +498,7 @@ static void mqueue_free_inode(struct inode *inode)
 static void m

[RFC PATCH v2 6/8] Move RLIMIT_SIGPENDING counter to ucounts

[Alexey Gladkov]

Signed-off-by: Alexey Gladkov 
---
 fs/proc/array.c|  2 +-
 include/linux/sched/user.h |  1 -
 include/linux/signal_types.h   |  4 ++-
 include/linux/user_namespace.h |  1 +
 kernel/fork.c  |  1 +
 kernel/signal.c| 53 ++
 kernel/ucount.c|  1 +
 kernel/user.c  |  1 -
 kernel/user_namespace.c|  1 +
 9 files changed, 30 insertions(+), 35 deletions(-)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index bb87e4d89cd8..74b0ea4b7e38 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -284,7 +284,7 @@ static inline void task_sig(struct seq_file *m, struct 
task_struct *p)
collect_sigign_sigcatch(p, &ignored, &caught);
num_threads = get_nr_threads(p);
rcu_read_lock();  /* FIXME: is this correct? */
-   qsize = atomic_read(&__task_cred(p)->user->sigpending);
+   qsize = get_ucounts_value(task_ucounts(p), 
UCOUNT_RLIMIT_SIGPENDING);
rcu_read_unlock();
qlim = task_rlimit(p, RLIMIT_SIGPENDING);
unlock_task_sighand(p, &flags);
diff --git a/include/linux/sched/user.h b/include/linux/sched/user.h
index 8a34446681aa..8ba9cec4fb99 100644
--- a/include/linux/sched/user.h
+++ b/include/linux/sched/user.h
@@ -12,7 +12,6 @@
  */
 struct user_struct {
refcount_t __count; /* reference count */
-   atomic_t sigpending;/* How many pending signals does this user 
have? */
 #ifdef CONFIG_FANOTIFY
atomic_t fanotify_listeners;
 #endif
diff --git a/include/linux/signal_types.h b/include/linux/signal_types.h
index 68e06c75c5b2..34cb28b8f16c 100644
--- a/include/linux/signal_types.h
+++ b/include/linux/signal_types.h
@@ -13,6 +13,8 @@ typedef struct kernel_siginfo {
__SIGINFO;
 } kernel_siginfo_t;
 
+struct ucounts;
+
 /*
  * Real Time signals may be queued.
  */
@@ -21,7 +23,7 @@ struct sigqueue {
struct list_head list;
int flags;
kernel_siginfo_t info;
-   struct user_struct *user;
+   struct ucounts *ucounts;
 };
 
 /* flags values. */
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 2980afed6fb7..7719e2163b72 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -52,6 +52,7 @@ enum ucount_type {
 #endif
UCOUNT_RLIMIT_NPROC,
UCOUNT_RLIMIT_MSGQUEUE,
+   UCOUNT_RLIMIT_SIGPENDING,
UCOUNT_COUNTS,
 };
 
diff --git a/kernel/fork.c b/kernel/fork.c
index f61a5a3dc02f..a7be5790392e 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -825,6 +825,7 @@ void __init fork_init(void)
 
init_user_ns.ucount_max[UCOUNT_RLIMIT_NPROC] = task_rlimit(&init_task, 
RLIMIT_NPROC);
init_user_ns.ucount_max[UCOUNT_RLIMIT_MSGQUEUE] = 
task_rlimit(&init_task, RLIMIT_MSGQUEUE);
+   init_user_ns.ucount_max[UCOUNT_RLIMIT_SIGPENDING] = 
task_rlimit(&init_task, RLIMIT_SIGPENDING);
 
 #ifdef CONFIG_VMAP_STACK
cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "fork:vm_stack_cache",
diff --git a/kernel/signal.c b/kernel/signal.c
index 5736c55aaa1a..877020481212 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -412,49 +412,40 @@ void task_join_group_stop(struct task_struct *task)
 static struct sigqueue *
 __sigqueue_alloc(int sig, struct task_struct *t, gfp_t flags, int 
override_rlimit)
 {
-   struct sigqueue *q = NULL;
-   struct user_struct *user;
-   int sigpending;
+   struct sigqueue *q = kmem_cache_alloc(sigqueue_cachep, flags);
 
-   /*
-* Protect access to @t credentials. This can go away when all
-* callers hold rcu read lock.
-*
-* NOTE! A pending signal will hold on to the user refcount,
-* and we get/put the refcount only when the sigpending count
-* changes from/to zero.
-*/
-   rcu_read_lock();
-   user = __task_cred(t)->user;
-   sigpending = atomic_inc_return(&user->sigpending);
-   if (sigpending == 1)
-   get_uid(user);
-   rcu_read_unlock();
+   if (likely(q != NULL)) {
+   bool overlimit;
 
-   if (override_rlimit || likely(sigpending <= task_rlimit(t, 
RLIMIT_SIGPENDING))) {
-   q = kmem_cache_alloc(sigqueue_cachep, flags);
-   } else {
-   print_dropped_signal(sig);
-   }
-
-   if (unlikely(q == NULL)) {
-   if (atomic_dec_and_test(&user->sigpending))
-   free_uid(user);
-   } else {
INIT_LIST_HEAD(&q->list);
q->flags = 0;
-   q->user = user;
+
+   /*
+* Protect access to @t credentials. This can go away when all
+* callers hold rcu read lock.
+*/
+   rcu_read_lock();
+   q->ucounts = get_ucount(task_ucounts(t));
+   overlimit = inc_rlimit_ucounts_and_test(q->ucounts, 
UCOUNT_RLIMIT_SIGPENDING,
+  

Re: [EXT] Re: [PATCH RFC net-next 03/19] net: mvpp2: add CM3 SRAM memory map

[Andrew Lunn]

> > Should there be -EPROBE_DEFER handling in here somewhere? The SRAM is a
> > device, so it might not of been probed yet?
> 

> No, firmware probed during bootloader boot and we can use SRAM. SRAM
> memory can be safely used.

A previous patch added:

+   CP11X_LABEL(cm3_sram): cm3@22 {
+   compatible = "mmio-sram";
+   reg = <0x22 0x800>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x22 0x800>;
+   };
+

So it looks like the SRAM is a device, in the linux driver model. And
there is a driver for this, driver/misc/sram.c. How do you know this
device has been probed before the Ethernet driver?

   Andrew

[RFC PATCH v2 7/8] Move RLIMIT_MEMLOCK counter to ucounts

[Alexey Gladkov]

Signed-off-by: Alexey Gladkov 
---
 fs/hugetlbfs/inode.c   | 17 -
 include/linux/hugetlb.h|  3 +--
 include/linux/mm.h |  4 ++--
 include/linux/shmem_fs.h   |  2 +-
 include/linux/user_namespace.h |  1 +
 ipc/shm.c  | 31 --
 kernel/fork.c  |  1 +
 kernel/ucount.c|  1 +
 kernel/user_namespace.c|  1 +
 mm/memfd.c |  4 +---
 mm/mlock.c | 35 +-
 mm/mmap.c  |  3 +--
 mm/shmem.c |  8 
 13 files changed, 52 insertions(+), 59 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index b5c109703daa..82298412f020 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1451,34 +1451,35 @@ static int get_hstate_idx(int page_size_log)
  * otherwise hugetlb_reserve_pages reserves one less hugepages than intended.
  */
 struct file *hugetlb_file_setup(const char *name, size_t size,
-   vm_flags_t acctflag, struct user_struct **user,
+   vm_flags_t acctflag,
int creat_flags, int page_size_log)
 {
struct inode *inode;
struct vfsmount *mnt;
int hstate_idx;
struct file *file;
+   const struct cred *cred;
 
hstate_idx = get_hstate_idx(page_size_log);
if (hstate_idx < 0)
return ERR_PTR(-ENODEV);
 
-   *user = NULL;
mnt = hugetlbfs_vfsmount[hstate_idx];
if (!mnt)
return ERR_PTR(-ENOENT);
 
if (creat_flags == HUGETLB_SHMFS_INODE && !can_do_hugetlb_shm()) {
-   *user = current_user();
-   if (user_shm_lock(size, *user)) {
+   cred = current_cred();
+   if (user_shm_lock(size, cred)) {
task_lock(current);
pr_warn_once("%s (%d): Using mlock ulimits for 
SHM_HUGETLB is deprecated\n",
current->comm, current->pid);
task_unlock(current);
} else {
-   *user = NULL;
return ERR_PTR(-EPERM);
}
+   } else {
+   cred = NULL;
}
 
file = ERR_PTR(-ENOSPC);
@@ -1503,10 +1504,8 @@ struct file *hugetlb_file_setup(const char *name, size_t 
size,
 
iput(inode);
 out:
-   if (*user) {
-   user_shm_unlock(size, *user);
-   *user = NULL;
-   }
+   if (cred)
+   user_shm_unlock(size, cred);
return file;
 }
 
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index ebca2ef02212..fbd36c452648 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -434,8 +434,7 @@ static inline struct hugetlbfs_inode_info 
*HUGETLBFS_I(struct inode *inode)
 extern const struct file_operations hugetlbfs_file_operations;
 extern const struct vm_operations_struct hugetlb_vm_ops;
 struct file *hugetlb_file_setup(const char *name, size_t size, vm_flags_t acct,
-   struct user_struct **user, int creat_flags,
-   int page_size_log);
+   int creat_flags, int page_size_log);
 
 static inline bool is_file_hugepages(struct file *file)
 {
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ecdf8a8cd6ae..30a37aef1ab9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1628,8 +1628,8 @@ extern bool can_do_mlock(void);
 #else
 static inline bool can_do_mlock(void) { return false; }
 #endif
-extern int user_shm_lock(size_t, struct user_struct *);
-extern void user_shm_unlock(size_t, struct user_struct *);
+extern int user_shm_lock(size_t, const struct cred *);
+extern void user_shm_unlock(size_t, const struct cred *);
 
 /*
  * Parameter block passed down to zap_pte_range in exceptional cases.
diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
index d82b6f396588..10f50b1c4e0e 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -65,7 +65,7 @@ extern struct file *shmem_file_setup_with_mnt(struct vfsmount 
*mnt,
 extern int shmem_zero_setup(struct vm_area_struct *);
 extern unsigned long shmem_get_unmapped_area(struct file *, unsigned long addr,
unsigned long len, unsigned long pgoff, unsigned long flags);
-extern int shmem_lock(struct file *file, int lock, struct user_struct *user);
+extern int shmem_lock(struct file *file, int lock, const struct cred *cred);
 #ifdef CONFIG_SHMEM
 extern const struct address_space_operations shmem_aops;
 static inline bool shmem_mapping(struct address_space *mapping)
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 7719e2163b72..320275e44524 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -53,6 +53,7 @@ enum ucount_type {
  

[RFC PATCH v2 1/8] Use atomic type for ucounts reference counting

[Alexey Gladkov]

Signed-off-by: Alexey Gladkov 
---
 include/linux/user_namespace.h |  2 +-
 kernel/ucount.c| 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 64cf8ebdc4ec..84fefa9247c4 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -92,7 +92,7 @@ struct ucounts {
struct hlist_node node;
struct user_namespace *ns;
kuid_t uid;
-   int count;
+   atomic_t count;
atomic_t ucount[UCOUNT_COUNTS];
 };
 
diff --git a/kernel/ucount.c b/kernel/ucount.c
index 11b1596e2542..0f2c7c11df19 100644
--- a/kernel/ucount.c
+++ b/kernel/ucount.c
@@ -141,7 +141,8 @@ static struct ucounts *get_ucounts(struct user_namespace 
*ns, kuid_t uid)
 
new->ns = ns;
new->uid = uid;
-   new->count = 0;
+
+   atomic_set(&new->count, 0);
 
spin_lock_irq(&ucounts_lock);
ucounts = find_ucounts(ns, uid, hashent);
@@ -152,10 +153,10 @@ static struct ucounts *get_ucounts(struct user_namespace 
*ns, kuid_t uid)
ucounts = new;
}
}
-   if (ucounts->count == INT_MAX)
+   if (atomic_read(&ucounts->count) == INT_MAX)
ucounts = NULL;
else
-   ucounts->count += 1;
+   atomic_inc(&ucounts->count);
spin_unlock_irq(&ucounts_lock);
return ucounts;
 }
@@ -165,8 +166,7 @@ static void put_ucounts(struct ucounts *ucounts)
unsigned long flags;
 
spin_lock_irqsave(&ucounts_lock, flags);
-   ucounts->count -= 1;
-   if (!ucounts->count)
+   if (atomic_dec_and_test(&ucounts->count))
hlist_del_init(&ucounts->node);
else
ucounts = NULL;
-- 
2.29.2

[RFC PATCH v2 4/8] Move RLIMIT_NPROC counter to ucounts

[Alexey Gladkov]

RLIMIT_NPROC is implemented on top of ucounts. The process counter is
tied to the user in the user namespace. Therefore, there is no longer
one single counter for the user. Instead, there is now one counter for
each user namespace. Thus, getting the RLIMIT_NPROC counter value to
check the rlimit becomes meaningless.

We cannot use existing inc_ucounts / dec_ucounts because they do not
allow us to exceed the maximum for the counter. Some rlimits can be
overlimited if the user has the appropriate capability.

Signed-off-by: Alexey Gladkov 
---
 fs/exec.c  |  2 +-
 fs/io-wq.c | 22 ++---
 fs/io-wq.h |  2 +-
 fs/io_uring.c  |  2 +-
 include/linux/cred.h   |  2 ++
 include/linux/sched/user.h |  1 -
 include/linux/user_namespace.h | 13 
 kernel/cred.c  | 10 +++---
 kernel/exit.c  |  2 +-
 kernel/fork.c  |  9 ++---
 kernel/sys.c   |  2 +-
 kernel/ucount.c| 60 ++
 kernel/user.c  |  1 -
 kernel/user_namespace.c|  3 +-
 14 files changed, 102 insertions(+), 29 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 5d4d52039105..f62fd2632104 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1870,7 +1870,7 @@ static int do_execveat_common(int fd, struct filename 
*filename,
 * whether NPROC limit is still exceeded.
 */
if ((current->flags & PF_NPROC_EXCEEDED) &&
-   atomic_read(¤t_user()->processes) > rlimit(RLIMIT_NPROC)) {
+   is_ucounts_overlimit(current_ucounts(), UCOUNT_RLIMIT_NPROC, 
rlimit(RLIMIT_NPROC))) {
retval = -EAGAIN;
goto out_ret;
}
diff --git a/fs/io-wq.c b/fs/io-wq.c
index a564f36e260c..5b6940c90c61 100644
--- a/fs/io-wq.c
+++ b/fs/io-wq.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../kernel/sched/sched.h"
 #include "io-wq.h"
@@ -120,7 +121,7 @@ struct io_wq {
io_wq_work_fn *do_work;
 
struct task_struct *manager;
-   struct user_struct *user;
+   const struct cred *cred;
refcount_t refs;
struct completion done;
 
@@ -234,7 +235,7 @@ static void io_worker_exit(struct io_worker *worker)
if (worker->flags & IO_WORKER_F_RUNNING)
atomic_dec(&acct->nr_running);
if (!(worker->flags & IO_WORKER_F_BOUND))
-   atomic_dec(&wqe->wq->user->processes);
+   dec_rlimit_ucounts(wqe->wq->cred->ucounts, UCOUNT_RLIMIT_NPROC, 
1);
worker->flags = 0;
preempt_enable();
 
@@ -364,15 +365,15 @@ static void __io_worker_busy(struct io_wqe *wqe, struct 
io_worker *worker,
worker->flags |= IO_WORKER_F_BOUND;
wqe->acct[IO_WQ_ACCT_UNBOUND].nr_workers--;
wqe->acct[IO_WQ_ACCT_BOUND].nr_workers++;
-   atomic_dec(&wqe->wq->user->processes);
+   dec_rlimit_ucounts(wqe->wq->cred->ucounts, 
UCOUNT_RLIMIT_NPROC, 1);
} else {
worker->flags &= ~IO_WORKER_F_BOUND;
wqe->acct[IO_WQ_ACCT_UNBOUND].nr_workers++;
wqe->acct[IO_WQ_ACCT_BOUND].nr_workers--;
-   atomic_inc(&wqe->wq->user->processes);
+   inc_rlimit_ucounts(wqe->wq->cred->ucounts, 
UCOUNT_RLIMIT_NPROC, 1);
}
io_wqe_inc_running(wqe, worker);
-}
+   }
 }
 
 /*
@@ -707,7 +708,7 @@ static bool create_io_worker(struct io_wq *wq, struct 
io_wqe *wqe, int index)
raw_spin_unlock_irq(&wqe->lock);
 
if (index == IO_WQ_ACCT_UNBOUND)
-   atomic_inc(&wq->user->processes);
+   inc_rlimit_ucounts(wq->cred->ucounts, UCOUNT_RLIMIT_NPROC, 1);
 
refcount_inc(&wq->refs);
wake_up_process(worker->task);
@@ -838,7 +839,7 @@ static bool io_wq_can_queue(struct io_wqe *wqe, struct 
io_wqe_acct *acct,
if (free_worker)
return true;
 
-   if (atomic_read(&wqe->wq->user->processes) >= acct->max_workers &&
+   if (is_ucounts_overlimit(wqe->wq->cred->ucounts, UCOUNT_RLIMIT_NPROC, 
acct->max_workers) &&
!(capable(CAP_SYS_RESOURCE) || capable(CAP_SYS_ADMIN)))
return false;
 
@@ -1074,7 +1075,7 @@ struct io_wq *io_wq_create(unsigned bounded, struct 
io_wq_data *data)
wq->do_work = data->do_work;
 
/* caller must already hold a reference to this */
-   wq->user = data->user;
+   wq->cred = data->cred;
 
ret = -ENOMEM;
for_each_node(node) {
@@ -1090,10 +1091,7 @@ struct io_wq *io_wq_create(unsigned bounded, struct 
io_wq_data *data)
wqe->node = alloc_node;
wqe->acct[IO_WQ_ACCT_BOUND].max_workers = bounded;
atomic_set(&wqe->acct[IO_WQ_ACCT_BOUND].nr_running, 0);
-   if (wq->user) {
-   

[RFC PATCH v2 3/8] Increase size of ucounts to atomic_long_t

[Alexey Gladkov]

This commit is preparation for migrating rlimits counters to ucounts.

Signed-off-by: Alexey Gladkov 
---
 include/linux/user_namespace.h |  4 ++--
 kernel/ucount.c| 14 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 483568a56f7f..24b850c7b70e 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -85,7 +85,7 @@ struct user_namespace {
struct ctl_table_header *sysctls;
 #endif
struct ucounts  *ucounts;
-   int ucount_max[UCOUNT_COUNTS];
+   long ucount_max[UCOUNT_COUNTS];
 } __randomize_layout;
 
 struct ucounts {
@@ -93,7 +93,7 @@ struct ucounts {
struct user_namespace *ns;
kuid_t uid;
atomic_t count;
-   atomic_t ucount[UCOUNT_COUNTS];
+   atomic_long_t ucount[UCOUNT_COUNTS];
 };
 
 extern struct user_namespace init_user_ns;
diff --git a/kernel/ucount.c b/kernel/ucount.c
index 80a39073bcef..4c5825ffd2e9 100644
--- a/kernel/ucount.c
+++ b/kernel/ucount.c
@@ -185,14 +185,14 @@ void set_cred_ucounts(const struct cred *cred, struct 
user_namespace *ns, kuid_t
((struct cred *) cred)->ucounts = get_ucounts(ns, uid);
 }
 
-static inline bool atomic_inc_below(atomic_t *v, int u)
+static inline bool atomic_long_inc_below(atomic_long_t *v, int u)
 {
-   int c, old;
-   c = atomic_read(v);
+   long c, old;
+   c = atomic_long_read(v);
for (;;) {
if (unlikely(c >= u))
return false;
-   old = atomic_cmpxchg(v, c, c+1);
+   old = atomic_long_cmpxchg(v, c, c+1);
if (likely(old == c))
return true;
c = old;
@@ -209,14 +209,14 @@ struct ucounts *inc_ucount(struct user_namespace *ns, 
kuid_t uid,
int max;
tns = iter->ns;
max = READ_ONCE(tns->ucount_max[type]);
-   if (!atomic_inc_below(&iter->ucount[type], max))
+   if (!atomic_long_inc_below(&iter->ucount[type], max))
goto fail;
}
return ucounts;
 fail:
bad = iter;
for (iter = ucounts; iter != bad; iter = iter->ns->ucounts)
-   atomic_dec(&iter->ucount[type]);
+   atomic_long_dec(&iter->ucount[type]);
 
put_ucounts(ucounts);
return NULL;
@@ -226,7 +226,7 @@ void dec_ucount(struct ucounts *ucounts, enum ucount_type 
type)
 {
struct ucounts *iter;
for (iter = ucounts; iter; iter = iter->ns->ucounts) {
-   int dec = atomic_dec_if_positive(&iter->ucount[type]);
+   int dec = atomic_long_dec_if_positive(&iter->ucount[type]);
WARN_ON_ONCE(dec < 0);
}
put_ucounts(ucounts);
-- 
2.29.2

[RFC PATCH v2 8/8] Move RLIMIT_NPROC check to the place where we increment the counter

[Alexey Gladkov]

After calling set_user(), we always have to call commit_creds() to apply
new credentials upon the current task. There is no need to separate
limit check and counter incrementing.

Signed-off-by: Alexey Gladkov 
---
 kernel/cred.c | 22 +-
 kernel/sys.c  | 13 -
 2 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/kernel/cred.c b/kernel/cred.c
index 89a945571533..770447b4f4de 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -488,14 +488,26 @@ int commit_creds(struct cred *new)
if (!gid_eq(new->fsgid, old->fsgid))
key_fsgid_changed(new);
 
-   /* do it
-* RLIMIT_NPROC limits on user->processes have already been checked
-* in set_user().
-*/
alter_cred_subscribers(new, 2);
if (new->user != old->user || new->user_ns != old->user_ns) {
+   bool overlimit;
+
set_cred_ucounts(new, new->user_ns, new->euid);
-   inc_rlimit_ucounts(new->ucounts, UCOUNT_RLIMIT_NPROC, 1);
+
+   overlimit = inc_rlimit_ucounts_and_test(new->ucounts, 
UCOUNT_RLIMIT_NPROC,
+   1, rlimit(RLIMIT_NPROC));
+
+   /*
+* We don't fail in case of NPROC limit excess here because too 
many
+* poorly written programs don't check set*uid() return code, 
assuming
+* it never fails if called by root.  We may still enforce 
NPROC limit
+* for programs doing set*uid()+execve() by harmlessly 
deferring the
+* failure to the execve() stage.
+*/
+   if (overlimit && new->user != INIT_USER)
+   current->flags |= PF_NPROC_EXCEEDED;
+   else
+   current->flags &= ~PF_NPROC_EXCEEDED;
}
rcu_assign_pointer(task->real_cred, new);
rcu_assign_pointer(task->cred, new);
diff --git a/kernel/sys.c b/kernel/sys.c
index c2734ab9474e..180c4e06064f 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -467,19 +467,6 @@ static int set_user(struct cred *new)
if (!new_user)
return -EAGAIN;
 
-   /*
-* We don't fail in case of NPROC limit excess here because too many
-* poorly written programs don't check set*uid() return code, assuming
-* it never fails if called by root.  We may still enforce NPROC limit
-* for programs doing set*uid()+execve() by harmlessly deferring the
-* failure to the execve() stage.
-*/
-   if (is_ucounts_overlimit(new->ucounts, UCOUNT_RLIMIT_NPROC, 
rlimit(RLIMIT_NPROC)) &&
-   new_user != INIT_USER)
-   current->flags |= PF_NPROC_EXCEEDED;
-   else
-   current->flags &= ~PF_NPROC_EXCEEDED;
-
free_uid(new->user);
new->user = new_user;
return 0;
-- 
2.29.2

RE: [EXT] Re: [PATCH RFC net-next 03/19] net: mvpp2: add CM3 SRAM memory map

[Stefan Chulski]

> 
> > > Should there be -EPROBE_DEFER handling in here somewhere? The SRAM
> > > is a device, so it might not of been probed yet?
> >
> 
> > No, firmware probed during bootloader boot and we can use SRAM. SRAM
> > memory can be safely used.
> 
> A previous patch added:
> 
> +   CP11X_LABEL(cm3_sram): cm3@22 {
> +   compatible = "mmio-sram";
> +   reg = <0x22 0x800>;
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges = <0 0x22 0x800>;
> +   };
> +
> 
> So it looks like the SRAM is a device, in the linux driver model. And there 
> is a
> driver for this, driver/misc/sram.c. How do you know this device has been
> probed before the Ethernet driver?
> 
>Andrew

You right, I would add EPROBE_DEFER if of_gen_pool_get return NULL.

Thanks.

Linux Kernel module notification bug

[Adam Zabrocki]

Hello,

I believe that the following commit does introduce a gentle "functionality 
bug":

"module: delay kobject uevent until after module init call":
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/kernel/module.c?id=38dc717e97153e46375ee21797aa54777e5498f3

The official Linux Kernel API for the kernel module activities notification has
been divided based on the readiness 'stage' for such module. We have the
following stages:

MODULE_STATE_LIVE,  /* Normal state. */
MODULE_STATE_COMING,/* Full formed, running module_init. */
MODULE_STATE_GOING, /* Going away. */
MODULE_STATE_UNFORMED,  /* Still setting it up. */

LIVE means that the kernel module is correctly running and all initialization
work has been already done. Otherwise, we have event 'COMING' or 'UNFORMED'.

In the described commit, creation of the KOBJECT has been moved after invoking
a notficiation of the newly formed kernel module state (LIVE). That's somehow
inconsistent from my understanding of the kernel modules notifiers logic.
Creation of the new objects (like KOBJ) should be done before notification of
the stage LIVE is invoked.

This commit breaks some of the projects that rely on the LIVE notification to
monitor when the newly loaded module is ready.

I believe that the latest time when 'kobject_uevent' function can be called is
just before invoking 'blocking_notifier_call_chain', e.g:

diff --git a/kernel/module.c b/kernel/module.c
index 4bf30e4b3eaa..7d56b1b07237 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3681,14 +3681,14 @@ static noinline int do_init_module(struct module *mod)
dump_stack();
}

+   /* Delay uevent until module has finished its init routine */
+   kobject_uevent(&mod->mkobj.kobj, KOBJ_ADD);
+
/* Now it's a first class citizen! */
mod->state = MODULE_STATE_LIVE;
blocking_notifier_call_chain(&module_notify_list,
 MODULE_STATE_LIVE, mod);

-   /* Delay uevent until module has finished its init routine */
-   kobject_uevent(&mod->mkobj.kobj, KOBJ_ADD);
-
/*
 * We need to finish all async code before the module init sequence
 * is done.  This has potential to deadlock.  For example, a newly

Thanks,
Adam

--
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl

[PATCH v4] driver core: Fix device link device name collision

[Saravana Kannan]

The device link device's name was of the form:
--

This can cause name collision as reported here [1] as device names are
not globally unique. Since device names have to be unique within the
bus/class, add the bus/class name as a prefix to the device names used to
construct the device link device name.

So the devuce link device's name will be of the form:
:--:

[1] - https://lore.kernel.org/lkml/20201229033440.32142-1-mich...@walle.cc/

Cc: sta...@vger.kernel.org
Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs")
Reported-by: Michael Walle 
Tested-by: Michael Walle 
Signed-off-by: Saravana Kannan 
---
v1:
- Fixed the collision in the device link device name.
v1 -> v2:
- Tried to fixed collision in the supplier: and consumer: symlinks
v2 -> v3:
- Fixed the truncation of the symlink names caused by v2.
v3 -> v4:
- Did all the above fixes for the symlink removal path.

 Documentation/ABI/testing/sysfs-class-devlink |  4 +--
 .../ABI/testing/sysfs-devices-consumer|  5 ++--
 .../ABI/testing/sysfs-devices-supplier|  5 ++--
 drivers/base/core.c   | 27 ++-
 include/linux/device.h| 12 +
 5 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-devlink 
b/Documentation/ABI/testing/sysfs-class-devlink
index b662f747c83e..8a21ce515f61 100644
--- a/Documentation/ABI/testing/sysfs-class-devlink
+++ b/Documentation/ABI/testing/sysfs-class-devlink
@@ -5,8 +5,8 @@ Description:
Provide a place in sysfs for the device link objects in the
kernel at any given time.  The name of a device link directory,
denoted as ... above, is of the form --
-   where  is the supplier device name and  is
-   the consumer device name.
+   where  is the supplier bus:device name and 
+   is the consumer bus:device name.
 
 What:  /sys/class/devlink/.../auto_remove_on
 Date:  May 2020
diff --git a/Documentation/ABI/testing/sysfs-devices-consumer 
b/Documentation/ABI/testing/sysfs-devices-consumer
index 1f06d74d1c3c..0809fda092e6 100644
--- a/Documentation/ABI/testing/sysfs-devices-consumer
+++ b/Documentation/ABI/testing/sysfs-devices-consumer
@@ -4,5 +4,6 @@ Contact:Saravana Kannan 
 Description:
The /sys/devices/.../consumer: are symlinks to device
links where this device is the supplier.  denotes the
-   name of the consumer in that device link. There can be zero or
-   more of these symlinks for a given device.
+   name of the consumer in that device link and is of the form
+   bus:device name. There can be zero or more of these symlinks
+   for a given device.
diff --git a/Documentation/ABI/testing/sysfs-devices-supplier 
b/Documentation/ABI/testing/sysfs-devices-supplier
index a919e0db5e90..207f5972e98d 100644
--- a/Documentation/ABI/testing/sysfs-devices-supplier
+++ b/Documentation/ABI/testing/sysfs-devices-supplier
@@ -4,5 +4,6 @@ Contact:Saravana Kannan 
 Description:
The /sys/devices/.../supplier: are symlinks to device
links where this device is the consumer.  denotes the
-   name of the supplier in that device link. There can be zero or
-   more of these symlinks for a given device.
+   name of the supplier in that device link and is of the form
+   bus:device name. There can be zero or more of these symlinks
+   for a given device.
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 25e08e5f40bd..47a6faf1605a 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -456,7 +456,9 @@ static int devlink_add_symlinks(struct device *dev,
struct device *con = link->consumer;
char *buf;
 
-   len = max(strlen(dev_name(sup)), strlen(dev_name(con)));
+   len = max(strlen(dev_bus_name(sup)) + strlen(dev_name(sup)),
+ strlen(dev_bus_name(con)) + strlen(dev_name(con)));
+   len += strlen(":");
len += strlen("supplier:") + 1;
buf = kzalloc(len, GFP_KERNEL);
if (!buf)
@@ -470,12 +472,12 @@ static int devlink_add_symlinks(struct device *dev,
if (ret)
goto err_con;
 
-   snprintf(buf, len, "consumer:%s", dev_name(con));
+   snprintf(buf, len, "consumer:%s:%s", dev_bus_name(con), dev_name(con));
ret = sysfs_create_link(&sup->kobj, &link->link_dev.kobj, buf);
if (ret)
goto err_con_dev;
 
-   snprintf(buf, len, "supplier:%s", dev_name(sup));
+   snprintf(buf, len, "supplier:%s:%s", dev_bus_name(sup), dev_name(sup));
ret = sysfs_create_link(&con->kobj, &link->link_dev.kobj, buf);
if (ret)
goto err_sup_dev;
@@ -483,7 +485,7 @@ static int devlink_add_symlinks(struct device *dev,
goto out;
 
 err_sup_dev:

Re: [PATCH RFC net-next 03/19] net: mvpp2: add CM3 SRAM memory map

[Russell King - ARM Linux admin]

On Sun, Jan 10, 2021 at 05:30:07PM +0200, stef...@marvell.com wrote:
> + } else {
> + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> + if (!priv->sram_pool) {
> + dev_warn(&pdev->dev, "DT is too old, TX FC disabled\n");

I don't see anything in this patch that disables TX flow control, which
means this warning message is misleading.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

RE: [EXT] Re: [PATCH RFC net-next 14/19] net: mvpp2: add ethtool flow control configuration support

[Stefan Chulski]

> > @@ -5373,6 +5402,30 @@ static int
> mvpp2_ethtool_set_pause_param(struct net_device *dev,
> >  struct ethtool_pauseparam *pause)  {
> > struct mvpp2_port *port = netdev_priv(dev);
> > +   int i;
> > +
> > +   if (pause->tx_pause && port->priv->global_tx_fc) {
> > +   port->tx_fc = true;
> > +   mvpp2_rxq_enable_fc(port);
> > +   if (port->priv->percpu_pools) {
> > +   for (i = 0; i < port->nrxqs; i++)
> > +   mvpp2_bm_pool_update_fc(port, &port-
> >priv->bm_pools[i], true);
> > +   } else {
> > +   mvpp2_bm_pool_update_fc(port, port->pool_long,
> true);
> > +   mvpp2_bm_pool_update_fc(port, port->pool_short,
> true);
> > +   }
> > +
> > +   } else if (port->priv->global_tx_fc) {
> > +   port->tx_fc = false;
> > +   mvpp2_rxq_disable_fc(port);
> > +   if (port->priv->percpu_pools) {
> > +   for (i = 0; i < port->nrxqs; i++)
> > +   mvpp2_bm_pool_update_fc(port, &port-
> >priv->bm_pools[i], false);
> > +   } else {
> > +   mvpp2_bm_pool_update_fc(port, port->pool_long,
> false);
> > +   mvpp2_bm_pool_update_fc(port, port->pool_short,
> false);
> > +   }
> > +   }
> 
> 
> This looks wrong. Flow control is normally the result of auto negotiation. 
> Both
> ends need to agree to it. Which is why
> mvpp2_ethtool_set_pause_param() passes the users request onto phylink.
> phylink will handle the autoneg and then ask the MAC to setup flow control
> depending on the result in mvpp2_mac_link_up().
> 
>   Andrew

Ok, I would move it to mvpp2_mac_link_up.

Stefan,
Thanks.

RE: [EXT] Re: [PATCH RFC net-next 03/19] net: mvpp2: add CM3 SRAM memory map

[Stefan Chulski]

> > +   } else {
> > +   priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > +   if (!priv->sram_pool) {
> > +   dev_warn(&pdev->dev, "DT is too old, TX FC
> disabled\n");
> 
> I don't see anything in this patch that disables TX flow control, which means
> this warning message is misleading.

OK, I would change to TX FC not supported.

Stefan.

Re: [PATCH 4/7] dt-bindings: regulator: qcom-labibb: Document soft start properties

[AngeloGioacchino Del Regno]

Il 10/01/21 18:18, Rob Herring ha scritto:

On Sat, 09 Jan 2021 14:29:18 +0100, AngeloGioacchino Del Regno wrote:

Document properties to configure soft start and discharge resistor
for LAB and IBB respectively.

Signed-off-by: AngeloGioacchino Del Regno 

---
  .../bindings/regulator/qcom-labibb-regulator.yaml | 8 
  1 file changed, 8 insertions(+)



My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml:
 properties:ibb:properties:qcom,discharge-resistor-kohms: 'oneOf' conditional 
failed, one must be fixed:
'type' is a required property
Additional properties are not allowed ('default', 'enum' were 
unexpected)
Additional properties are not allowed ('default' was unexpected)

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml:
 properties:ibb:properties:qcom,discharge-resistor-kohms: 'oneOf' conditional 
failed, one must be fixed:
'$ref' is a required property
'allOf' is a required property
300 is not of type 'string'
64 is not of type 'string'
32 is not of type 'string'
16 is not of type 'string'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml:
 ignoring, error in schema: properties: ibb: properties: 
qcom,discharge-resistor-kohms
warning: no schema found in file: 
./Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml

See https://patchwork.ozlabs.org/patch/1424112

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


Fixing ASAP.

Re: [EXT] Re: [PATCH RFC net-next 03/19] net: mvpp2: add CM3 SRAM memory map

[Andrew Lunn]

On Sun, Jan 10, 2021 at 05:57:14PM +, Stefan Chulski wrote:
> > > + } else {
> > > + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > > + if (!priv->sram_pool) {
> > > + dev_warn(&pdev->dev, "DT is too old, TX FC
> > disabled\n");
> > 
> > I don't see anything in this patch that disables TX flow control, which 
> > means
> > this warning message is misleading.
> 
> OK, I would change to TX FC not supported.

And you should tell phlylink, so it knows to disable it in autoneg.

Which make me wonder, do we need a fix for stable? Has flow control
never been support in this device up until these patches get merged?
It should not be negotiated if it is not supported, which means
telling phylink.

   Andrew

Re: [PATCH RFC net-next 11/19] net: mvpp2: add flow control RXQ and BM pool config callbacks

[Russell King - ARM Linux admin]

On Sun, Jan 10, 2021 at 05:30:15PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski 
> 
> This patch did not change any functionality.
> Added flow control RXQ and BM pool config callbacks that would be
> used to configure RXQ and BM pool thresholds.
> APIs also will disable/enable RXQ and pool Flow Control polling.
> 
> In this stage BM pool and RXQ has same stop/start thresholds
> defined in code.
> Also there are common thresholds for all RXQs.
> 
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h  |  51 +-
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 169 
>  2 files changed, 216 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index 4d58af6..0ba0598 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -763,10 +763,53 @@
>   ((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
>  
>  /* MSS Flow control */
> -#define MSS_SRAM_SIZE0x800
> -#define FC_QUANTA0x
> -#define FC_CLK_DIVIDER   0x140
> -#define MSS_THRESHOLD_STOP768
> +#define MSS_SRAM_SIZE0x800
> +#define MSS_FC_COM_REG   0
> +#define FLOW_CONTROL_ENABLE_BIT  BIT(0)
> +#define FLOW_CONTROL_UPDATE_COMMAND_BIT  BIT(31)
> +#define FC_QUANTA0x
> +#define FC_CLK_DIVIDER   0x140
> +
> +#define MSS_BUF_POOL_BASE0x40
> +#define MSS_BUF_POOL_OFFS4
> +#define MSS_BUF_POOL_REG(id) (MSS_BUF_POOL_BASE  \
> + + (id) * MSS_BUF_POOL_OFFS)
> +
> +#define MSS_BUF_POOL_STOP_MASK   0xFFF
> +#define MSS_BUF_POOL_START_MASK  (0xFFF << 
> MSS_BUF_POOL_START_OFFS)
> +#define MSS_BUF_POOL_START_OFFS  12
> +#define MSS_BUF_POOL_PORTS_MASK  (0xF << MSS_BUF_POOL_PORTS_OFFS)
> +#define MSS_BUF_POOL_PORTS_OFFS  24
> +#define MSS_BUF_POOL_PORT_OFFS(id)   (0x1 << \
> + ((id) + MSS_BUF_POOL_PORTS_OFFS))
> +
> +#define MSS_RXQ_TRESH_BASE   0x200
> +#define MSS_RXQ_TRESH_OFFS   4
> +#define MSS_RXQ_TRESH_REG(q, fq) (MSS_RXQ_TRESH_BASE + (((q) + (fq)) \
> + * MSS_RXQ_TRESH_OFFS))
> +
> +#define MSS_RXQ_TRESH_START_MASK 0x
> +#define MSS_RXQ_TRESH_STOP_MASK  (0x << 
> MSS_RXQ_TRESH_STOP_OFFS)
> +#define MSS_RXQ_TRESH_STOP_OFFS  16
> +
> +#define MSS_RXQ_ASS_BASE 0x80
> +#define MSS_RXQ_ASS_OFFS 4
> +#define MSS_RXQ_ASS_PER_REG  4
> +#define MSS_RXQ_ASS_PER_OFFS 8
> +#define MSS_RXQ_ASS_PORTID_OFFS  0
> +#define MSS_RXQ_ASS_PORTID_MASK  0x3
> +#define MSS_RXQ_ASS_HOSTID_OFFS  2
> +#define MSS_RXQ_ASS_HOSTID_MASK  0x3F
> +
> +#define MSS_RXQ_ASS_Q_BASE(q, fq) q) + (fq)) % MSS_RXQ_ASS_PER_REG)  
>  \
> +   * MSS_RXQ_ASS_PER_OFFS)
> +#define MSS_RXQ_ASS_PQ_BASE(q, fq) q) + (fq)) / MSS_RXQ_ASS_PER_REG) \
> +* MSS_RXQ_ASS_OFFS)
> +#define MSS_RXQ_ASS_REG(q, fq) (MSS_RXQ_ASS_BASE + MSS_RXQ_ASS_PQ_BASE(q, 
> fq))
> +
> +#define MSS_THRESHOLD_STOP   768
> +#define MSS_THRESHOLD_START  1024
> +
>  
>  /* RX buffer constants */
>  #define MVPP2_SKB_SHINFO_SIZE \
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index bc4b8069..19648c4 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -744,6 +744,175 @@ static void *mvpp2_buf_alloc(struct mvpp2_port *port,
>   return data;
>  }
>  
> +/* Routine calculate single queue shares address space */
> +static int mvpp22_calc_shared_addr_space(struct mvpp2_port *port)
> +{
> + /* If number of CPU's greater than number of threads, return last
> +  * address space
> +  */
> + if (num_active_cpus() >= MVPP2_MAX_THREADS)
> + return MVPP2_MAX_THREADS - 1;
> +
> + return num_active_cpus();

Firstly - this can be written as:

return min(num_active_cpus(), MVPP2_MAX_THREADS - 1);

Secondly - what if the number of active CPUs change, for example due
to hotplug activity. What if we boot with maxcpus=1 and then bring the
other CPUs online after networking has been started? The number of
active CPUs is dynamically managed via the scheduler as CPUs are
brought online or offline.

> +/* Routine enable flow control for RXQs conditon */
> +void mvpp2_rxq_enable_fc(struct mvpp2_port *port)
...
> +/* Routine disable flow control for RXQs conditon */
> +void mvpp2_rxq_disable_fc(struct mvpp2_port *port)

Nothing seems to call these in this patch, so on its own, it's not
obvious how these are being called, and therefore what reme

Re: [PATCH RFC net-next 12/19] net: mvpp2: enable global flow control

[Russell King - ARM Linux admin]

On Sun, Jan 10, 2021 at 05:30:16PM +0200, stef...@marvell.com wrote:
> + /* Enable global Flow Control only if hanler to SRAM not NULL */

I think this comment needs fixing. I'm not sure what a "hanler" is,
and "handler" doesn't make sense here.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

RE: [EXT] Re: [PATCH RFC net-next 03/19] net: mvpp2: add CM3 SRAM memory map

[Stefan Chulski]

> > > > +   } else {
> > > > +   priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > > > +   if (!priv->sram_pool) {
> > > > +   dev_warn(&pdev->dev, "DT is too old, TX FC
> > > disabled\n");
> > >
> > > I don't see anything in this patch that disables TX flow control,
> > > which means this warning message is misleading.
> >
> > OK, I would change to TX FC not supported.
> 
> And you should tell phlylink, so it knows to disable it in autoneg.
> 
> Which make me wonder, do we need a fix for stable? Has flow control never
> been support in this device up until these patches get merged?
> It should not be negotiated if it is not supported, which means telling 
> phylink.
> 
>Andrew

TX FC never were really supported. MAC or PHY can negotiated flow control.
But MAC would never trigger FC frame.

Should I prepare separate patch that disable TX FC till we merge this patches?

Regards,
Stefan.

Re: Old platforms: bring out your dead

[Fabian Vogt]

Hi,

Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang  wrote:
> >
> > Hi Arnd,
> >
> > On 9 Jan 2021, at 9:55 am, Arnd Bergmann  wrote:
> >
> > * nspire -- added in 2013, no notable changes after 2015

Most of the platform is just the DT sources and some small drivers around it,
so it's actually fairly low maintenance. So far the migration away from
panel-simple in 2019
(https://lore.kernel.org/linux-arm-kernel/20190805085847.25554-1-linus.wall...@linaro.org)
was the biggest required change so far.

> > I believe this is still in active use. I’ve CC’d Fabian into this thread 
> > who’s
> > probably in a better position to respond to this.
> 
> Ok, moving it to the "keep around for now list" as well, to be on the
> safe side.

Thanks!

> Would either of you already have a guess for how long it makes
> sense to update kernels on it?
> 
> I see that this is one of the more limited platforms with just 32MB
> of RAM (64MB in case of CX), and kernels only get more bloated over
> time, so I expect at some point you will be stuck with running old
> software.

The kernel overhead isn't actually that bad. I just built today's 2ff90100ace8
and booted it with a busybox-based initrd. free -m reports:
total used free shared buffers
   58   12   46  0   0

Relatively speaking, still mostly unused ;-) The stock OS actually uses more!
With 32MiB, the situation is definitely worse, but still manageable. Should
that change in the future, dropping just the Classic/CM variants would be a
possible option, but that still seems far enough away.

> Wikipedia tells me that new models came out recently. Are you
> planning to add support for those as well?

Yes, someone from the community actually managed to boot Linux on a CX II-T,
and I'm hoping to get that upstreamed soon. Most of the hardware changes are
supported by drivers already and so this is mainly just another device tree.

Cheers,
Fabian

>   Arnd

Re: [PATCH RFC net-next 14/19] net: mvpp2: add ethtool flow control configuration support

[Russell King - ARM Linux admin]

On Sun, Jan 10, 2021 at 05:30:18PM +0200, stef...@marvell.com wrote:
> @@ -5373,6 +5402,30 @@ static int mvpp2_ethtool_set_pause_param(struct 
> net_device *dev,
>struct ethtool_pauseparam *pause)
>  {
>   struct mvpp2_port *port = netdev_priv(dev);
> + int i;
> +
> + if (pause->tx_pause && port->priv->global_tx_fc) {
> + port->tx_fc = true;
> + mvpp2_rxq_enable_fc(port);
> + if (port->priv->percpu_pools) {
> + for (i = 0; i < port->nrxqs; i++)
> + mvpp2_bm_pool_update_fc(port, 
> &port->priv->bm_pools[i], true);
> + } else {
> + mvpp2_bm_pool_update_fc(port, port->pool_long, true);
> + mvpp2_bm_pool_update_fc(port, port->pool_short, true);
> + }
> +
> + } else if (port->priv->global_tx_fc) {
> + port->tx_fc = false;
> + mvpp2_rxq_disable_fc(port);
> + if (port->priv->percpu_pools) {
> + for (i = 0; i < port->nrxqs; i++)
> + mvpp2_bm_pool_update_fc(port, 
> &port->priv->bm_pools[i], false);
> + } else {
> + mvpp2_bm_pool_update_fc(port, port->pool_long, false);
> + mvpp2_bm_pool_update_fc(port, port->pool_short, false);
> + }
> + }

This doesn't look correct to me. This function is only called when
ethtool -A is used to change the flow control settings. This is not
the place to be configuring flow control, as flow control is
negotiated with the link partner.

The final resolved flow control settings are available in
mvpp2_mac_link_up() via the tx_pause and rx_pause parameters.

What also concerns me is whether flow control is supported in the
existing driver at all, given this patch set. If it isn't supported
without the firmware's help, then we should _not_ be negotiating flow
control with the link partner unless we actually support it, so the
Pause and Asym_Pause bits in mvpp2_phylink_validate() should be
cleared.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH RFC net-next 00/19] net: mvpp2: Add TX Flow Control support

[Russell King - ARM Linux admin]

Hi,

On Sun, Jan 10, 2021 at 05:30:04PM +0200, stef...@marvell.com wrote:
> Armada hardware has a pause generation mechanism in GOP (MAC).
> GOP has to generate flow control frames based on an indication
> programmed in Ports Control 0 Register. There is a bit per port.
> However assertion of the PortX Pause bits in the ports control 0 register
> only sends a one time pause. To complement the function the GOP has
> a mechanism to periodically send pause control messages based on periodic 
> counters.
> This mechanism ensures that the pause is effective as long as the Appropriate 
> PortX Pause
> is asserted.

Can you ensure that your commit messages are consistently wrapped?
Some lines are wrapped others aren't.

> Problem is that Packet Processor witch actually can drop packets due to lack 
> of resources

Does the packet processor engage in magic or witchcraft? I suppose
some would argue that firmware does "magic"! However, I think you
mean "which". :)

> not connected to the GOP flow control generation mechanism.
> To solve this issue Armada has firmware running on CM3 CPU dedectated for 
> Flow Control
> support. Firmware monitors Packet Processor resources and asserts XON/XOFF by 
> writing
> to Ports Control 0 Register.

What is the minimum firmware version that supports this?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

RE: [EXT] Re: [PATCH RFC net-next 11/19] net: mvpp2: add flow control RXQ and BM pool config callbacks

[Stefan Chulski]

> >
> > +/* Routine calculate single queue shares address space */ static int
> > +mvpp22_calc_shared_addr_space(struct mvpp2_port *port) {
> > +   /* If number of CPU's greater than number of threads, return last
> > +* address space
> > +*/
> > +   if (num_active_cpus() >= MVPP2_MAX_THREADS)
> > +   return MVPP2_MAX_THREADS - 1;
> > +
> > +   return num_active_cpus();
> 
> Firstly - this can be written as:
> 
>   return min(num_active_cpus(), MVPP2_MAX_THREADS - 1);

OK.

> Secondly - what if the number of active CPUs change, for example due to
> hotplug activity. What if we boot with maxcpus=1 and then bring the other
> CPUs online after networking has been started? The number of active CPUs is
> dynamically managed via the scheduler as CPUs are brought online or offline.
> 
> > +/* Routine enable flow control for RXQs conditon */ void
> > +mvpp2_rxq_enable_fc(struct mvpp2_port *port)
> ...
> > +/* Routine disable flow control for RXQs conditon */ void
> > +mvpp2_rxq_disable_fc(struct mvpp2_port *port)
> 
> Nothing seems to call these in this patch, so on its own, it's not obvious how
> these are being called, and therefore what remedy to suggest for
> num_active_cpus().

I don't think that current driver support CPU hotplug, anyway I can remove  
num_active_cpus
and just use shared RX IRQ ID.

Thanks.
. 

Re: [EXT] Re: [PATCH RFC net-next 03/19] net: mvpp2: add CM3 SRAM memory map

[Russell King - ARM Linux admin]

On Sun, Jan 10, 2021 at 06:09:39PM +, Stefan Chulski wrote:
> > > > > + } else {
> > > > > + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > > > > + if (!priv->sram_pool) {
> > > > > + dev_warn(&pdev->dev, "DT is too old, TX FC
> > > > disabled\n");
> > > >
> > > > I don't see anything in this patch that disables TX flow control,
> > > > which means this warning message is misleading.
> > >
> > > OK, I would change to TX FC not supported.
> > 
> > And you should tell phlylink, so it knows to disable it in autoneg.
> > 
> > Which make me wonder, do we need a fix for stable? Has flow control never
> > been support in this device up until these patches get merged?
> > It should not be negotiated if it is not supported, which means telling 
> > phylink.
> > 
> >Andrew
> 
> TX FC never were really supported. MAC or PHY can negotiated flow control.
> But MAC would never trigger FC frame.

That really sucks.

> Should I prepare separate patch that disable TX FC till we merge this patches?

>From what I see in table 28B in 802.3, there is no way to advertise
that you only support RX flow control. If you advertise ASM_DIR=1
PAUSE=0, it basically means you support sending FC frames, but not
receiving them. Advertising anything with PAUSE=1 means you support
both sending and receiving FC frames, irrespective of the state of
ASM_DIR.

So, our only option would be to completely disable pause frames.
Yes, I think we need a separate patch for that for the net tree,
and it should be backported to stable kernels, IMHO.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

RE: [EXT] Re: [PATCH RFC net-next 14/19] net: mvpp2: add ethtool flow control configuration support

[Stefan Chulski]

> > @@ -5373,6 +5402,30 @@ static int
> mvpp2_ethtool_set_pause_param(struct net_device *dev,
> >  struct ethtool_pauseparam *pause)  {
> > struct mvpp2_port *port = netdev_priv(dev);
> > +   int i;
> > +
> > +   if (pause->tx_pause && port->priv->global_tx_fc) {
> > +   port->tx_fc = true;
> > +   mvpp2_rxq_enable_fc(port);
> > +   if (port->priv->percpu_pools) {
> > +   for (i = 0; i < port->nrxqs; i++)
> > +   mvpp2_bm_pool_update_fc(port, &port-
> >priv->bm_pools[i], true);
> > +   } else {
> > +   mvpp2_bm_pool_update_fc(port, port->pool_long,
> true);
> > +   mvpp2_bm_pool_update_fc(port, port->pool_short,
> true);
> > +   }
> > +
> > +   } else if (port->priv->global_tx_fc) {
> > +   port->tx_fc = false;
> > +   mvpp2_rxq_disable_fc(port);
> > +   if (port->priv->percpu_pools) {
> > +   for (i = 0; i < port->nrxqs; i++)
> > +   mvpp2_bm_pool_update_fc(port, &port-
> >priv->bm_pools[i], false);
> > +   } else {
> > +   mvpp2_bm_pool_update_fc(port, port->pool_long,
> false);
> > +   mvpp2_bm_pool_update_fc(port, port->pool_short,
> false);
> > +   }
> > +   }
> 
> This doesn't look correct to me. This function is only called when ethtool -A 
> is
> used to change the flow control settings. This is not the place to be
> configuring flow control, as flow control is negotiated with the link partner.
> 
> The final resolved flow control settings are available in
> mvpp2_mac_link_up() via the tx_pause and rx_pause parameters.

I would move this to mvpp2_mac_link_up.
Thanks.
 
> What also concerns me is whether flow control is supported in the existing
> driver at all, given this patch set. If it isn't supported without the 
> firmware's
> help, then we should _not_ be negotiating flow control with the link partner
> unless we actually support it, so the Pause and Asym_Pause bits in
> mvpp2_phylink_validate() should be cleared.

RX FC supported, issue only with TX FC.

Stefan,
Regards.

Re: [EXT] Re: [PATCH RFC net-next 11/19] net: mvpp2: add flow control RXQ and BM pool config callbacks

[Russell King - ARM Linux admin]

On Sun, Jan 10, 2021 at 06:24:30PM +, Stefan Chulski wrote:
> > >
> > > +/* Routine calculate single queue shares address space */ static int
> > > +mvpp22_calc_shared_addr_space(struct mvpp2_port *port) {
> > > + /* If number of CPU's greater than number of threads, return last
> > > +  * address space
> > > +  */
> > > + if (num_active_cpus() >= MVPP2_MAX_THREADS)
> > > + return MVPP2_MAX_THREADS - 1;
> > > +
> > > + return num_active_cpus();
> > 
> > Firstly - this can be written as:
> > 
> > return min(num_active_cpus(), MVPP2_MAX_THREADS - 1);
> 
> OK.
> 
> > Secondly - what if the number of active CPUs change, for example due to
> > hotplug activity. What if we boot with maxcpus=1 and then bring the other
> > CPUs online after networking has been started? The number of active CPUs is
> > dynamically managed via the scheduler as CPUs are brought online or offline.
> > 
> > > +/* Routine enable flow control for RXQs conditon */ void
> > > +mvpp2_rxq_enable_fc(struct mvpp2_port *port)
> > ...
> > > +/* Routine disable flow control for RXQs conditon */ void
> > > +mvpp2_rxq_disable_fc(struct mvpp2_port *port)
> > 
> > Nothing seems to call these in this patch, so on its own, it's not obvious 
> > how
> > these are being called, and therefore what remedy to suggest for
> > num_active_cpus().
> 
> I don't think that current driver support CPU hotplug, anyway I can
> remove  num_active_cpus and just use shared RX IRQ ID.

Sorry, but that is not really a decision the driver can make. It is
part of a kernel that _does_ support CPU hotplug, and the online
CPUs can be changed today.

It is likely that every distro out there builds the kernel with
CPU hotplug enabled.

If changing the online CPUs causes the driver to misbehave, that
is a(nother) bug with the driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [EXT] Re: [PATCH RFC net-next 14/19] net: mvpp2: add ethtool flow control configuration support

[Russell King - ARM Linux admin]

On Sun, Jan 10, 2021 at 06:27:57PM +, Stefan Chulski wrote:
> > What also concerns me is whether flow control is supported in the existing
> > driver at all, given this patch set. If it isn't supported without the 
> > firmware's
> > help, then we should _not_ be negotiating flow control with the link partner
> > unless we actually support it, so the Pause and Asym_Pause bits in
> > mvpp2_phylink_validate() should be cleared.
> 
> RX FC supported, issue only with TX FC.

That doesn't seem relevant given table 28B in IEEE 802.3. There is
no advertisement combination that allows one to advertise an ability
to receive FC frames but not transmit FC frames.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

[PATCH v6] ehci: fix EHCI host controller initialization sequence

[Eugene Korenevsky]

According to EHCI spec, EHCI HC clears USBSTS.HCHalted whenever
USBCMD.RS=1.

However, it is a good practice to wait some time after setting USBCMD.RS
(approximately 100ms) until USBSTS.HCHalted become zero.

Without this waiting, VirtualBox's EHCI virtual HC accidentally hangs
(see BugLink).

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211095 
Acked-by: Alan Stern 
Signed-off-by: Eugene Korenevsky 
---
v1: initial patch
v2: add BugLink tag
v3: add Revieved-By tags (incorrect), restore `msleep(5)`
v4: remove Reviewed-By tags, restore reading from USBCMD prior to msleep,
adjust description
v5: add `patch changelog`
v6: add `Acked-by: Alan Stern ` tag

 drivers/usb/host/ehci-hcd.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index e358ae17d51e..1926b328b6aa 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -574,6 +574,7 @@ static int ehci_run (struct usb_hcd *hcd)
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 temp;
u32 hcc_params;
+   int rc;
 
hcd->uses_new_polling = 1;
 
@@ -629,9 +630,20 @@ static int ehci_run (struct usb_hcd *hcd)
down_write(&ehci_cf_port_reset_rwsem);
ehci->rh_state = EHCI_RH_RUNNING;
ehci_writel(ehci, FLAG_CF, &ehci->regs->configured_flag);
+
+   /* Wait until HC become operational */
ehci_readl(ehci, &ehci->regs->command); /* unblock posted writes */
msleep(5);
+   rc = ehci_handshake(ehci, &ehci->regs->status, STS_HALT, 0, 100 * 1000);
+
up_write(&ehci_cf_port_reset_rwsem);
+
+   if (rc) {
+   ehci_err(ehci, "USB %x.%x, controller refused to start: %d\n",
+((ehci->sbrn & 0xf0)>>4), (ehci->sbrn & 0x0f), rc);
+   return rc;
+   }
+
ehci->last_periodic_enable = ktime_get_real();
 
temp = HC_VERSION(ehci, ehci_readl(ehci, &ehci->caps->hc_capbase));
-- 
2.20.1

RE: [EXT] Re: [PATCH RFC net-next 11/19] net: mvpp2: add flow control RXQ and BM pool config callbacks

[Stefan Chulski]

> Sorry, but that is not really a decision the driver can make. It is part of a 
> kernel
> that _does_ support CPU hotplug, and the online CPUs can be changed today.
> 
> It is likely that every distro out there builds the kernel with CPU hotplug
> enabled.
> 
> If changing the online CPUs causes the driver to misbehave, that is a(nother)
> bug with the driver.

This function doesn't really need to know num_active_cpus, only host ID used by
used by shared RX interrupt in single queue mode.
Host ID is just register address space used to access PPv2 register space.
So I can remove this use of  num_active_cpus.

Stefan,
Regards.

Malicious fs images was Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps

[Pavel Machek]

Hi!

On Fri 2020-10-09 10:37:32, Theodore Y. Ts'o wrote:
> On Thu, Oct 08, 2020 at 03:22:59PM -0700, Josh Triplett wrote:
> > 
> > I wasn't trying to make a *new* general principle or policy. I was under
> > the impression that this *was* the policy, because it never occurred to
> > me that it could be otherwise. It seemed like a natural aspect of the
> > kernel/userspace boundary, to the point that the idea of it *not* being
> > part of the kernel's stability guarantees didn't cross my mind. 
> 
> >From our perspective (and Darrick and I discussed this on this week's
> ext4 video conference, so it represents the ext4 and xfs maintainer's
> position) is that the file system format is different.  First, the
> on-disk format is not an ABI, and it is several orders more complex
> than a system call interface.  Second, we make no guarantees about
> what the file system created by malicious tools will do.  For example,
> XFS developers reject bug reports from file system fuzzers, because
> the v5 format has CRC checks, so randomly corrupted file systems won't
> crash the kernel.  Yes, this doesn't protect against maliciously
> created file systems where the attacker makes sure the checksums are
> valid, but only crazy people who think containers are just as secure

Well, it is not just containers. It is also USB sticks. And people who
believe secure boot is good idea and try to protect kernel against
root. And crazy people who encrypt pointers in dmesg. And...

People want to use USB sticks from time to time. And while I
understand XFS is so complex it is unsuitable for such use, I'd still
expect bugs to be fixed there.

I hope VFAT to be safe to mount, because that is very common on USB.

I also hope ext2/3/4 is safe in that regard.

Anyway it would be nice to have documentation explaining this. If I'm
wrong about VFAT being safe, it would be good to know, and I guess
many will be surprised that XFS is using different rules.

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

Re: [RFC PATCH v2 0/8] Count rlimits in each user namespace

[Linus Torvalds]

On Sun, Jan 10, 2021 at 9:34 AM Alexey Gladkov  wrote:
>
> To address the problem, we bind rlimit counters to each user namespace. The
> result is a tree of rlimit counters with the biggest value at the root (aka
> init_user_ns). The rlimit counter increment/decrement occurs in the current 
> and
> all parent user namespaces.

I'm not seeing why this is necessary.

Maybe it's the right approach, but none of the patches (or this cover
letter email) really explain it to me.

I understand why you might want the _limits_ themselves would form a
tree like this - with the "master limit" limiting the limits in the
user namespaces under it.

But I don't understand why the _counts_ should do that. The 'struct
user_struct' should be shared across even user namespaces for the same
user.

IOW, the very example of the problem you quote seems to argue against this:

> For example, there are two containers (A and B) created by one user. The
> container A sets RLIMIT_NPROC=1 and starts one process. Everything is fine, 
> but
> when container B tries to do the same it will fail because the number of
> processes is counted globally for each user and user has one process already.

Note how the problem was _not_ that the _count_ was global. That part
was fine and all good.

No, the problem was that the _limit_ in container A also ended up
affecting container B.

So to me, that says that it would make sense to continue to use the
resource counts in 'struct user_struct' (because if user A has a hard
limit of X, then creating a new namespace shouldn't expand that
limit), but then have the ability to make per-container changes to the
resource limits (as long as they are within the bounds of the parent
user namespace resource limit).

Maybe there is some reason for this ucounts approach, but if so, I
feel it was not explained at all.

 Linus

Re: Aw: [PATCH v2 3/3] regulator: mt6323: Add OF match table

[Matthias Brugger]

On 09/01/2021 17:44, Frank Wunderlich wrote:
> Hi
> 
>> Gesendet: Samstag, 09. Januar 2021 um 12:26 Uhr
>> Von: matthias@kernel.org
> 
>> Changes in v2:
>> - check for CONFIG_OF
>> - add Fixes tag
> 
>> --- a/drivers/regulator/mt6323-regulator.c
>> +++ b/drivers/regulator/mt6323-regulator.c
>> @@ -406,9 +406,18 @@ static const struct platform_device_id 
>> mt6323_platform_ids[] = {
>>  };
>>  MODULE_DEVICE_TABLE(platform, mt6323_platform_ids);
>>
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id mt6323_of_match[] = {
>> +{ .compatible = "mediatek,mt6323-regulator", },
>> +{ /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, mt6323_of_match);
>> +#endif
>> +
>>  static struct platform_driver mt6323_regulator_driver = {
>>  .driver = {
>>  .name = "mt6323-regulator",
>> +.of_match_table = of_match_ptr(mt6323_of_match),
> 
> imho check for CONFIG_OF is here needed too, else mt6323_of_match is 
> referenced but undefined
> 

No, of_match_ptr already takes care of this:
https://elixir.bootlin.com/linux/latest/source/include/linux/of.h#L998

Regards,
Matthias

[GIT PULL] ARC fixes for 5.11-rc3

[Vineet Gupta]

Hi Linus,

I ran into boot failures on ARC, which went unnoticed. This pull request 
addresses that.

Thx,
-Vineet
-->
The following changes since commit f6e7a024bfe5e11d91ccff46bb576e3fb5a516ea:

   Merge tag 'arc-5.11-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2021-01-05 
12:46:27 -0800)

are available in the Git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ 
tags/arc-5.11-rc3-fixes

for you to fetch changes up to e8deee4f1543eda9b75278f63322f412cad52f6a:

   ARC: [hsdk]: Enable FPU_SAVE_RESTORE (2021-01-08 13:46:58 -0800)


ARC fixes for 5.11-rc3

  - Address the 2nd boot failure due to snafu in signal handling code
(first was generic console ttynull issue)

  - miscll other fixes


Randy Dunlap (1):
   arch/arc: add copy_user_page() to  to fix build error 
on ARC

Vineet Gupta (3):
   include/soc: remove headers for EZChip NPS
   ARC: unbork 5.11 bootup: fix snafu in _TIF_NOTIFY_SIGNAL handling
   ARC: [hsdk]: Enable FPU_SAVE_RESTORE

  arch/arc/include/asm/page.h |   1 +
  arch/arc/kernel/entry.S |   2 +-
  arch/arc/plat-hsdk/Kconfig  |   1 +
  include/soc/nps/common.h| 172 

  include/soc/nps/mtm.h   |  59 ---
  5 files changed, 3 insertions(+), 232 deletions(-)
  delete mode 100644 include/soc/nps/common.h
  delete mode 100644 include/soc/nps/mtm.h

[PATCH] scripts: mod: fix checkpatch.pl warnings

[Dwaipayan Ray]

Fix the following warnings in file2alias reported by
checkpatch:

CHECK: spaces preferred around that '*' (ctx:WxV)
CHECK: spaces preferred around that '+' (ctx:VxV)
CHECK: spaces preferred around that '-' (ctx:VxV)
CHECK: spaces preferred around that '&' (ctx:VxV)
CHECK: braces {} should be used on all arms of this statement
CHECK: Unbalanced braces around else statement
CHECK: Alignment should match open parenthesis
CHECK: Logical continuations should be on the previous line
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: Missing a blank line after declarations
WARNING: please, no spaces at the start of a line
WARNING: Block comments use a trailing */ on a separate line
ERROR: spaces required around that '<' (ctx:VxV)
ERROR: spaces required around that '=' (ctx:VxV)
ERROR: space required after that ',' (ctx:VxV)
ERROR: space prohibited before that close parenthesis ')'
ERROR: code indent should use tabs where possible
ERROR: "(foo*)" should be "(foo *)"

Signed-off-by: Dwaipayan Ray 
---

Note: The patch is compile tested only

 scripts/mod/file2alias.c | 156 +--
 1 file changed, 83 insertions(+), 73 deletions(-)

diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index fb4827027536..4a87c5f42339 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -14,7 +14,8 @@
 #include "devicetable-offsets.h"
 
 /* We use the ELF typedefs for kernel_ulong_t but bite the bullet and
- * use either stdint.h or inttypes.h for the rest. */
+ * use either stdint.h or inttypes.h for the rest.
+ */
 #if KERNEL_ELFCLASS == ELFCLASS32
 typedef Elf32_Addr kernel_ulong_t;
 #define BITS_PER_LONG 32
@@ -49,7 +50,8 @@ typedef struct {
 
 /* Big exception to the "don't include kernel headers into userspace, which
  * even potentially has different endianness and word sizes, since
- * we handle those differences explicitly below */
+ * we handle those differences explicitly below
+ */
 #include "../../include/linux/mod_devicetable.h"
 
 /* This array collects all instances that use the generic do_table */
@@ -84,16 +86,16 @@ struct devtable {
 
 #define ADD(str, sep, cond, field)  \
 do {\
-strcat(str, sep);   \
-if (cond)   \
-sprintf(str + strlen(str),  \
-sizeof(field) == 1 ? "%02X" :   \
-sizeof(field) == 2 ? "%04X" :   \
-sizeof(field) == 4 ? "%08X" : "",   \
-field); \
-else\
-sprintf(str + strlen(str), "*");\
-} while(0)
+   strcat(str, sep);   \
+   if (cond)   \
+   sprintf(str + strlen(str),  \
+   sizeof(field) == 1 ? "%02X" :   \
+   sizeof(field) == 2 ? "%04X" :   \
+   sizeof(field) == 4 ? "%08X" : "",   \
+   field); \
+   else\
+   sprintf(str + strlen(str), "*");\
+} while (0)
 
 /* End in a wildcard, for future extension */
 static inline void add_wildcard(char *str)
@@ -137,15 +139,15 @@ static void device_id_check(const char *modname, const 
char *device_id,
  modname, device_id, id_size, device_id, size, device_id);
}
/* Verify last one is a terminator */
-   for (i = 0; i < id_size; i++ ) {
-   if (*(uint8_t*)(symval+size-id_size+i)) {
-   fprintf(stderr,"%s: struct %s_device_id is %lu bytes.  "
+   for (i = 0; i < id_size; i++) {
+   if (*(uint8_t *)(symval + size - id_size + i)) {
+   fprintf(stderr, "%s: struct %s_device_id is %lu bytes.  
"
"The last of %lu is:\n",
modname, device_id, id_size, size / id_size);
-   for (i = 0; i < id_size; i++ )
-   fprintf(stderr,"0x%02x ",
-   *(uint8_t*)(symval+size-id_size+i) );
-   fprintf(stderr,"\n");
+   for (i = 0; i < id_size; i++)
+   fprintf(stderr, "0x%02x ",
+   *(uint8_t *)(symval + size - id_size + 
i));
+   fprintf(stderr, "\n");
fatal("%s: struct %s_device_id is not terminated "
"with a NULL entry!\n", modname, device_id);
}
@@ -160,6 +162,7 @@ 

RE: [EXT] Re: [PATCH RFC net-next 00/19] net: mvpp2: Add TX Flow Control support

[Stefan Chulski]

> > not connected to the GOP flow control generation mechanism.
> > To solve this issue Armada has firmware running on CM3 CPU dedectated
> > for Flow Control support. Firmware monitors Packet Processor resources
> > and asserts XON/XOFF by writing to Ports Control 0 Register.
> 
> What is the minimum firmware version that supports this?
> 

Support were added to firmware about two years ago. 
All releases from 18.09 should has it.

Stefan,
Regards.

[PATCH] ARM: dts: qcom: msm8974-klte: Fix shdc numbering

[Alexey Minnekhanov]

Since commit fa2d0aa96941 ("mmc: core: Allow setting slot index
via device tree alias") proper aliases should be named "mmcN".

Signed-off-by: Alexey Minnekhanov 
---
 arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts 
b/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
index 97352de9131422..f23d1002b8f8b9 100644
--- a/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
@@ -12,8 +12,8 @@ / {
 
aliases {
serial0 = &blsp1_uart1;
-   sdhc1 = &sdhc_1; /* SDC1 eMMC slot */
-   sdhc2 = &sdhc_2; /* SDC2 SD card slot */
+   mmc0 = &sdhc_1; /* SDC1 eMMC slot */
+   mmc1 = &sdhc_2; /* SDC2 SD card slot */
};
 
chosen {
-- 
2.26.2

Re: [EXT] Re: [PATCH RFC net-next 00/19] net: mvpp2: Add TX Flow Control support

[Russell King - ARM Linux admin]

On Sun, Jan 10, 2021 at 06:55:11PM +, Stefan Chulski wrote:
> > > not connected to the GOP flow control generation mechanism.
> > > To solve this issue Armada has firmware running on CM3 CPU dedectated
> > > for Flow Control support. Firmware monitors Packet Processor resources
> > > and asserts XON/XOFF by writing to Ports Control 0 Register.
> > 
> > What is the minimum firmware version that supports this?
> > 
> 
> Support were added to firmware about two years ago. 
> All releases from 18.09 should has it.

Please add that vital bit of information somewhere appropriate.
I would not be surprised if people are still running e.g. 17.10
on some of their Armada 8040 boards. My Macchiatobin which is
acting as a server currently has 17.10, although I plan to upgrade
it to 18.12 in about three to six months time, once I've well and
truely proven that my ext4 problems are resolved.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH resend v13 5/5] leds: mt6360: Add LED driver for MT6360

[Jacek Anaszewski]

Hi Gene,

On 12/24/20 2:47 AM, Gene Chen wrote:

From: Gene Chen 

Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode,
3-channel RGB LED support Register/Flash/Breath Mode, and 1-channel for
moonlight LED.



You can carry my ack also for patches 4/5 and 5/5:

Acked-by: Jacek Anaszewski 

--
Best regards,
Jacek Anaszewski

[PATCH 1/5] Input: omap4-keypad - disable unused long interrupts

[Tony Lindgren]

We are not using the long events and they produce extra interrupts.
Let's not enable them at all.

Note that also the v3.0.8 Linux Android kernel has long interrupts
disabled.

Cc: Arthur Demchenkov 
Cc: Carl Philipp Klemm 
Cc: Merlijn Wajer 
Cc: Pavel Machek 
Cc: ruleh 
Cc: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---
 drivers/input/keyboard/omap4-keypad.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/input/keyboard/omap4-keypad.c 
b/drivers/input/keyboard/omap4-keypad.c
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -176,10 +176,9 @@ static int omap4_keypad_open(struct input_dev *input)
kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
 kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS));
kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
-   OMAP4_DEF_IRQENABLE_EVENTEN |
-   OMAP4_DEF_IRQENABLE_LONGKEY);
+   OMAP4_DEF_IRQENABLE_EVENTEN);
kbd_writel(keypad_data, OMAP4_KBD_WAKEUPENABLE,
-   OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA);
+   OMAP4_DEF_WUP_EVENT_ENA);
 
enable_irq(keypad_data->irq);
 
-- 
2.30.0

[PATCHv5 0/5] Lost key-up interrupt handling for omap4-keypad

[Tony Lindgren]

Hi,

This series updates omap4-keypad to disable unused long interrupts, and
implements the missing parts for the lost key-up interrupt quirk as
described in the silicon errata pdf.

These are based on Linux next with the following pending patch applied:

"Input: omap4-keypad - switch to use managed resources"

Regards,

Tony


Changes since v4:

- Rebase on Dmitry's devm patch

- Fix up kernel test robot warnings and mismerge of pm_ops when
  I rebased from v5.10 to Linux next

- Split up the patches further as suggested by Dmitry

Changes since v3:

- Use PM runtime to check the last pressed key is not stuck

- Simplify probe with devm

Changes since v2:

- Drop bogus level change, that already comes from device tree

- Scan keyboard in two phases and simplify using a bitmask

- Use mod_delayed_work and cancel_delayed_work_sync for the quirk

Tony Lindgren (5):
  Input: omap4-keypad - disable unused long interrupts
  Input: omap4-keypad - scan keys in two phases and simplify with
bitmask
  Input: omap4-keypad - move rest of key scanning to a separate function
  Input: omap4-keypad - use PM runtime autosuspend
  Input: omap4-keypad - implement errata check for lost key-up events

 drivers/input/keyboard/omap4-keypad.c | 172 --
 1 file changed, 132 insertions(+), 40 deletions(-)

-- 
2.30.0

[GIT PULL] SCSI fixes for 5.11-rc2

[James Bottomley]

This is two driver fixes (megaraid_sas and hisi_sas).  The megaraid one
is a revert of a previous revert of a cpu hotplug fix which exposed a
bug in the block layer which has been fixed in this merge window and
the hisi_sas performance enhancement comes from switching to interrupt
managed completion queues, which depended on the addition of
devm_platform_get_irqs_affinity() which is now upstream via the irq
tree in the last merge window.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

  scsi: hisi_sas: Expose HW queues for v2 hw

Martin K. Petersen (1):
  Revert "Revert "scsi: megaraid_sas: Added support for shared host tagset 
for cpuhotplug""

And the diffstat:

 drivers/scsi/hisi_sas/hisi_sas.h|  4 ++
 drivers/scsi/hisi_sas/hisi_sas_main.c   | 11 +
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c  | 66 +++--
 drivers/scsi/megaraid/megaraid_sas_base.c   | 39 +
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 29 +++--
 5 files changed, 123 insertions(+), 26 deletions(-)

With full diff below.

James

---

diff --git a/drivers/scsi/hisi_sas/hisi_sas.h b/drivers/scsi/hisi_sas/hisi_sas.h
index 2b28dd405600..e821dd32dd28 100644
--- a/drivers/scsi/hisi_sas/hisi_sas.h
+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -294,6 +295,7 @@ enum {
 
 struct hisi_sas_hw {
int (*hw_init)(struct hisi_hba *hisi_hba);
+   int (*interrupt_preinit)(struct hisi_hba *hisi_hba);
void (*setup_itct)(struct hisi_hba *hisi_hba,
   struct hisi_sas_device *device);
int (*slot_index_alloc)(struct hisi_hba *hisi_hba,
@@ -393,6 +395,8 @@ struct hisi_hba {
u32 refclk_frequency_mhz;
u8 sas_addr[SAS_ADDR_SIZE];
 
+   int *irq_map; /* v2 hw */
+
int n_phy;
spinlock_t lock;
struct semaphore sem;
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index b6d4419c32f2..cf0bfac920a8 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -2614,6 +2614,13 @@ static struct Scsi_Host *hisi_sas_shost_alloc(struct 
platform_device *pdev,
return NULL;
 }
 
+static int hisi_sas_interrupt_preinit(struct hisi_hba *hisi_hba)
+{
+   if (hisi_hba->hw->interrupt_preinit)
+   return hisi_hba->hw->interrupt_preinit(hisi_hba);
+   return 0;
+}
+
 int hisi_sas_probe(struct platform_device *pdev,
   const struct hisi_sas_hw *hw)
 {
@@ -2671,6 +2678,10 @@ int hisi_sas_probe(struct platform_device *pdev,
sha->sas_port[i] = &hisi_hba->port[i].sas_port;
}
 
+   rc = hisi_sas_interrupt_preinit(hisi_hba);
+   if (rc)
+   goto err_out_ha;
+
rc = scsi_add_host(shost, &pdev->dev);
if (rc)
goto err_out_ha;
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index b57177b52fac..9adfdefef9ca 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -3302,6 +3302,28 @@ static irq_handler_t 
fatal_interrupts[HISI_SAS_FATAL_INT_NR] = {
fatal_axi_int_v2_hw
 };
 
+#define CQ0_IRQ_INDEX (96)
+
+static int hisi_sas_v2_interrupt_preinit(struct hisi_hba *hisi_hba)
+{
+   struct platform_device *pdev = hisi_hba->platform_dev;
+   struct Scsi_Host *shost = hisi_hba->shost;
+   struct irq_affinity desc = {
+   .pre_vectors = CQ0_IRQ_INDEX,
+   .post_vectors = 16,
+   };
+   int resv = desc.pre_vectors + desc.post_vectors, minvec = resv + 1, 
nvec;
+
+   nvec = devm_platform_get_irqs_affinity(pdev, &desc, minvec, 128,
+  &hisi_hba->irq_map);
+   if (nvec < 0)
+   return nvec;
+
+   shost->nr_hw_queues = hisi_hba->cq_nvecs = nvec - resv;
+
+   return 0;
+}
+
 /*
  * There is a limitation in the hip06 chipset that we need
  * to map in all mbigen interrupts, even if they are not used.
@@ -3310,14 +3332,11 @@ static int interrupt_init_v2_hw(struct hisi_hba 
*hisi_hba)
 {
struct platform_device *pdev = hisi_hba->platform_dev;
struct device *dev = &pdev->dev;
-   int irq, rc = 0, irq_map[128];
+   int irq, rc = 0;
int i, phy_no, fatal_no, queue_no;
 
-   for (i = 0; i < 128; i++)
-   irq_map[i] = platform_get_irq(pdev, i);
-
for (i = 0; i < HISI_SAS_PHY_INT_NR; i++) {
-   irq = irq_map[i + 1]; /* Phy up/down is irq1 */
+   irq = hisi_hba->irq_map[i + 1]; /* Phy up/down is irq1 */
rc = devm_request_irq(dev, irq, phy_interrupts[i], 0,
  DRV_NAME " phy", hisi_hba);
if (rc) {
@@ -3331,7 +3350,7 @@ static int interrupt_init_