* [PATCH 09/64] i2c: bcm2835: reword according to newest specification
From: Wolfram Sang @ 2024-03-22 13:25 UTC (permalink / raw)
To: linux-i2c
Cc: Wolfram Sang, Andi Shyti, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20240322132619.6389-1-wsa+renesas@sang-engineering.com>
Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
specifications and replace "master/slave" with more appropriate terms.
They are also more specific because we distinguish now between a remote
entity ("client") and a local one ("target").
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/i2c/busses/i2c-bcm2835.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index b92de1944221..62776e7fc586 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * BCM2835 master mode driver
+ * BCM2835 host controller mode driver
*/
#include <linux/clk.h>
@@ -25,7 +25,7 @@
#define BCM2835_I2C_DEL 0x18
/*
* 16-bit field for the number of SCL cycles to wait after rising SCL
- * before deciding the slave is not responding. 0 disables the
+ * before deciding the client is not responding. 0 disables the
* timeout detection.
*/
#define BCM2835_I2C_CLKT 0x1c
@@ -223,7 +223,7 @@ static void bcm2835_drain_rxfifo(struct bcm2835_i2c_dev *i2c_dev)
/*
* Repeated Start Condition (Sr)
* The BCM2835 ARM Peripherals datasheet mentions a way to trigger a Sr when it
- * talks about reading from a slave with 10 bit address. This is achieved by
+ * talks about reading from a client with 10 bit address. This is achieved by
* issuing a write, poll the I2CS.TA flag and wait for it to be set, and then
* issue a read.
* A comment in https://github.com/raspberrypi/linux/issues/254 shows how the
@@ -391,7 +391,7 @@ static u32 bcm2835_i2c_func(struct i2c_adapter *adap)
}
static const struct i2c_algorithm bcm2835_i2c_algo = {
- .master_xfer = bcm2835_i2c_xfer,
+ .xfer = bcm2835_i2c_xfer,
.functionality = bcm2835_i2c_func,
};
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 10/64] i2c: brcmstb: reword according to newest specification
From: Wolfram Sang @ 2024-03-22 13:25 UTC (permalink / raw)
To: linux-i2c
Cc: Wolfram Sang, Kamal Dasu, Broadcom internal kernel review list,
Andi Shyti, Florian Fainelli, linux-arm-kernel, linux-kernel
In-Reply-To: <20240322132619.6389-1-wsa+renesas@sang-engineering.com>
Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
specifications and replace "master/slave" with more appropriate terms.
They are also more specific because we distinguish now between a remote
entity ("client") and a local one ("target").
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/i2c/busses/i2c-brcmstb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-brcmstb.c b/drivers/i2c/busses/i2c-brcmstb.c
index 38f276c99193..dfdf465e6f8c 100644
--- a/drivers/i2c/busses/i2c-brcmstb.c
+++ b/drivers/i2c/busses/i2c-brcmstb.c
@@ -67,7 +67,7 @@
/* BSC block register map structure to cache fields to be written */
struct bsc_regs {
- u32 chip_address; /* slave address */
+ u32 chip_address; /* client address */
u32 data_in[N_DATA_REGS]; /* tx data buffer*/
u32 cnt_reg; /* rx/tx data length */
u32 ctl_reg; /* control register */
@@ -320,7 +320,7 @@ static int brcmstb_send_i2c_cmd(struct brcmstb_i2c_dev *dev,
return rc;
}
-/* Actual data transfer through the BSC master */
+/* Actual data transfer through the BSC controller */
static int brcmstb_i2c_xfer_bsc_data(struct brcmstb_i2c_dev *dev,
u8 *buf, unsigned int len,
struct i2c_msg *pmsg)
@@ -441,7 +441,7 @@ static int brcmstb_i2c_do_addr(struct brcmstb_i2c_dev *dev,
return 0;
}
-/* Master transfer function */
+/* Host transfer function */
static int brcmstb_i2c_xfer(struct i2c_adapter *adapter,
struct i2c_msg msgs[], int num)
{
@@ -473,7 +473,7 @@ static int brcmstb_i2c_xfer(struct i2c_adapter *adapter,
brcmstb_set_i2c_start_stop(dev, cond);
- /* Send slave address */
+ /* Send client address */
if (!(pmsg->flags & I2C_M_NOSTART)) {
rc = brcmstb_i2c_do_addr(dev, pmsg);
if (rc < 0) {
@@ -545,8 +545,8 @@ static u32 brcmstb_i2c_functionality(struct i2c_adapter *adap)
}
static const struct i2c_algorithm brcmstb_i2c_algo = {
- .master_xfer = brcmstb_i2c_xfer,
- .master_xfer_atomic = brcmstb_i2c_xfer_atomic,
+ .xfer = brcmstb_i2c_xfer,
+ .xfer_atomic = brcmstb_i2c_xfer_atomic,
.functionality = brcmstb_i2c_functionality,
};
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 07/64] i2c: bcm-iproc: reword according to newest specification
From: Wolfram Sang @ 2024-03-22 13:25 UTC (permalink / raw)
To: linux-i2c
Cc: Wolfram Sang, Andi Shyti, Ray Jui, Scott Branden,
Broadcom internal kernel review list, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240322132619.6389-1-wsa+renesas@sang-engineering.com>
Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
specifications and replace "master/slave" with more appropriate terms.
They are also more specific because we distinguish now between a remote
entity ("client") and a local one ("target").
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/i2c/busses/i2c-bcm-iproc.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
index e905734c26a0..3c68d4df029f 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -224,8 +224,8 @@ static void slave_rx_tasklet_fn(unsigned long);
| BIT(IS_S_TX_UNDERRUN_SHIFT) | BIT(IS_S_RX_FIFO_FULL_SHIFT)\
| BIT(IS_S_RX_THLD_SHIFT))
-static int bcm_iproc_i2c_reg_slave(struct i2c_client *slave);
-static int bcm_iproc_i2c_unreg_slave(struct i2c_client *slave);
+static int bcm_iproc_i2c_reg_target(struct i2c_client *slave);
+static int bcm_iproc_i2c_unreg_target(struct i2c_client *slave);
static void bcm_iproc_i2c_enable_disable(struct bcm_iproc_i2c_dev *iproc_i2c,
bool enable);
@@ -987,17 +987,17 @@ static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
val = I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
- if (adap->algo->reg_slave)
+ if (adap->algo->reg_target)
val |= I2C_FUNC_SLAVE;
return val;
}
static struct i2c_algorithm bcm_iproc_algo = {
- .master_xfer = bcm_iproc_i2c_xfer,
+ .xfer = bcm_iproc_i2c_xfer,
.functionality = bcm_iproc_i2c_functionality,
- .reg_slave = bcm_iproc_i2c_reg_slave,
- .unreg_slave = bcm_iproc_i2c_unreg_slave,
+ .reg_target = bcm_iproc_i2c_reg_target,
+ .unreg_target = bcm_iproc_i2c_unreg_target,
};
static const struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
@@ -1079,8 +1079,8 @@ static int bcm_iproc_i2c_probe(struct platform_device *pdev)
spin_lock_init(&iproc_i2c->idm_lock);
/* no slave support */
- bcm_iproc_algo.reg_slave = NULL;
- bcm_iproc_algo.unreg_slave = NULL;
+ bcm_iproc_algo.reg_target = NULL;
+ bcm_iproc_algo.unreg_target = NULL;
}
ret = bcm_iproc_i2c_init(iproc_i2c);
@@ -1191,7 +1191,7 @@ static const struct dev_pm_ops bcm_iproc_i2c_pm_ops = {
.resume_early = &bcm_iproc_i2c_resume
};
-static int bcm_iproc_i2c_reg_slave(struct i2c_client *slave)
+static int bcm_iproc_i2c_reg_target(struct i2c_client *slave)
{
struct bcm_iproc_i2c_dev *iproc_i2c = i2c_get_adapdata(slave->adapter);
@@ -1210,7 +1210,7 @@ static int bcm_iproc_i2c_reg_slave(struct i2c_client *slave)
return 0;
}
-static int bcm_iproc_i2c_unreg_slave(struct i2c_client *slave)
+static int bcm_iproc_i2c_unreg_target(struct i2c_client *slave)
{
u32 tmp;
struct bcm_iproc_i2c_dev *iproc_i2c = i2c_get_adapdata(slave->adapter);
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 05/64] i2c: aspeed: reword according to newest specification
From: Wolfram Sang @ 2024-03-22 13:24 UTC (permalink / raw)
To: linux-i2c
Cc: Wolfram Sang, Brendan Higgins, Benjamin Herrenschmidt,
Joel Stanley, Andi Shyti, Andrew Jeffery, openbmc,
linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20240322132619.6389-1-wsa+renesas@sang-engineering.com>
Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
specifications and replace "master/slave" with more appropriate terms.
They are also more specific because we distinguish now between a remote
entity ("client") and a local one ("target").
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
drivers/i2c/busses/i2c-aspeed.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index ce8c4846b7fa..4e6ea4a5cab9 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -159,7 +159,7 @@ struct aspeed_i2c_bus {
bool send_stop;
int cmd_err;
/* Protected only by i2c_lock_bus */
- int master_xfer_result;
+ int xfer_result;
/* Multi-master */
bool multi_master;
#if IS_ENABLED(CONFIG_I2C_SLAVE)
@@ -608,9 +608,9 @@ static u32 aspeed_i2c_master_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
out_complete:
bus->msgs = NULL;
if (bus->cmd_err)
- bus->master_xfer_result = bus->cmd_err;
+ bus->xfer_result = bus->cmd_err;
else
- bus->master_xfer_result = bus->msgs_index + 1;
+ bus->xfer_result = bus->msgs_index + 1;
complete(&bus->cmd_complete);
out_no_complete:
return irq_handled;
@@ -679,7 +679,7 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
}
-static int aspeed_i2c_master_xfer(struct i2c_adapter *adap,
+static int aspeed_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs, int num)
{
struct aspeed_i2c_bus *bus = i2c_get_adapdata(adap);
@@ -738,7 +738,7 @@ static int aspeed_i2c_master_xfer(struct i2c_adapter *adap,
return -ETIMEDOUT;
}
- return bus->master_xfer_result;
+ return bus->xfer_result;
}
static u32 aspeed_i2c_functionality(struct i2c_adapter *adap)
@@ -748,7 +748,7 @@ static u32 aspeed_i2c_functionality(struct i2c_adapter *adap)
#if IS_ENABLED(CONFIG_I2C_SLAVE)
/* precondition: bus.lock has been acquired. */
-static void __aspeed_i2c_reg_slave(struct aspeed_i2c_bus *bus, u16 slave_addr)
+static void __aspeed_i2c_reg_target(struct aspeed_i2c_bus *bus, u16 slave_addr)
{
u32 addr_reg_val, func_ctrl_reg_val;
@@ -770,7 +770,7 @@ static void __aspeed_i2c_reg_slave(struct aspeed_i2c_bus *bus, u16 slave_addr)
bus->slave_state = ASPEED_I2C_SLAVE_INACTIVE;
}
-static int aspeed_i2c_reg_slave(struct i2c_client *client)
+static int aspeed_i2c_reg_target(struct i2c_client *client)
{
struct aspeed_i2c_bus *bus = i2c_get_adapdata(client->adapter);
unsigned long flags;
@@ -781,7 +781,7 @@ static int aspeed_i2c_reg_slave(struct i2c_client *client)
return -EINVAL;
}
- __aspeed_i2c_reg_slave(bus, client->addr);
+ __aspeed_i2c_reg_target(bus, client->addr);
bus->slave = client;
spin_unlock_irqrestore(&bus->lock, flags);
@@ -789,7 +789,7 @@ static int aspeed_i2c_reg_slave(struct i2c_client *client)
return 0;
}
-static int aspeed_i2c_unreg_slave(struct i2c_client *client)
+static int aspeed_i2c_unreg_target(struct i2c_client *client)
{
struct aspeed_i2c_bus *bus = i2c_get_adapdata(client->adapter);
u32 func_ctrl_reg_val;
@@ -814,11 +814,11 @@ static int aspeed_i2c_unreg_slave(struct i2c_client *client)
#endif /* CONFIG_I2C_SLAVE */
static const struct i2c_algorithm aspeed_i2c_algo = {
- .master_xfer = aspeed_i2c_master_xfer,
+ .xfer = aspeed_i2c_xfer,
.functionality = aspeed_i2c_functionality,
#if IS_ENABLED(CONFIG_I2C_SLAVE)
- .reg_slave = aspeed_i2c_reg_slave,
- .unreg_slave = aspeed_i2c_unreg_slave,
+ .reg_target = aspeed_i2c_reg_target,
+ .unreg_target = aspeed_i2c_unreg_target,
#endif /* CONFIG_I2C_SLAVE */
};
@@ -950,7 +950,7 @@ static int aspeed_i2c_init(struct aspeed_i2c_bus *bus,
#if IS_ENABLED(CONFIG_I2C_SLAVE)
/* If slave has already been registered, re-enable it. */
if (bus->slave)
- __aspeed_i2c_reg_slave(bus, bus->slave->addr);
+ __aspeed_i2c_reg_target(bus, bus->slave->addr);
#endif /* CONFIG_I2C_SLAVE */
/* Set interrupt generation of I2C controller */
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 00/64] i2c: reword i2c_algorithm according to newest specification
From: Wolfram Sang @ 2024-03-22 13:24 UTC (permalink / raw)
To: linux-i2c
Cc: Wolfram Sang, asahi, chrome-platform, imx, linux-actions,
linux-amlogic, linux-arm-kernel, linux-arm-msm, linux-aspeed,
linux-kernel, linux-mediatek, linux-mips, linux-omap,
linuxppc-dev, linux-renesas-soc, linux-riscv, linux-rockchip,
linux-rpi-kernel, linux-samsung-soc, linux-stm32, linux-sunxi,
linux-tegra, openbmc, virtualization
Okay, we need to begin somewhere...
Start changing the wording of the I2C main header wrt. the newest I2C
v7, SMBus 3.2, I3C specifications and replace "master/slave" with more
appropriate terms. This first step renames the members of struct
i2c_algorithm. Once all in-tree users are converted, the anonymous union
will go away again. All this work will also pave the way for finally
seperating the monolithic header into more fine-grained headers like
"i2c/clients.h" etc. So, this is not a simple renaming-excercise but
also a chance to update the I2C core to recent Linux standards.
My motivation is to improve the I2C core API, in general. My motivation
is not to clean each and every driver. I think this is impossible
because register names based on official documentation will need to stay
as they are. But the Linux-internal names should be updated IMO.
That being said, I worked on 62 drivers in this series beyond plain
renames inside 'struct i2c_algorithm' because the fruits were so
low-hanging. Before this series, 112 files in the 'busses/' directory
contained 'master' and/or 'slave'. After the series, only 57. Why not?
Next step is updating the drivers outside the 'i2c'-folder regarding
'struct i2c_algorithm' so we can remove the anonymous union ASAP. To be
able to work on this with minimal dependencies, I'd like to apply this
series between -rc1 and -rc2.
I hope this will work for you guys. The changes are really minimal. If
you are not comfortable with changes to your driver or need more time to
review, please NACK the patch and I will drop the patch and/or address
the issues separeately.
@Andi: are you okay with this approach? It means you'd need to merge
-rc2 into your for-next branch. Or rebase if all fails.
Speaking of Andi, thanks a lot to him taking care of the controller
drivers these days. His work really gives me the freedom to work on I2C
core issues again. Also, Renesas deserves a honorable mention here for
increased support of my I2C activities. Thank you!
If you have comments, hints, etc, please let me know.
Happy hacking,
Wolfram
Wolfram Sang (64):
i2c: reword i2c_algorithm according to newest specification
i2c: ali15x3: reword according to newest specification
i2c: altera: reword according to newest specification
i2c: amd-mp2-pci: reword according to newest specification
i2c: aspeed: reword according to newest specification
i2c: au1550: reword according to newest specification
i2c: bcm-iproc: reword according to newest specification
i2c: bcm-kona: reword according to newest specification
i2c: bcm2835: reword according to newest specification
i2c: brcmstb: reword according to newest specification
i2c: cadence: reword according to newest specification
i2c: cht-wc: reword according to newest specification
i2c: cp2615: reword according to newest specification
i2c: cpm: reword according to newest specification
i2c: davinci: reword according to newest specification
i2c: digicolor: reword according to newest specification
i2c: dln2: reword according to newest specification
i2c: eg20t: reword according to newest specification
i2c: emev2: reword according to newest specification
i2c: fsi: reword according to newest specification
i2c: gpio: reword according to newest specification
i2c: highlander: reword according to newest specification
i2c: hix5hd2: reword according to newest specification
i2c: i801: reword according to newest specification
i2c: ibm_iic: reword according to newest specification
i2c: imx-lpi2c: reword according to newest specification
i2c: iop3xx: reword according to newest specification
i2c: isch: reword according to newest specification
i2c: ismt: reword according to newest specification
i2c: ljca: reword according to newest specification
i2c: lpc2k: reword according to newest specification
i2c: ls2x: reword according to newest specification
i2c: mchp-pci1xxxx: reword according to newest specification
i2c: microchip-corei2c: reword according to newest specification
i2c: mlxcpld: reword according to newest specification
i2c: mpc: reword according to newest specification
i2c: mt7621: reword according to newest specification
i2c: mv64xxx: reword according to newest specification
i2c: octeon-core: reword according to newest specification
i2c: owl: reword according to newest specification
i2c: piix4: reword according to newest specification
i2c: powermac: reword according to newest specification
i2c: pxa-pci: reword according to newest specification
i2c: qup: reword according to newest specification
i2c: rcar: reword according to newest specification
i2c: riic: reword according to newest specification
i2c: rk3x: reword according to newest specification
i2c: sh7760: reword according to newest specification
i2c: sh_mobile: reword according to newest specification
i2c: sis5595: reword according to newest specification
i2c: sis630: reword according to newest specification
i2c: sprd: reword according to newest specification
i2c: st: reword according to newest specification
i2c: stm32f4: reword according to newest specification
i2c: sun6i-p2wi: reword according to newest specification
i2c: synquacer: reword according to newest specification
i2c: taos-evm: reword according to newest specification
i2c: tiny-usb: reword according to newest specification
i2c: uniphier-f: reword according to newest specification
i2c: uniphier: reword according to newest specification
i2c: viperboard: reword according to newest specification
i2c: xlp9xx: reword according to newest specification
i2c: scx200_acb: reword according to newest specification
i2c: reword i2c_algorithm in drivers according to newest specification
drivers/i2c/busses/i2c-ali15x3.c | 2 +-
drivers/i2c/busses/i2c-altera.c | 4 +-
drivers/i2c/busses/i2c-amd-mp2-pci.c | 8 ++--
drivers/i2c/busses/i2c-amd-mp2-plat.c | 2 +-
drivers/i2c/busses/i2c-aspeed.c | 26 +++++-----
drivers/i2c/busses/i2c-at91-master.c | 2 +-
drivers/i2c/busses/i2c-at91-slave.c | 8 ++--
drivers/i2c/busses/i2c-au1550.c | 14 +++---
drivers/i2c/busses/i2c-axxia.c | 10 ++--
drivers/i2c/busses/i2c-bcm-iproc.c | 20 ++++----
drivers/i2c/busses/i2c-bcm-kona.c | 14 +++---
drivers/i2c/busses/i2c-bcm2835.c | 8 ++--
drivers/i2c/busses/i2c-brcmstb.c | 12 ++---
drivers/i2c/busses/i2c-cadence.c | 14 +++---
drivers/i2c/busses/i2c-cht-wc.c | 8 ++--
drivers/i2c/busses/i2c-cp2615.c | 6 +--
drivers/i2c/busses/i2c-cpm.c | 4 +-
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
drivers/i2c/busses/i2c-davinci.c | 13 +++--
drivers/i2c/busses/i2c-designware-master.c | 2 +-
drivers/i2c/busses/i2c-designware-slave.c | 8 ++--
drivers/i2c/busses/i2c-digicolor.c | 4 +-
drivers/i2c/busses/i2c-diolan-u2c.c | 2 +-
drivers/i2c/busses/i2c-dln2.c | 4 +-
drivers/i2c/busses/i2c-eg20t.c | 10 ++--
drivers/i2c/busses/i2c-emev2.c | 10 ++--
drivers/i2c/busses/i2c-exynos5.c | 4 +-
drivers/i2c/busses/i2c-fsi.c | 56 +++++++++++-----------
drivers/i2c/busses/i2c-gpio.c | 8 ++--
drivers/i2c/busses/i2c-gxp.c | 12 ++---
drivers/i2c/busses/i2c-highlander.c | 2 +-
drivers/i2c/busses/i2c-hisi.c | 4 +-
drivers/i2c/busses/i2c-hix5hd2.c | 4 +-
drivers/i2c/busses/i2c-i801.c | 12 ++---
drivers/i2c/busses/i2c-ibm_iic.c | 26 +++++-----
drivers/i2c/busses/i2c-img-scb.c | 2 +-
drivers/i2c/busses/i2c-imx-lpi2c.c | 10 ++--
drivers/i2c/busses/i2c-imx.c | 12 ++---
drivers/i2c/busses/i2c-iop3xx.c | 10 ++--
drivers/i2c/busses/i2c-isch.c | 2 +-
drivers/i2c/busses/i2c-ismt.c | 2 +-
drivers/i2c/busses/i2c-jz4780.c | 2 +-
drivers/i2c/busses/i2c-kempld.c | 2 +-
drivers/i2c/busses/i2c-ljca.c | 20 ++++----
drivers/i2c/busses/i2c-lpc2k.c | 8 ++--
drivers/i2c/busses/i2c-ls2x.c | 8 ++--
drivers/i2c/busses/i2c-mchp-pci1xxxx.c | 40 ++++++++--------
drivers/i2c/busses/i2c-meson.c | 4 +-
drivers/i2c/busses/i2c-microchip-corei2c.c | 4 +-
drivers/i2c/busses/i2c-mlxbf.c | 8 ++--
drivers/i2c/busses/i2c-mlxcpld.c | 12 ++---
drivers/i2c/busses/i2c-mpc.c | 4 +-
drivers/i2c/busses/i2c-mt65xx.c | 2 +-
drivers/i2c/busses/i2c-mt7621.c | 22 ++++-----
drivers/i2c/busses/i2c-mv64xxx.c | 12 ++---
drivers/i2c/busses/i2c-mxs.c | 2 +-
drivers/i2c/busses/i2c-nomadik.c | 2 +-
drivers/i2c/busses/i2c-npcm7xx.c | 12 ++---
drivers/i2c/busses/i2c-nvidia-gpu.c | 4 +-
drivers/i2c/busses/i2c-ocores.c | 8 ++--
drivers/i2c/busses/i2c-octeon-core.c | 6 +--
drivers/i2c/busses/i2c-octeon-platdrv.c | 2 +-
drivers/i2c/busses/i2c-omap.c | 4 +-
drivers/i2c/busses/i2c-opal.c | 4 +-
drivers/i2c/busses/i2c-owl.c | 10 ++--
drivers/i2c/busses/i2c-pasemi-core.c | 2 +-
drivers/i2c/busses/i2c-piix4.c | 2 +-
drivers/i2c/busses/i2c-pnx.c | 2 +-
drivers/i2c/busses/i2c-powermac.c | 8 ++--
drivers/i2c/busses/i2c-pxa-pci.c | 2 +-
drivers/i2c/busses/i2c-pxa.c | 12 ++---
drivers/i2c/busses/i2c-qcom-cci.c | 2 +-
drivers/i2c/busses/i2c-qcom-geni.c | 2 +-
drivers/i2c/busses/i2c-qup.c | 6 +--
drivers/i2c/busses/i2c-rcar.c | 16 +++----
drivers/i2c/busses/i2c-riic.c | 6 +--
drivers/i2c/busses/i2c-rk3x.c | 18 +++----
drivers/i2c/busses/i2c-robotfuzz-osif.c | 2 +-
drivers/i2c/busses/i2c-rzv2m.c | 8 ++--
drivers/i2c/busses/i2c-s3c2410.c | 4 +-
drivers/i2c/busses/i2c-sh7760.c | 18 +++----
drivers/i2c/busses/i2c-sh_mobile.c | 12 ++---
drivers/i2c/busses/i2c-sis5595.c | 2 +-
drivers/i2c/busses/i2c-sis630.c | 16 +++----
drivers/i2c/busses/i2c-sprd.c | 14 +++---
drivers/i2c/busses/i2c-st.c | 17 +++----
drivers/i2c/busses/i2c-stm32f4.c | 8 ++--
drivers/i2c/busses/i2c-stm32f7.c | 14 +++---
drivers/i2c/busses/i2c-sun6i-p2wi.c | 20 ++++----
drivers/i2c/busses/i2c-synquacer.c | 30 ++++++------
drivers/i2c/busses/i2c-taos-evm.c | 2 +-
drivers/i2c/busses/i2c-tegra-bpmp.c | 4 +-
drivers/i2c/busses/i2c-tegra.c | 4 +-
drivers/i2c/busses/i2c-thunderx-pcidrv.c | 2 +-
drivers/i2c/busses/i2c-tiny-usb.c | 4 +-
drivers/i2c/busses/i2c-uniphier-f.c | 22 ++++-----
drivers/i2c/busses/i2c-uniphier.c | 12 ++---
drivers/i2c/busses/i2c-viperboard.c | 8 ++--
drivers/i2c/busses/i2c-virtio.c | 2 +-
drivers/i2c/busses/i2c-wmt.c | 2 +-
drivers/i2c/busses/i2c-xiic.c | 2 +-
drivers/i2c/busses/i2c-xlp9xx.c | 4 +-
drivers/i2c/busses/scx200_acb.c | 4 +-
include/linux/i2c.h | 24 ++++++++--
104 files changed, 460 insertions(+), 464 deletions(-)
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] pinctrl: armada-37xx: remove an unused variable
From: Arnd Bergmann @ 2024-03-22 13:21 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Linus Walleij
Cc: Arnd Bergmann, linux-arm-kernel, linux-gpio, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
This variable has never been used and can be removed to avoid a W=1 warning:
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c:837:6: error: variable 'i' set but not used [-Werror,-Wunused-but-set-variable]
837 | int i = 0;
Fixes: 87466ccd9401 ("pinctrl: armada-37xx: Add pin controller support for Armada 37xx")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index c34719b7506d..4c4ada06423d 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -834,8 +834,6 @@ static int armada_37xx_gpiochip_register(struct platform_device *pdev,
static int armada_37xx_add_function(struct armada_37xx_pmx_func *funcs,
int *funcsize, const char *name)
{
- int i = 0;
-
if (*funcsize <= 0)
return -EOVERFLOW;
@@ -847,7 +845,6 @@ static int armada_37xx_add_function(struct armada_37xx_pmx_func *funcs,
return -EEXIST;
}
funcs++;
- i++;
}
/* append new unique function */
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] dmaengine: owl: fix register access functions
From: Arnd Bergmann @ 2024-03-22 13:21 UTC (permalink / raw)
To: Vinod Koul, Andreas Färber, Manivannan Sadhasivam,
Nathan Chancellor
Cc: Arnd Bergmann, Nick Desaulniers, Bill Wendling, Justin Stitt,
Uwe Kleine-König, Randy Dunlap, Rob Herring, Zhang Jianhua,
dmaengine, linux-arm-kernel, linux-actions, linux-kernel, llvm
From: Arnd Bergmann <arnd@arndb.de>
When building with 'make W=1', clang notices that the computed register
values are never actually written back but instead the wrong variable
is set:
drivers/dma/owl-dma.c:244:6: error: variable 'regval' set but not used [-Werror,-Wunused-but-set-variable]
244 | u32 regval;
| ^
drivers/dma/owl-dma.c:268:6: error: variable 'regval' set but not used [-Werror,-Wunused-but-set-variable]
268 | u32 regval;
| ^
Change these to what was most likely intended.
Fixes: 47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/dma/owl-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
index 4e76c4ec2d39..e001f4f7aa64 100644
--- a/drivers/dma/owl-dma.c
+++ b/drivers/dma/owl-dma.c
@@ -250,7 +250,7 @@ static void pchan_update(struct owl_dma_pchan *pchan, u32 reg,
else
regval &= ~val;
- writel(val, pchan->base + reg);
+ writel(regval, pchan->base + reg);
}
static void pchan_writel(struct owl_dma_pchan *pchan, u32 reg, u32 data)
@@ -274,7 +274,7 @@ static void dma_update(struct owl_dma *od, u32 reg, u32 val, bool state)
else
regval &= ~val;
- writel(val, od->base + reg);
+ writel(regval, od->base + reg);
}
static void dma_writel(struct owl_dma *od, u32 reg, u32 data)
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] [RESEND] irqchip: armada: suppress unused-function warning
From: Andrew Lunn @ 2024-03-22 13:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Thomas Gleixner, Arnd Bergmann, Gregory Clement,
Sebastian Hesselbarth, Marc Zyngier, Nathan Rossi,
linux-arm-kernel, linux-kernel
In-Reply-To: <20240322125838.901649-1-arnd@kernel.org>
On Fri, Mar 22, 2024 at 01:58:25PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> armada_370_xp_msi_reenable_percpu is only defined when CONFIG_PCI_MSI
> is enabled, and only called when SMP is enabled.
>
> Without CONFIG_SMP, there are no callers, so we get a build time
> warning instead:
>
> drivers/irqchip/irq-armada-370-xp.c:319:13: error: 'armada_370_xp_msi_reenable_percpu' defined but not used [-Werror=unused-function]
> 319 | static void armada_370_xp_msi_reenable_percpu(void) {}
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Mark the function as __maybe_unused to avoid adding more complexity
> to the #ifdefs.
>
> Fixes: 8ca61cde32c1 ("irqchip/armada-370-xp: Enable MSI affinity configuration")
> Link: https://lore.kernel.org/lkml/20221215170202.2441960-1-arnd@kernel.org/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards
From: Andrew Lunn @ 2024-03-22 13:11 UTC (permalink / raw)
To: Josua Mayer
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Yazan Shhady,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <0d1afbcc-948e-4aff-8296-42f7166d318d@solid-run.com>
> > Sorry, but no. List the LEDs in the PHY node, and they can then be
> > controlled via /sys/class/leds.
> May I ask more precisely the motivation?
> Does this replace the phy's builtin automatic led control?
> > arch/arm/boot/dts/marvell/armada-370-rd.dts is an example.
>
> I will investigate it.
>
> My main motivation for tweaking the led controls was to make them all consistent across the two boards:
> - LEDs under control of PHYs on cpu mdio bus
> - LEDs under control of ethernet switch on mdio bus
> - LEDs under control of ethernet phy on external mdio bus behind ethernet switch
>
> It looks as if the marvell phy driver supports led subnodes,
> The switch driver does not.
https://lwn.net/Articles/965775/
There has been quite a bit of interest in mv88e6xxx driver support, so
i expect support for other families outside of 6352 will be added
after it has been merged, and it is not difficult code to write.
> Finally one phy can only be written to but not read,
> the cpu can never know its link state.
O.K. That one cannot use the LED infrastructure in a meaningful way.
> So I prefer (for the Clearfog Pro) board to explicitly use the phys
> autonomous management of LEDs.
> Is that still possible if I added led subnodes?
You can combine both. The horrible marvell,reg-init will be applied
first. The generic LED code will then take over controlling the LEDs.
For the discrete PHYs, the generic LED code can make use of the
hardware offload support to read back the hardware configuration and
configure itself to match. The switch code is missing hardware offload
at the moment. So it cannot read back the current
configuration. However, it is simple code to add, and the discrete
code is a good example to follow.
marvell,reg-init is not going to go away, because of backwards
compatibility with old DT blobs. But in general, i expect all vendor
proprietary methods of configuring LEDs to be deprecated and replaced
with the vendor neutral /sys/class/leds.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 1/1] phy: freescale: imx8m-pcie: fix pcie link-up instability
From: Marcel Ziswiler @ 2024-03-22 13:06 UTC (permalink / raw)
To: linux-phy
Cc: linux-imx, Lucas Stach, linux-arm-kernel, kernel, Richard Zhu,
linux-kernel, Marcel Ziswiler, Fabio Estevam, Heiko Stuebner,
Kishon Vijay Abraham I, Marc Kleine-Budde, Rob Herring,
Sascha Hauer, Shawn Guo, Tim Harvey, Vinod Koul, Yang Li, imx
In-Reply-To: <20240322130646.1016630-1-marcel@ziswiler.com>
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Leaving AUX_PLL_REFCLK_SEL at its reset default of AUX_IN (PLL clock)
proves to be more stable on the i.MX 8M Mini.
Fixes: 1aa97b002258 ("phy: freescale: pcie: Initialize the imx8 pcie standalone phy driver")
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
index b700f52b7b67..11fcb1867118 100644
--- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
+++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
@@ -110,8 +110,10 @@ static int imx8_pcie_phy_power_on(struct phy *phy)
/* Source clock from SoC internal PLL */
writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL,
imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062);
- writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
- imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
+ if (imx8_phy->drvdata->variant != IMX8MM) {
+ writel(AUX_PLL_REFCLK_SEL_SYS_PLL,
+ imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063);
+ }
val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM;
writel(val | ANA_AUX_RX_TERM_GND_EN,
imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064);
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 0/1] phy: freescale: imx8m-pcie: facing pcie link-up instability
From: Marcel Ziswiler @ 2024-03-22 13:06 UTC (permalink / raw)
To: linux-phy
Cc: linux-imx, Lucas Stach, linux-arm-kernel, kernel, Richard Zhu,
linux-kernel, Marcel Ziswiler, Fabio Estevam, Heiko Stuebner,
Kishon Vijay Abraham I, Marc Kleine-Budde, Rob Herring,
Sascha Hauer, Shawn Guo, Tim Harvey, Vinod Koul, Yang Li, imx
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
In our automated testing setup, we use Delock Mini-PCIe SATA cards [1].
While this setup has proven very stable overall we noticed upstream on
the i.MX8M Mini fails quite regularly (about 50/50) to bring up the PCIe
link while with NXP's downstream BSP 5.15.71_2.2.2 it always works. As
that old downstream stuff was quite different, I first also tried NXP's
latest downstream BSP 6.1.55_2.2.0 which from a PCIe point of view is
fairly vanilla, however, also there the PCIe link-up was not stable.
Comparing and debugging I noticed that upstream explicitly configures
the AUX_PLL_REFCLK_SEL to I_PLL_REFCLK_FROM_SYSPLL while working
downstream [2] leaving it at reset defaults of AUX_IN (PLL clock).
Unfortunately, the TRM does not mention any further details about this
register (both for the i.MX 8M Mini as well as the Plus). Maybe somebody
from NXP could further comment on this?
BTW: On the i.MX 8M Plus we have not seen any issues with PCIe with the
exact same setup which is why I left it unchanged.
[1] https://www.delock.com/produkt/95233/merkmale.html
[2] https://github.com/nxp-imx/linux-imx/blob/lf-5.15.71-2.2.0/drivers/pci/controller/dwc/pci-imx6.c#L1548
Marcel Ziswiler (1):
phy: freescale: imx8m-pcie: fix pcie link-up instability
drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] [RESEND] irqchip: armada: suppress unused-function warning
From: Arnd Bergmann @ 2024-03-22 12:58 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Arnd Bergmann, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Marc Zyngier, Nathan Rossi,
linux-arm-kernel, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
armada_370_xp_msi_reenable_percpu is only defined when CONFIG_PCI_MSI
is enabled, and only called when SMP is enabled.
Without CONFIG_SMP, there are no callers, so we get a build time
warning instead:
drivers/irqchip/irq-armada-370-xp.c:319:13: error: 'armada_370_xp_msi_reenable_percpu' defined but not used [-Werror=unused-function]
319 | static void armada_370_xp_msi_reenable_percpu(void) {}
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark the function as __maybe_unused to avoid adding more complexity
to the #ifdefs.
Fixes: 8ca61cde32c1 ("irqchip/armada-370-xp: Enable MSI affinity configuration")
Link: https://lore.kernel.org/lkml/20221215170202.2441960-1-arnd@kernel.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I noticed this never got applied, and the warning still remains.
---
drivers/irqchip/irq-armada-370-xp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index a55528469278..4b021a67bdfe 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -316,7 +316,7 @@ static int armada_370_xp_msi_init(struct device_node *node,
return 0;
}
#else
-static void armada_370_xp_msi_reenable_percpu(void) {}
+static __maybe_unused void armada_370_xp_msi_reenable_percpu(void) {}
static inline int armada_370_xp_msi_init(struct device_node *node,
phys_addr_t main_int_phys_base)
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] ARM: unwind: improve unwinders for noreturn case
From: Jiangfeng Xiao @ 2024-03-22 12:54 UTC (permalink / raw)
To: Russell King (Oracle), David Laight
Cc: Ard Biesheuvel, arnd@arndb.de, keescook@chromium.org,
haibo.li@mediatek.com, angelogioacchino.delregno@collabora.com,
amergnat@baylibre.com, akpm@linux-foundation.org,
dave.hansen@linux.intel.com, douzhaolei@huawei.com,
gustavoars@kernel.org, jpoimboe@kernel.org,
kepler.chenxin@huawei.com, kirill.shutemov@linux.intel.com,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
nixiaoming@huawei.com, peterz@infradead.org, wangbing6@huawei.com,
wangfangpeng1@huawei.com, jannh@google.com, willy@infradead.org
In-Reply-To: <Zf1UyxlDf/oCjXxr@shell.armlinux.org.uk>
On 2024/3/22 17:52, Russell King (Oracle) wrote:
> On Fri, Mar 22, 2024 at 09:24:20AM +0000, David Laight wrote:
>> From: Russell King
>>> Sent: 22 March 2024 00:09
>>>
>>> On Thu, Mar 21, 2024 at 11:43:41PM +0100, Ard Biesheuvel wrote:
>>>> Given that this particular issue would just disappear if the compiler
>>>> would just insert a BRK after the BL, I'd prefer to explore first
>>>> whether we can get this fixed on the compiler side.
>>>
>>> Arm32 doesn't have a BRK instruction. What would be appropriate after
>>> the no-return BL would be OS specific.
>>
>> It would need to depend on what was being compiled.
>
> Yes, but as for the rest...
>
>> For the kernel it could be much the same as BUG().
>> (Probably without any extra data.)
>> I suspect that arm32 could use 'swi' in kernel space,
>> but you wouldn't want to use that in userspace.
>>
>> Looks like armv5 has a bkpt instruction - could that be used?
>> Or does the kernel need to support armv4?
>>
>> The last arm I wrote anything for was a strongarm.
>
> Thank you David, but remember - I have programmed 32-bit Arm since 1992,
> and wrote the majority of the 32-bit Arm kernel support. I think I know
> what I'm walking about by now.
>
> The compiler can't do the same as BUG() - that is a kernel specific
> construct and not an architecture one. It is an undefined instruction
> specifically chosen to be undefined on both 32-bit and 16-bit Arm ISAs.
>
> As for your idea of using "swi" in kernel space, no that's never going
> to happen - to shoe-horn that into the SWI exception path for the sake
> of the compiler would be totally idiotic - it would cause userspace
> performance regressions for something that never happens. Moreover,
> with EABI the "comment" field in the "swi" instruction is ignored so
> all SWIs under EABI are treated the same. So no, that's not going to
> work without causing inefficiencies - again - for a case that will
> likely never happen.
>
> Whereas we already provide an abort() function because iirc the
> compiler used to emit branches to that due to noreturn functions. If
> correct, there's previous convention for doing this - and abort() is
> still exists in the kernel and in userspace since it's part of ANSI
> C. This would be a more reliable and portable solution, but probably
> not for embedded platforms - and that's probably why it got removed.
>
> There isn't going to be a single solution to this which satisfies
> everyone, and I don't blame the compiler people for deciding to
> basically give up with putting any instruction after a call to a
> no-return function - because there isn't an instruction defined in
> the architecture that _could_ be put there that would work everywhere.
>
If the compiler inserts (a branch to 'abort') behind (no-return BL)
that does not apply to ARM32 embedded platforms, do you think the
"[PATCH v3] ARM: unwind: improve unwinders for noreturn case"
submitted the day before yesterday can be used as a
complementary solution?
2) we're unwinding a frame that has been created because of a branch,
where the PC points at the next instruction _after_ that callsite.
When we hit the second type of frame, "pc-1" is closer to callsite,
and no problem is introduced. In addition, the issue of the 'noreturn'
can be solved.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1] arm64: dts: freescale: verdin-imx8mp: enable Verdin I2C_3_HDMI interface
From: Vitor Soares @ 2024-03-22 12:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Vitor Soares, devicetree, imx, linux-arm-kernel, linux-kernel
From: Vitor Soares <vitor.soares@toradex.com>
Enable Verdin I2C_3_HDMI interface on iMX8MP Toradex Verdin boards.
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
---
.../dts/freescale/imx8mp-verdin-dahlia.dtsi | 5 ++++
.../boot/dts/freescale/imx8mp-verdin-dev.dtsi | 5 ++++
.../dts/freescale/imx8mp-verdin-mallow.dtsi | 5 ++++
.../dts/freescale/imx8mp-verdin-yavia.dtsi | 5 ++++
.../boot/dts/freescale/imx8mp-verdin.dtsi | 27 ++++++++++++++++---
5 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-dahlia.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin-dahlia.dtsi
index 7e9e4b13b5c5..8d954259085f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-verdin-dahlia.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-dahlia.dtsi
@@ -110,6 +110,11 @@ wm8904_1a: audio-codec@1a {
};
};
+/* Verdin I2C_3_HDMI */
+&i2c5 {
+ status = "okay";
+};
+
/* Verdin PCIE_1 */
&pcie {
status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-dev.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin-dev.dtsi
index a509b2b7fa85..e5400140e5c6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-verdin-dev.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-dev.dtsi
@@ -131,6 +131,11 @@ nau8822_1a: audio-codec@1a {
};
};
+/* Verdin I2C_3_HDMI */
+&i2c5 {
+ status = "okay";
+};
+
/* Verdin PCIE_1 */
&pcie {
status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-mallow.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin-mallow.dtsi
index 8482393f3cac..1d15f7449c58 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-verdin-mallow.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-mallow.dtsi
@@ -112,6 +112,11 @@ &i2c4 {
status = "okay";
};
+/* Verdin I2C_3_HDMI */
+&i2c5 {
+ status = "okay";
+};
+
/* Verdin PCIE_1 */
&pcie {
status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-yavia.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin-yavia.dtsi
index db1722f0d80e..3a8542266d85 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-verdin-yavia.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-yavia.dtsi
@@ -117,6 +117,11 @@ &i2c4 {
status = "okay";
};
+/* Verdin I2C_3_HDMI */
+&i2c5 {
+ status = "okay";
+};
+
/* Verdin PCIE_1 */
&pcie {
status = "okay";
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
index faa17cbbe2fd..f033d4310305 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
@@ -664,8 +664,6 @@ atmel_mxt_ts_mezzanine: touch-mezzanine@4a {
};
};
-/* TODO: Verdin I2C_3_HDMI */
-
/* Verdin I2C_4_CSI */
&i2c3 {
clock-frequency = <400000>;
@@ -764,6 +762,16 @@ eeprom_carrier_board: eeprom@57 {
};
};
+/* Verdin I2C_3_HDMI */
+&i2c5 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c5>;
+ pinctrl-1 = <&pinctrl_i2c5_gpio>;
+ scl-gpios = <&gpio3 26 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio3 27 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
/* Verdin PCIE_1 */
&pcie {
pinctrl-names = "default";
@@ -1106,8 +1114,6 @@ pinctrl_gpio_keys: gpiokeysgrp {
pinctrl_hdmi_hog: hdmihoggrp {
fsl,pins =
<MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0x40000019>, /* SODIMM 63 */
- <MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x400001c3>, /* SODIMM 59 */
- <MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x400001c3>, /* SODIMM 57 */
<MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x40000019>; /* SODIMM 61 */
};
@@ -1163,6 +1169,19 @@ pinctrl_i2c4_gpio: i2c4gpiogrp {
<MX8MP_IOMUXC_I2C4_SDA__GPIO5_IO21 0x400001c6>; /* SODIMM 12 */
};
+ /* Verdin I2C_3_HDMI */
+ pinctrl_i2c5: i2c5grp {
+ fsl,pins =
+ <MX8MP_IOMUXC_HDMI_DDC_SCL__I2C5_SCL 0x400001c6>, /* SODIMM 59 */
+ <MX8MP_IOMUXC_HDMI_DDC_SDA__I2C5_SDA 0x400001c6>; /* SODIMM 57 */
+ };
+
+ pinctrl_i2c5_gpio: i2c5gpiogrp {
+ fsl,pins =
+ <MX8MP_IOMUXC_HDMI_DDC_SCL__GPIO3_IO26 0x400001c6>, /* SODIMM 59 */
+ <MX8MP_IOMUXC_HDMI_DDC_SDA__GPIO3_IO27 0x400001c6>; /* SODIMM 57 */
+ };
+
/* Verdin I2S_2_BCLK (TOUCH_RESET#) */
pinctrl_i2s_2_bclk_touch_reset: i2s2bclktouchresetgrp {
fsl,pins =
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] KVM: arm64: Allow only the specified FF-A calls to be forwarded to TZ
From: Sebastian Ene @ 2024-03-22 12:43 UTC (permalink / raw)
To: catalin.marinas, james.morse, jean-philippe, maz, oliver.upton,
qperret, qwandor, sebastianene, suzuki.poulose, tabba, will,
yuzenghui
Cc: kvmarm, linux-arm-kernel, linux-kernel, kernel-team
In-Reply-To: <20240322124303.309423-1-sebastianene@google.com>
The previous logic used a deny list to filter the FF-A calls. Because of
this, some of the calls escaped the check and they were forwarded by
default to Trustzone. (eg. FFA_MSG_SEND_DIRECT_REQ was denied but the 64
bit version of the call was not).
Modify the logic to use an allowlist and allow only the calls specified in
the filter function to be proxied to TZ from the hypervisor.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 46 +++++++++++++++++------------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 320f2eaa14a9..fc4f04209618 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -580,35 +580,35 @@ static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
ffa_to_smccc_res(res, ret);
}
-/*
- * Is a given FFA function supported, either by forwarding on directly
- * or by handling at EL2?
- */
static bool ffa_call_supported(u64 func_id)
{
switch (func_id) {
- /* Unsupported memory management calls */
- case FFA_FN64_MEM_RETRIEVE_REQ:
- case FFA_MEM_RETRIEVE_RESP:
- case FFA_MEM_RELINQUISH:
- case FFA_MEM_OP_PAUSE:
- case FFA_MEM_OP_RESUME:
- case FFA_MEM_FRAG_RX:
- case FFA_FN64_MEM_DONATE:
- /* Indirect message passing via RX/TX buffers */
- case FFA_MSG_SEND:
- case FFA_MSG_POLL:
- case FFA_MSG_WAIT:
- /* 32-bit variants of 64-bit calls */
+ /* Discovery functions */
+ case FFA_FEATURES:
+ case FFA_ID_GET:
+ case FFA_VERSION:
+ case FFA_PARTITION_INFO_GET:
+
+ /* Memory management calls */
+ case FFA_FN64_RXTX_MAP:
+ case FFA_RXTX_UNMAP:
+ case FFA_MEM_SHARE:
+ case FFA_FN64_MEM_SHARE:
+ case FFA_MEM_RECLAIM:
+ case FFA_MEM_LEND:
+ case FFA_FN64_MEM_LEND:
+ case FFA_MEM_FRAG_TX:
+
+ /* State management */
+ case FFA_RUN:
+
+ /* Message passing */
case FFA_MSG_SEND_DIRECT_REQ:
- case FFA_MSG_SEND_DIRECT_RESP:
- case FFA_RXTX_MAP:
- case FFA_MEM_DONATE:
- case FFA_MEM_RETRIEVE_REQ:
- return false;
+ case FFA_FN64_MSG_SEND_DIRECT_REQ:
+ return true;
}
- return true;
+ return false;
}
static bool do_ffa_features(struct arm_smccc_res *res,
--
2.44.0.396.g6e790dbe36-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] KVM: arm64: Fix the identification range for the FF-A smcs
From: Sebastian Ene @ 2024-03-22 12:43 UTC (permalink / raw)
To: catalin.marinas, james.morse, jean-philippe, maz, oliver.upton,
qperret, qwandor, sebastianene, suzuki.poulose, tabba, will,
yuzenghui
Cc: kvmarm, linux-arm-kernel, linux-kernel, kernel-team
The FF-A spec 1.2 reserves the following ranges for identifying FF-A
calls:
0x84000060-0x840000FF: FF-A 32-bit calls
0xC4000060-0xC40000FF: FF-A 64-bit calls.
Use the range identification according to the spec and allow calls that
are currently out of the range(eg. FFA_MSG_SEND_DIRECT_REQ2) to be
identified correctly.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/include/nvhe/ffa.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/include/nvhe/ffa.h b/arch/arm64/kvm/hyp/include/nvhe/ffa.h
index d9fd5e6c7d3c..146e0aebfa1c 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/ffa.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/ffa.h
@@ -9,7 +9,7 @@
#include <asm/kvm_host.h>
#define FFA_MIN_FUNC_NUM 0x60
-#define FFA_MAX_FUNC_NUM 0x7F
+#define FFA_MAX_FUNC_NUM 0xFF
int hyp_ffa_init(void *pages);
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id);
--
2.44.0.396.g6e790dbe36-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [v10,20/27] drm/connector: hdmi: Add Infoframes generation
From: Maxime Ripard @ 2024-03-22 12:31 UTC (permalink / raw)
To: Sui Jingfeng
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Daniel Vetter,
Jonathan Corbet, Sandy Huang, Heiko Stübner, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Hans Verkuil, Sebastian Wick,
Ville Syrjälä, dri-devel, linux-arm-kernel, linux-doc,
linux-kernel, linux-media, linux-rockchip, linux-sunxi
In-Reply-To: <7835e928-7d09-446e-91dd-13a0fa549bc2@linux.dev>
[-- Attachment #1.1: Type: text/plain, Size: 717 bytes --]
On Fri, Mar 22, 2024 at 07:13:54PM +0800, Sui Jingfeng wrote:
> Hi,
>
>
> On 2024/3/22 18:31, Maxime Ripard wrote:
> > Which default config are you talking about? This compiles fine with all
> > drm-misc defconfig, x86 defconfig and allmodconfig.
>
> The drm_hdmi_avi_infoframe_colorimetry() function is belong to the drm_display_helper.ko
> kernel module, it get called from hdmi_generate_avi_infoframe() in drm_atomic_state_helper.c.
> While drm_atomic_state_helper.c belongs to drm_kms_helper.ko. Therefore drm_kms_helper.ko
> is dependent on drm_display_helper.ko implicitly. So we probably should select it.
Right. I was asking which config are you using to generate that build error
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 05/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
From: Jason Gunthorpe @ 2024-03-22 12:28 UTC (permalink / raw)
To: peterx
Cc: linux-mm, linux-kernel, linuxppc-dev, Michael Ellerman,
Christophe Leroy, Matthew Wilcox, Rik van Riel, Lorenzo Stoakes,
Axel Rasmussen, Yang Shi, John Hubbard, linux-arm-kernel,
Kirill A . Shutemov, Andrew Jones, Vlastimil Babka, Mike Rapoport,
Andrew Morton, Muchun Song, Christoph Hellwig, linux-riscv,
James Houghton, David Hildenbrand, Andrea Arcangeli,
Aneesh Kumar K . V, Mike Kravetz
In-Reply-To: <20240321220802.679544-6-peterx@redhat.com>
On Thu, Mar 21, 2024 at 06:07:55PM -0400, peterx@redhat.com wrote:
> From: Peter Xu <peterx@redhat.com>
>
> Hugepd format for GUP is only used in PowerPC with hugetlbfs. There are
> some kernel usage of hugepd (can refer to hugepd_populate_kernel() for
> PPC_8XX), however those pages are not candidates for GUP.
>
> Commit a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to
> file-backed mappings") added a check to fail gup-fast if there's potential
> risk of violating GUP over writeback file systems. That should never apply
> to hugepd. Considering that hugepd is an old format (and even
> software-only), there's no plan to extend hugepd into other file typed
> memories that is prone to the same issue.
>
> Drop that check, not only because it'll never be true for hugepd per any
> known plan, but also it paves way for reusing the function outside
> fast-gup.
>
> To make sure we'll still remember this issue just in case hugepd will be
> extended to support non-hugetlbfs memories, add a rich comment above
> gup_huge_pd(), explaining the issue with proper references.
>
> Cc: Christoph Hellwig <hch@infradead.org>
> Cc: Lorenzo Stoakes <lstoakes@gmail.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
> mm/gup.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 04/12] mm: Introduce vma_pgtable_walk_{begin|end}()
From: Jason Gunthorpe @ 2024-03-22 12:27 UTC (permalink / raw)
To: peterx
Cc: linux-mm, linux-kernel, linuxppc-dev, Michael Ellerman,
Christophe Leroy, Matthew Wilcox, Rik van Riel, Lorenzo Stoakes,
Axel Rasmussen, Yang Shi, John Hubbard, linux-arm-kernel,
Kirill A . Shutemov, Andrew Jones, Vlastimil Babka, Mike Rapoport,
Andrew Morton, Muchun Song, Christoph Hellwig, linux-riscv,
James Houghton, David Hildenbrand, Andrea Arcangeli,
Aneesh Kumar K . V, Mike Kravetz
In-Reply-To: <20240321220802.679544-5-peterx@redhat.com>
On Thu, Mar 21, 2024 at 06:07:54PM -0400, peterx@redhat.com wrote:
> From: Peter Xu <peterx@redhat.com>
>
> Introduce per-vma begin()/end() helpers for pgtable walks. This is a
> preparation work to merge hugetlb pgtable walkers with generic mm.
>
> The helpers need to be called before and after a pgtable walk, will start
> to be needed if the pgtable walker code supports hugetlb pages. It's a
> hook point for any type of VMA, but for now only hugetlb uses it to
> stablize the pgtable pages from getting away (due to possible pmd
> unsharing).
>
> Reviewed-by: Christoph Hellwig <hch@infradead.org>
> Reviewed-by: Muchun Song <muchun.song@linux.dev>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
> include/linux/mm.h | 3 +++
> mm/memory.c | 12 ++++++++++++
> 2 files changed, 15 insertions(+)
is_vm_hugetlb_page(vma) seems weirdly named. Regardless
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: dt-bindings: fsl-asoc-card: convert to YAML
From: Rob Herring @ 2024-03-22 12:27 UTC (permalink / raw)
To: Shengjiu Wang
Cc: shengjiu.wang, broonie, linux-arm-kernel, shawnguo, robh+dt,
kernel, conor+dt, krzysztof.kozlowski+dt, lgirdwood, linux-sound,
devicetree, linux-kernel, imx, s.hauer, festevam
In-Reply-To: <1711102406-8399-2-git-send-email-shengjiu.wang@nxp.com>
On Fri, 22 Mar 2024 18:13:25 +0800, Shengjiu Wang wrote:
> Convert the fsl-asoc-card binding to YAML.
>
> In order to pass the checking, add some used compatible
> string from devicetree.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> .../bindings/sound/fsl-asoc-card.txt | 117 -----------
> .../bindings/sound/fsl-asoc-card.yaml | 196 ++++++++++++++++++
> 2 files changed, 196 insertions(+), 117 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
> create mode 100644 Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
Warning: Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml references a file that doesn't exist: Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml
Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml: Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/1711102406-8399-2-git-send-email-shengjiu.wang@nxp.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
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 after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] power: reset: add new gs101-poweroff driver
From: Peter Griffin @ 2024-03-22 12:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alexey Klimov, sre, robh, krzysztof.kozlowski+dt, linux-pm,
devicetree, robh+dt, conor+dt, linux-samsung-soc, semen.protsenko,
linux-kernel, klimov.linux, kernel-team, tudor.ambarus,
andre.draszik, saravanak, willmcvicker, alim.akhtar,
linux-arm-kernel, elder
In-Reply-To: <4d5b2da7-2a45-4a9f-8a96-a6840d2751a2@linaro.org>
Hi Krzysztof,
Thanks for your review feedback!
On Wed, 20 Mar 2024 at 07:20, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 20/03/2024 03:05, Alexey Klimov wrote:
> > +
> > + ret = devm_work_autocancel(dev, &gs101->shutdown_work,
> > + gs101_shutdown_work_fn);
> > + if (ret) {
> > + dev_err(dev, "failed to register gs101 shutdown_work: %i\n", ret);
> > + unregister_keyboard_notifier(&gs101->keyboard_nb);
> > + return ret;
> > + }
> > +
> > + gs101_poweroff_ctx = gs101;
> > + platform_set_drvdata(pdev, gs101);
> > +
> > + /*
> > + * At this point there is a chance that psci_sys_poweroff already
> > + * registered as pm_power_off hook but unfortunately it cannot power
> > + * off the gs101 SoC hence we are rewriting it here just as is.
> > + */
> > + pm_power_off = gs101_poweroff;
>
> So that's a duplicated syscon power off driver. Why syscon does not
> work? syscon_node_to_regmap() does not return correct regmap?
Yes, for gs101 the regmap handling PMU registers is now created by
exynos-pmu driver and is obtained using
exynos_get_pmu_regmap_by_phandle() API. That was required due to the
SMC call required to write to these registers from Linux.
> If so,
> this should be fixed instead of copying the driver with basically only
> one difference.
Are you suggesting we should add some API to syscon.c that allows
regmaps created in other drivers like exynos-pmu.c or altera-sysmgr.c
to be registered in the syscon_list?
Thanks,
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 8/8] PCI: dwc: ep: Remove "core_init_notifier" flag
From: Niklas Cassel @ 2024-03-22 11:53 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Jingoo Han, Gustavo Pimentel, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Marek Vasut, Yoshihiro Shimoda, Thierry Reding, Jonathan Hunter,
Kishon Vijay Abraham I, Vidya Sagar, Vignesh Raghavendra,
Richard Zhu, Lucas Stach, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Minghuan Lian, Mingkai Hu, Roy Zang, Kunihiko Hayashi,
Masami Hiramatsu, Kishon Vijay Abraham I, Jesper Nilsson,
Srikanth Thokala, linux-pci, linux-kernel, linux-renesas-soc,
linux-arm-msm, linux-tegra, linux-omap, linux-arm-kernel,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20240314-pci-dbi-rework-v10-8-14a45c5a938e@linaro.org>
On Thu, Mar 14, 2024 at 01:18:06PM +0530, Manivannan Sadhasivam wrote:
> "core_init_notifier" flag is set by the glue drivers requiring refclk from
> the host to complete the DWC core initialization. Also, those drivers will
> send a notification to the EPF drivers once the initialization is fully
> completed using the pci_epc_init_notify() API. Only then, the EPF drivers
> will start functioning.
>
> For the rest of the drivers generating refclk locally, EPF drivers will
> start functioning post binding with them. EPF drivers rely on the
> 'core_init_notifier' flag to differentiate between the drivers.
> Unfortunately, this creates two different flows for the EPF drivers.
>
> So to avoid that, let's get rid of the "core_init_notifier" flag and follow
> a single initialization flow for the EPF drivers. This is done by calling
> the dw_pcie_ep_init_notify() from all glue drivers after the completion of
> dw_pcie_ep_init_registers() API. This will allow all the glue drivers to
> send the notification to the EPF drivers once the initialization is fully
> completed.
>
> Only difference here is that, the drivers requiring refclk from host will
> send the notification once refclk is received, while others will send it
> during probe time itself.
>
> But this also requires the EPC core driver to deliver the notification
> after EPF driver bind. Because, the glue driver can send the notification
> before the EPF drivers bind() and in those cases the EPF drivers will miss
> the event. To accommodate this, EPC core is now caching the state of the
> EPC initialization in 'init_complete' flag and pci-ep-cfs driver sends the
> notification to EPF drivers based on that after each EPF driver bind.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> drivers/pci/controller/dwc/pci-dra7xx.c | 2 ++
> drivers/pci/controller/dwc/pci-imx6.c | 2 ++
> drivers/pci/controller/dwc/pci-keystone.c | 2 ++
> drivers/pci/controller/dwc/pci-layerscape-ep.c | 2 ++
> drivers/pci/controller/dwc/pcie-artpec6.c | 2 ++
> drivers/pci/controller/dwc/pcie-designware-plat.c | 2 ++
> drivers/pci/controller/dwc/pcie-keembay.c | 2 ++
> drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 -
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 2 ++
> drivers/pci/controller/dwc/pcie-tegra194.c | 1 -
> drivers/pci/controller/dwc/pcie-uniphier-ep.c | 2 ++
> drivers/pci/endpoint/functions/pci-epf-test.c | 18 +++++-------------
> drivers/pci/endpoint/pci-ep-cfs.c | 9 +++++++++
> drivers/pci/endpoint/pci-epc-core.c | 22 ++++++++++++++++++++++
> include/linux/pci-epc.h | 7 ++++---
> 15 files changed, 58 insertions(+), 18 deletions(-)
FWIW:
Tested-by: Niklas Cassel <cassel@kernel.org>
However, when looking at this, I was surprised that you never call something
that will set:
init_complete = false;
from e.g. dw_pcie_ep_deinit() or dw_pcie_ep_cleanup().
I saw that you do seem to set
init_complete = false;
in your other follow up series that is based on this one.
What will happen if you run with only this series merged (without your
follow up series), on a platform that used to have .core_init_notifier?
If you do remove and recreate the symlink on a platform with external
refclk, since you never set init_complete to false, you could trigger
EPF core_init callback, e.g. pci_epf_test_core_init() to be called,
which will do DBI writes even when there is no refclk.
E.g. (on a platform with external refclk):
1) Create symlink to pci-epf-test in configfs.
2) Start RC, your EPC driver will call ep_init_notifiy() when perst
deasserts.
3) Run pci-epf-test.
4) Remove the pci-epf-test symlink
5) Shutdown RC
6) Create symlink to pci-epf-test in configfs.
This will see that init_complete is true, and will do DBI writes
which will crash your system, since you don't have a refclk.
Perhaps you should move the patch that calls a function that sets
init_complete = false;
to this series, so that this crash is not possible?
>
> diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c b/drivers/pci/controller/dwc/pci-dra7xx.c
> index 395042b29ffc..d2d17d37d3e0 100644
> --- a/drivers/pci/controller/dwc/pci-dra7xx.c
> +++ b/drivers/pci/controller/dwc/pci-dra7xx.c
> @@ -474,6 +474,8 @@ static int dra7xx_add_pcie_ep(struct dra7xx_pcie *dra7xx,
> return ret;
> }
>
> + dw_pcie_ep_init_notify(ep);
> +
> return 0;
> }
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index bfcafa440ddb..894b5de76e3a 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -1144,6 +1144,8 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
> return ret;
> }
>
> + dw_pcie_ep_init_notify(ep);
> +
> /* Start LTSSM. */
> imx6_pcie_ltssm_enable(dev);
>
> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
> index 093dbb725e41..b7b30470b394 100644
> --- a/drivers/pci/controller/dwc/pci-keystone.c
> +++ b/drivers/pci/controller/dwc/pci-keystone.c
> @@ -1293,6 +1293,8 @@ static int ks_pcie_probe(struct platform_device *pdev)
> goto err_ep_init;
> }
>
> + dw_pcie_ep_init_notify(&pci->ep);
> +
> break;
> default:
> dev_err(dev, "INVALID device type %d\n", mode);
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index b712fdd06549..c513598a46d7 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -283,6 +283,8 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
> return ret;
> }
>
> + dw_pcie_ep_init_notify(&pci->ep);
> +
> return ls_pcie_ep_interrupt_init(pcie, pdev);
> }
>
> diff --git a/drivers/pci/controller/dwc/pcie-artpec6.c b/drivers/pci/controller/dwc/pcie-artpec6.c
> index a6095561db4a..a4630b92489b 100644
> --- a/drivers/pci/controller/dwc/pcie-artpec6.c
> +++ b/drivers/pci/controller/dwc/pcie-artpec6.c
> @@ -452,6 +452,8 @@ static int artpec6_pcie_probe(struct platform_device *pdev)
> return ret;
> }
>
> + dw_pcie_ep_init_notify(&pci->ep);
> +
> break;
> default:
> dev_err(dev, "INVALID device type %d\n", artpec6_pcie->mode);
> diff --git a/drivers/pci/controller/dwc/pcie-designware-plat.c b/drivers/pci/controller/dwc/pcie-designware-plat.c
> index ca9b22e654cd..8490c5d6ff9f 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-plat.c
> @@ -154,6 +154,8 @@ static int dw_plat_pcie_probe(struct platform_device *pdev)
> dw_pcie_ep_deinit(&pci->ep);
> }
>
> + dw_pcie_ep_init_notify(&pci->ep);
> +
> break;
> default:
> dev_err(dev, "INVALID device type %d\n", dw_plat_pcie->mode);
> diff --git a/drivers/pci/controller/dwc/pcie-keembay.c b/drivers/pci/controller/dwc/pcie-keembay.c
> index 250d6acf16dc..9fa9354a5f48 100644
> --- a/drivers/pci/controller/dwc/pcie-keembay.c
> +++ b/drivers/pci/controller/dwc/pcie-keembay.c
> @@ -438,6 +438,8 @@ static int keembay_pcie_probe(struct platform_device *pdev)
> return ret;
> }
>
> + dw_pcie_ep_init_notify(&pci->ep);
> +
> break;
> default:
> dev_err(dev, "Invalid device type %d\n", pcie->mode);
> diff --git a/drivers/pci/controller/dwc/pcie-qcom-ep.c b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> index 3697b4a944cc..2fb8c15e7a91 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> @@ -775,7 +775,6 @@ static void qcom_pcie_ep_init_debugfs(struct qcom_pcie_ep *pcie_ep)
>
> static const struct pci_epc_features qcom_pcie_epc_features = {
> .linkup_notifier = true,
> - .core_init_notifier = true,
> .msi_capable = true,
> .msix_capable = false,
> .align = SZ_4K,
> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index fb7c03639a53..0448928017f3 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> @@ -435,6 +435,8 @@ static int rcar_gen4_add_dw_pcie_ep(struct rcar_gen4_pcie *rcar)
> rcar_gen4_pcie_ep_deinit(rcar);
> }
>
> + dw_pcie_ep_init_notify(ep);
> +
> return ret;
> }
>
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 264ee76bf008..e02deb31a72d 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -2006,7 +2006,6 @@ static int tegra_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
>
> static const struct pci_epc_features tegra_pcie_epc_features = {
> .linkup_notifier = true,
> - .core_init_notifier = true,
> .msi_capable = false,
> .msix_capable = false,
> .reserved_bar = 1 << BAR_2 | 1 << BAR_3 | 1 << BAR_4 | 1 << BAR_5,
> diff --git a/drivers/pci/controller/dwc/pcie-uniphier-ep.c b/drivers/pci/controller/dwc/pcie-uniphier-ep.c
> index 82ccaea089be..eb1d79fdb1f1 100644
> --- a/drivers/pci/controller/dwc/pcie-uniphier-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-uniphier-ep.c
> @@ -410,6 +410,8 @@ static int uniphier_pcie_ep_probe(struct platform_device *pdev)
> return ret;
> }
>
> + dw_pcie_ep_init_notify(&priv->pci.ep);
> +
> return 0;
> }
>
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 18c80002d3bd..fc0282b0d626 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -753,6 +753,7 @@ static int pci_epf_test_core_init(struct pci_epf *epf)
> const struct pci_epc_features *epc_features;
> struct pci_epc *epc = epf->epc;
> struct device *dev = &epf->dev;
> + bool linkup_notifier = false;
> bool msix_capable = false;
> bool msi_capable = true;
> int ret;
> @@ -795,6 +796,10 @@ static int pci_epf_test_core_init(struct pci_epf *epf)
> }
> }
>
> + linkup_notifier = epc_features->linkup_notifier;
> + if (!linkup_notifier)
> + queue_work(kpcitest_workqueue, &epf_test->cmd_handler.work);
> +
> return 0;
> }
>
> @@ -901,8 +906,6 @@ static int pci_epf_test_bind(struct pci_epf *epf)
> const struct pci_epc_features *epc_features;
> enum pci_barno test_reg_bar = BAR_0;
> struct pci_epc *epc = epf->epc;
> - bool linkup_notifier = false;
> - bool core_init_notifier = false;
>
> if (WARN_ON_ONCE(!epc))
> return -EINVAL;
> @@ -913,8 +916,6 @@ static int pci_epf_test_bind(struct pci_epf *epf)
> return -EOPNOTSUPP;
> }
>
> - linkup_notifier = epc_features->linkup_notifier;
> - core_init_notifier = epc_features->core_init_notifier;
> test_reg_bar = pci_epc_get_first_free_bar(epc_features);
> if (test_reg_bar < 0)
> return -EINVAL;
> @@ -927,21 +928,12 @@ static int pci_epf_test_bind(struct pci_epf *epf)
> if (ret)
> return ret;
>
> - if (!core_init_notifier) {
> - ret = pci_epf_test_core_init(epf);
> - if (ret)
> - return ret;
> - }
> -
While you did fix up all DWC based drivers, the non-DWC EPC drivers that
did not have epc_features->core_init_notifier before this patch:
drivers/pci/controller/cadence/pcie-cadence-ep.c:#include <linux/pci-epc.h>
drivers/pci/controller/pcie-rcar-ep.c:#include <linux/pci-epc.h>
drivers/pci/controller/pcie-rockchip-ep.c:#include <linux/pci-epc.h>
I don't think that they will work with pci-epf-test anymore, since AFAICT,
you did not add a call to: pci_epc_init_notify() or similar in these EPC drivers.
(Like this patch does to all the DWC-based drivers without a core_init_notifier.)
Kind regards,
Niklas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1] arm64: mm: swap: support THP_SWAP on hardware with MTE
From: Barry Song @ 2024-03-22 11:41 UTC (permalink / raw)
To: catalin.marinas, will, akpm, hughd, linux-mm, linux-arm-kernel
Cc: chrisl, mark.rutland, ryan.roberts, steven.price, david, willy,
Barry Song, Kemeng Shi, Anshuman Khandual, Peter Collingbourne,
Yosry Ahmed, Peter Xu, Lorenzo Stoakes, Mike Rapoport (IBM),
Aneesh Kumar K.V, Rick Edgecombe
In-Reply-To: <20240322114136.61386-1-21cnbao@gmail.com>
From: Barry Song <v-songbaohua@oppo.com>
Commit d0637c505f8a1 ("arm64: enable THP_SWAP for arm64") brings up
THP_SWAP on ARM64, but it doesn't enable THP_SWP on hardware with
MTE as the MTE code works with the assumption tags save/restore is
always handling a folio with only one page.
The limitation should be removed as more and more ARM64 SoCs have
this feature. Co-existence of MTE and THP_SWAP becomes more and
more important.
This patch makes MTE tags saving support large folios, then we don't
need to split large folios into base pages for swapping out on ARM64
SoCs with MTE any more.
arch_prepare_to_swap() should take folio rather than page as parameter
because we support THP swap-out as a whole. It saves tags for all
pages in a large folio.
As now we are restoring tags based-on folio, in arch_swap_restore(),
we may increase some extra loops and early-exitings while refaulting
a large folio which is still in swapcache in do_swap_page(). In case
a large folio has nr pages, do_swap_page() will only set the PTE of
the particular page which is causing the page fault.
Thus do_swap_page() runs nr times, and each time, arch_swap_restore()
will loop nr times for those subpages in the folio. So right now the
algorithmic complexity becomes O(nr^2).
Once we support mapping large folios in do_swap_page(), extra loops
and early-exitings will decrease while not being completely removed
as a large folio might get partially tagged in corner cases such as,
1. a large folio in swapcache can be partially unmapped, thus, MTE
tags for the unmapped pages will be invalidated;
2. users might use mprotect() to set MTEs on a part of a large folio.
arch_thp_swp_supported() is dropped since ARM64 MTE was the only one
who needed it.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Kemeng Shi <shikemeng@huaweicloud.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Steven Price <steven.price@arm.com>
Cc: Yosry Ahmed <yosryahmed@google.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: "Mike Rapoport (IBM)" <rppt@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
CC: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Barry Song <v-songbaohua@oppo.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Chris Li <chrisl@kernel.org>
---
arch/arm64/include/asm/pgtable.h | 19 ++------------
arch/arm64/mm/mteswap.c | 45 ++++++++++++++++++++++++++++++++
include/linux/huge_mm.h | 12 ---------
include/linux/pgtable.h | 2 +-
mm/internal.h | 14 ++++++++++
mm/memory.c | 2 +-
mm/page_io.c | 2 +-
mm/shmem.c | 2 +-
mm/swap_slots.c | 2 +-
mm/swapfile.c | 2 +-
10 files changed, 67 insertions(+), 35 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index afdd56d26ad7..259325e6b7e8 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -49,12 +49,6 @@
__flush_tlb_range(vma, addr, end, PUD_SIZE, false, 1)
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
-static inline bool arch_thp_swp_supported(void)
-{
- return !system_supports_mte();
-}
-#define arch_thp_swp_supported arch_thp_swp_supported
-
/*
* Outside of a few very special situations (e.g. hibernation), we always
* use broadcast TLB invalidation instructions, therefore a spurious page
@@ -1280,12 +1274,7 @@ static inline pmd_t pmdp_establish(struct vm_area_struct *vma,
#ifdef CONFIG_ARM64_MTE
#define __HAVE_ARCH_PREPARE_TO_SWAP
-static inline int arch_prepare_to_swap(struct page *page)
-{
- if (system_supports_mte())
- return mte_save_tags(page);
- return 0;
-}
+extern int arch_prepare_to_swap(struct folio *folio);
#define __HAVE_ARCH_SWAP_INVALIDATE
static inline void arch_swap_invalidate_page(int type, pgoff_t offset)
@@ -1301,11 +1290,7 @@ static inline void arch_swap_invalidate_area(int type)
}
#define __HAVE_ARCH_SWAP_RESTORE
-static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
-{
- if (system_supports_mte())
- mte_restore_tags(entry, &folio->page);
-}
+extern void arch_swap_restore(swp_entry_t entry, struct folio *folio);
#endif /* CONFIG_ARM64_MTE */
diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c
index a31833e3ddc5..63e8d72f202a 100644
--- a/arch/arm64/mm/mteswap.c
+++ b/arch/arm64/mm/mteswap.c
@@ -68,6 +68,13 @@ void mte_invalidate_tags(int type, pgoff_t offset)
mte_free_tag_storage(tags);
}
+static inline void __mte_invalidate_tags(struct page *page)
+{
+ swp_entry_t entry = page_swap_entry(page);
+
+ mte_invalidate_tags(swp_type(entry), swp_offset(entry));
+}
+
void mte_invalidate_tags_area(int type)
{
swp_entry_t entry = swp_entry(type, 0);
@@ -83,3 +90,41 @@ void mte_invalidate_tags_area(int type)
}
xa_unlock(&mte_pages);
}
+
+int arch_prepare_to_swap(struct folio *folio)
+{
+ long i, nr;
+ int err;
+
+ if (!system_supports_mte())
+ return 0;
+
+ nr = folio_nr_pages(folio);
+
+ for (i = 0; i < nr; i++) {
+ err = mte_save_tags(folio_page(folio, i));
+ if (err)
+ goto out;
+ }
+ return 0;
+
+out:
+ while (i--)
+ __mte_invalidate_tags(folio_page(folio, i));
+ return err;
+}
+
+void arch_swap_restore(swp_entry_t entry, struct folio *folio)
+{
+ long i, nr;
+
+ if (!system_supports_mte())
+ return;
+
+ nr = folio_nr_pages(folio);
+
+ for (i = 0; i < nr; i++) {
+ mte_restore_tags(entry, folio_page(folio, i));
+ entry.val++;
+ }
+}
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index de0c89105076..e04b93c43965 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -535,16 +535,4 @@ static inline int split_folio_to_order(struct folio *folio, int new_order)
#define split_folio_to_list(f, l) split_folio_to_list_to_order(f, l, 0)
#define split_folio(f) split_folio_to_order(f, 0)
-/*
- * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to
- * limitations in the implementation like arm64 MTE can override this to
- * false
- */
-#ifndef arch_thp_swp_supported
-static inline bool arch_thp_swp_supported(void)
-{
- return true;
-}
-#endif
-
#endif /* _LINUX_HUGE_MM_H */
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 85fc7554cd52..b10a7dd615bd 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1052,7 +1052,7 @@ static inline int arch_unmap_one(struct mm_struct *mm,
* prototypes must be defined in the arch-specific asm/pgtable.h file.
*/
#ifndef __HAVE_ARCH_PREPARE_TO_SWAP
-static inline int arch_prepare_to_swap(struct page *page)
+static inline int arch_prepare_to_swap(struct folio *folio)
{
return 0;
}
diff --git a/mm/internal.h b/mm/internal.h
index 7e486f2c502c..2551e93dd885 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -76,6 +76,20 @@ static inline int folio_nr_pages_mapped(struct folio *folio)
return atomic_read(&folio->_nr_pages_mapped) & FOLIO_PAGES_MAPPED;
}
+/*
+ * Retrieve the first entry of a folio based on a provided entry within the
+ * folio. We cannot rely on folio->swap as there is no guarantee that it has
+ * been initialized. Used for calling arch_swap_restore()
+ */
+static inline swp_entry_t folio_swap(swp_entry_t entry, struct folio *folio)
+{
+ swp_entry_t swap = {
+ .val = ALIGN_DOWN(entry.val, folio_nr_pages(folio)),
+ };
+
+ return swap;
+}
+
static inline void *folio_raw_mapping(struct folio *folio)
{
unsigned long mapping = (unsigned long)folio->mapping;
diff --git a/mm/memory.c b/mm/memory.c
index f2bc6dd15eb8..b7cab8be8632 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4188,7 +4188,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
* when reading from swap. This metadata may be indexed by swap entry
* so this must be called before swap_free().
*/
- arch_swap_restore(entry, folio);
+ arch_swap_restore(folio_swap(entry, folio), folio);
/*
* Remove the swap entry and conditionally try to free up the swapcache.
diff --git a/mm/page_io.c b/mm/page_io.c
index ae2b49055e43..a9a7c236aecc 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -189,7 +189,7 @@ int swap_writepage(struct page *page, struct writeback_control *wbc)
* Arch code may have to preserve more data than just the page
* contents, e.g. memory tags.
*/
- ret = arch_prepare_to_swap(&folio->page);
+ ret = arch_prepare_to_swap(folio);
if (ret) {
folio_mark_dirty(folio);
folio_unlock(folio);
diff --git a/mm/shmem.c b/mm/shmem.c
index 0aad0d9a621b..44c1519ba881 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1913,7 +1913,7 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
* Some architectures may have to restore extra metadata to the
* folio after reading from swap.
*/
- arch_swap_restore(swap, folio);
+ arch_swap_restore(folio_swap(swap, folio), folio);
if (shmem_should_replace_folio(folio, gfp)) {
error = shmem_replace_folio(&folio, gfp, info, index);
diff --git a/mm/swap_slots.c b/mm/swap_slots.c
index 90973ce7881d..53abeaf1371d 100644
--- a/mm/swap_slots.c
+++ b/mm/swap_slots.c
@@ -310,7 +310,7 @@ swp_entry_t folio_alloc_swap(struct folio *folio)
entry.val = 0;
if (folio_test_large(folio)) {
- if (IS_ENABLED(CONFIG_THP_SWAP) && arch_thp_swp_supported())
+ if (IS_ENABLED(CONFIG_THP_SWAP))
get_swap_pages(1, &entry, folio_nr_pages(folio));
goto out;
}
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 4919423cce76..5e6d2304a2a4 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1806,7 +1806,7 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd,
* when reading from swap. This metadata may be indexed by swap entry
* so this must be called before swap_free().
*/
- arch_swap_restore(entry, folio);
+ arch_swap_restore(folio_swap(entry, folio), folio);
dec_mm_counter(vma->vm_mm, MM_SWAPENTS);
inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [v10,20/27] drm/connector: hdmi: Add Infoframes generation
From: Jani Nikula @ 2024-03-22 11:46 UTC (permalink / raw)
To: Maxime Ripard
Cc: Sui Jingfeng, Maarten Lankhorst, Thomas Zimmermann, David Airlie,
Daniel Vetter, Jonathan Corbet, Sandy Huang, Heiko Stübner,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Hans Verkuil,
Sebastian Wick, Ville Syrjälä, dri-devel,
linux-arm-kernel, linux-doc, linux-kernel, linux-media,
linux-rockchip, linux-sunxi
In-Reply-To: <20240322-petite-fabulous-bustard-b168ec@houat>
On Fri, 22 Mar 2024, Maxime Ripard <mripard@kernel.org> wrote:
> On Fri, Mar 22, 2024 at 11:22:14AM +0200, Jani Nikula wrote:
>> On Fri, 22 Mar 2024, Sui Jingfeng <sui.jingfeng@linux.dev> wrote:
>> > Hi,
>> >
>> >
>> > On 2024/3/21 23:29, Maxime Ripard wrote:
>> >> Infoframes in KMS is usually handled by a bunch of low-level helpers
>> >> that require quite some boilerplate for drivers. This leads to
>> >> discrepancies with how drivers generate them, and which are actually
>> >> sent.
>> >>
>> >> Now that we have everything needed to generate them in the HDMI
>> >> connector state, we can generate them in our common logic so that
>> >> drivers can simply reuse what we precomputed.
>> >>
>> >> Signed-off-by: Maxime Ripard <mripard@kernel.org>
>> >> ---
>> >> drivers/gpu/drm/Kconfig | 1 +
>> >> drivers/gpu/drm/drm_atomic_state_helper.c | 338 +++++++++++++++++++++
>> >> drivers/gpu/drm/drm_connector.c | 14 +
>> >> .../gpu/drm/tests/drm_atomic_state_helper_test.c | 1 +
>> >> drivers/gpu/drm/tests/drm_connector_test.c | 12 +
>> >> include/drm/drm_atomic_state_helper.h | 8 +
>> >> include/drm/drm_connector.h | 109 +++++++
>> >> 7 files changed, 483 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> >> index 16029435b750..3d3193c7aa5f 100644
>> >> --- a/drivers/gpu/drm/Kconfig
>> >> +++ b/drivers/gpu/drm/Kconfig
>> >> @@ -97,10 +97,11 @@ config DRM_KUNIT_TEST
>> >> If in doubt, say "N".
>> >>
>> >> config DRM_KMS_HELPER
>> >> tristate
>> >> depends on DRM
>> >> + select DRM_DISPLAY_HDMI_HELPER
>> >
>> > Should we select DRM_DISPLAY_HELPER here? Otherwise there will have some compile error
>> > emerged with default config.
>>
>> Can we stop abusing select instead of adding more selects to paper over
>> the issues?
>>
>> Use select only for non-visible symbols (no prompts anywhere) and for
>> symbols with no dependencies.
>
> I don't really have an opinion there, but it looks like all the other
> helpers Kconfig symbols are using select everywhere, and I don't really
> see how we could turn them into visible symbols with depends on without
> breaking a number of defconfig.
>
> Could you expand a bit what you have in mind here?
Just my standard grumbling about the rampant select abuse.
Maybe one day someone takes the hint and starts fixing things up. :p
See the note under "reverse dependencies" at [1].
BR,
Jani.
[1] https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes
--
Jani Nikula, Intel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/1] THP_SWAP support for ARM64 SoC with MTE
From: Barry Song @ 2024-03-22 11:41 UTC (permalink / raw)
To: catalin.marinas, will, akpm, hughd, linux-mm, linux-arm-kernel
Cc: chrisl, mark.rutland, ryan.roberts, steven.price, david, willy,
Barry Song
From: Barry Song <v-songbaohua@oppo.com>
The patch has been extracted from the larger folios swap-in series [1],
incorporating some new modifications.
Introducing THP_SWAP support for ARM64 SoCs with MTE is essential, particularly
due to its significance for widely used ARM64 products in the market. Without
this support, Ryan's mTHP swap-out without splitting series won't operate
effectively on these SoCs.
Therefore, it's imperative for this update to be implemented sooner
rather than later.
There are a couple of differences with the code in [1]:
1. minor code cleanup, Ryan
2. always pass the first swap entry of a folio to arch_swap_restore, Ryan
[1] https://lore.kernel.org/linux-mm/20240304081348.197341-2-21cnbao@gmail.com/
Barry Song (1):
arm64: mm: swap: support THP_SWAP on hardware with MTE
arch/arm64/include/asm/pgtable.h | 19 ++------------
arch/arm64/mm/mteswap.c | 45 ++++++++++++++++++++++++++++++++
include/linux/huge_mm.h | 12 ---------
include/linux/pgtable.h | 2 +-
mm/internal.h | 14 ++++++++++
mm/memory.c | 2 +-
mm/page_io.c | 2 +-
mm/shmem.c | 2 +-
mm/swap_slots.c | 2 +-
mm/swapfile.c | 2 +-
10 files changed, 67 insertions(+), 35 deletions(-)
Appendix
I also have a small test program specifically designed for running MTE
on a THP that I can share with those who are interested in this subject.
/*
* To be compiled with -march=armv8.5-a+memtag
*/
#include <errno.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/auxv.h>
#include <sys/mman.h>
#include <sys/prctl.h>
/*
* From arch/arm64/include/uapi/asm/hwcap.h
*/
#define HWCAP2_MTE (1 << 18)
/*
* From arch/arm64/include/uapi/asm/mman.h
*/
#define PROT_MTE 0x20
/*
* From include/uapi/linux/prctl.h
*/
#define PR_SET_TAGGED_ADDR_CTRL 55
#define PR_GET_TAGGED_ADDR_CTRL 56
# define PR_TAGGED_ADDR_ENABLE (1UL << 0)
# define PR_MTE_TCF_SHIFT 1
# define PR_MTE_TCF_NONE (0UL << PR_MTE_TCF_SHIFT)
# define PR_MTE_TCF_SYNC (1UL << PR_MTE_TCF_SHIFT)
# define PR_MTE_TCF_ASYNC (2UL << PR_MTE_TCF_SHIFT)
# define PR_MTE_TCF_MASK (3UL << PR_MTE_TCF_SHIFT)
# define PR_MTE_TAG_SHIFT 3
# define PR_MTE_TAG_MASK (0xffffUL << PR_MTE_TAG_SHIFT)
/*
* Insert a random logical tag into the given pointer.
*/
#define insert_random_tag(ptr) ({ \
uint64_t __val; \
asm("irg %0, %1" : "=r" (__val) : "r" (ptr)); \
__val; \
})
/*
* Set the allocation tag on the destination address.
*/
#define set_tag(tagged_addr) do { \
asm volatile("stg %0, [%0]" : : "r" (tagged_addr) : "memory"); \
} while (0)
int main()
{
unsigned char *a, *p[512];
unsigned long page_sz = 4 * 1024UL;
unsigned long mem_sz = 2 * 1024 * 1024UL;
unsigned long hwcap2 = getauxval(AT_HWCAP2);
int i;
if (!(hwcap2 & HWCAP2_MTE))
return EXIT_FAILURE;
if (prctl(PR_SET_TAGGED_ADDR_CTRL,
PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC |
(0xfffe << PR_MTE_TAG_SHIFT),
0, 0, 0)) {
perror("prctl() failed");
return EXIT_FAILURE;
}
a = mmap(0, mem_sz * 2, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (a == MAP_FAILED) {
perror("mmap() failed");
return EXIT_FAILURE;
}
/* make sure a is aligned with 2MiB THP */
a = (unsigned char *)(((unsigned long)a + mem_sz - 1) & ~(mem_sz - 1));
madvise(a, mem_sz, MADV_HUGEPAGE);
memset(a, 0x11, mem_sz);
if (mprotect(a, mem_sz, PROT_READ | PROT_WRITE | PROT_MTE)) {
perror("mprotect() failed");
return EXIT_FAILURE;
}
printf("set tag for each 4KiB page\n");
for (i = 0; i < 512; i++) {
p[i] = a + i * page_sz;
p[i] = (unsigned char *)insert_random_tag(p[i]);
set_tag(p[i]);
p[i][0] = 0x33;
}
printf("swap-out the whole THP\n");
madvise(a, mem_sz, MADV_PAGEOUT);
printf("swap-in each page of the original THP\n");
for (i = 0; i < 512; i++) {
if (p[i][0] != 0x33) {
printf("test fails, unmatched value after swap-in\n");
return EXIT_FAILURE;
}
}
printf("we should get here\n");
for (i = 0; i < 512; i++) {
printf("page :%d val: expect segment fault, is %02x\n", i, p[i][16]);
}
printf("we shouldn't get here\n");
return EXIT_FAILURE;
}
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox