* Re: [PATCH v1 1/6] x86/resctrl: Move __resctrl_sched_in() out-of-line
From: Peter Newman @ 2024-04-08 19:05 UTC (permalink / raw)
To: Reinette Chatre
Cc: Fenghua Yu, James Morse, Stephane Eranian, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Peter Zijlstra, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman,
Daniel Bristot de Oliveira, Valentin Schneider, Uros Bizjak,
Mike Rapoport, Kirill A. Shutemov, Rick Edgecombe, Xin Li,
Babu Moger, Shaopeng Tan, Maciej Wieczor-Retman, Jens Axboe,
Christian Brauner, Oleg Nesterov, Andrew Morton, Tycho Andersen,
Nicholas Piggin, Beau Belgrave, Matthew Wilcox (Oracle),
linux-kernel
In-Reply-To: <d3ef1a5a-a7ee-477c-8697-d64b91726d91@intel.com>
Hi Reinette,
On Sun, Apr 7, 2024 at 12:21 PM Reinette Chatre
<reinette.chatre@intel.com> wrote:
>
> I think this needs more thought. rdt_enable_key is x86 specific now and should not
> be in the fs code. Every architecture will have its own task switch code, with
> __resctrl_sched_in() belonging to x86 and thus not something to be directly called
> from the fs code.
I think we will need to discuss whether __resctrl_sched_in() is really
arch or FS code following the changes in this series. This series
removes the explicit MSR access and James has already provided inline
wrappers for the mon and alloc enable keys[1], so I can only assume
they are architecture-independent in concept.
Thanks!
-Peter
https://lore.kernel.org/r/20240213184438.16675-18-james.morse@arm.com
^ permalink raw reply
* [openeuler:OLK-6.6 6900/7311] drivers/net/ethernet/hisilicon/hns3/hns3_common/hclge_comm_cmd.c:475:60: sparse: sparse: incorrect type in argument 1 (different base types)
From: kernel test robot @ 2024-04-08 19:04 UTC (permalink / raw)
To: kernel, Jiantao Xiao; +Cc: oe-kbuild-all
tree: https://gitee.com/openeuler/kernel.git OLK-6.6
head: 05607873db411ec3c614313b43cec60138c26a99
commit: 676df2864a908565710282838af4f392acb9ebd4 [6900/7311] net: hns3: add command queue trace for hns3
config: loongarch-randconfig-r113-20240408 (https://download.01.org/0day-ci/archive/20240409/202404090328.GBESI86e-lkp@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20240409/202404090328.GBESI86e-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404090328.GBESI86e-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/hisilicon/hns3/hns3_common/hclge_comm_cmd.c:475:60: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short [usertype] opcode @@ got restricted __le16 [usertype] opcode @@
drivers/net/ethernet/hisilicon/hns3/hns3_common/hclge_comm_cmd.c:475:60: sparse: expected unsigned short [usertype] opcode
drivers/net/ethernet/hisilicon/hns3/hns3_common/hclge_comm_cmd.c:475:60: sparse: got restricted __le16 [usertype] opcode
drivers/net/ethernet/hisilicon/hns3/hns3_common/hclge_comm_cmd.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/slab.h, ...):
include/linux/page-flags.h:245:46: sparse: sparse: self-comparison always evaluates to false
--
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c: note: in included file (through include/trace/trace_events.h, include/trace/define_trace.h, ...):
>> drivers/net/ethernet/hisilicon/hns3/hns3pf/./hclge_trace.h:132:1: sparse: sparse: cast to restricted __le32
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c: note: in included file (through include/trace/perf.h, include/trace/define_trace.h, drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_trace.h):
>> drivers/net/ethernet/hisilicon/hns3/hns3pf/./hclge_trace.h:132:1: sparse: sparse: cast to restricted __le32
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c: note: in included file (through include/linux/mmzone.h, include/linux/gfp.h, include/linux/xarray.h, ...):
include/linux/page-flags.h:245:46: sparse: sparse: self-comparison always evaluates to false
vim +475 drivers/net/ethernet/hisilicon/hns3/hns3_common/hclge_comm_cmd.c
462
463 /**
464 * hclge_comm_cmd_send - send command to command queue
465 * @hw: pointer to the hw struct
466 * @desc: prefilled descriptor for describing the command
467 * @num : the number of descriptors to be sent
468 *
469 * This is the main send command for command queue, it
470 * sends the queue, cleans the queue, etc
471 **/
472 int hclge_comm_cmd_send(struct hclge_comm_hw *hw, struct hclge_desc *desc,
473 int num)
474 {
> 475 bool is_special = hclge_comm_is_special_opcode(desc->opcode);
476 struct hclge_comm_cmq_ring *csq = &hw->cmq.csq;
477 int ret;
478 int ntc;
479
480 if (hw->cmq.ops.trace_cmd_send)
481 hw->cmq.ops.trace_cmd_send(hw, desc, num, is_special);
482
483 spin_lock_bh(&hw->cmq.csq.lock);
484
485 if (test_bit(HCLGE_COMM_STATE_CMD_DISABLE, &hw->comm_state)) {
486 spin_unlock_bh(&hw->cmq.csq.lock);
487 return -EBUSY;
488 }
489
490 if (num > hclge_comm_ring_space(&hw->cmq.csq)) {
491 /* If CMDQ ring is full, SW HEAD and HW HEAD may be different,
492 * need update the SW HEAD pointer csq->next_to_clean
493 */
494 csq->next_to_clean =
495 hclge_comm_read_dev(hw, HCLGE_COMM_NIC_CSQ_HEAD_REG);
496 spin_unlock_bh(&hw->cmq.csq.lock);
497 return -EBUSY;
498 }
499
500 /**
501 * Record the location of desc in the ring for this time
502 * which will be use for hardware to write back
503 */
504 ntc = hw->cmq.csq.next_to_use;
505
506 hclge_comm_cmd_copy_desc(hw, desc, num);
507
508 /* Write to hardware */
509 hclge_comm_write_dev(hw, HCLGE_COMM_NIC_CSQ_TAIL_REG,
510 hw->cmq.csq.next_to_use);
511
512 ret = hclge_comm_cmd_check_result(hw, desc, num, ntc);
513
514 spin_unlock_bh(&hw->cmq.csq.lock);
515
516 if (hw->cmq.ops.trace_cmd_get)
517 hw->cmq.ops.trace_cmd_get(hw, desc, num, is_special);
518
519 return ret;
520 }
521
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH net-next 3/3] bonding: no longer use RTNL in bonding_show_queue_id()
From: Eric Dumazet @ 2024-04-08 19:04 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Jay Vosburgh, Andy Gospodarek, netdev, eric.dumazet, Eric Dumazet
In-Reply-To: <20240408190437.2214473-1-edumazet@google.com>
Annotate lockless reads of slave->queue_id.
Annotate writes of slave->queue_id.
Switch bonding_show_queue_id() to rcu_read_lock()
and bond_for_each_slave_rcu().
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/bonding/bond_main.c | 2 +-
drivers/net/bonding/bond_netlink.c | 3 ++-
drivers/net/bonding/bond_options.c | 2 +-
drivers/net/bonding/bond_procfs.c | 2 +-
drivers/net/bonding/bond_sysfs.c | 10 +++++-----
drivers/net/bonding/bond_sysfs_slave.c | 2 +-
6 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 08e9bdbf450afdc103931249259c58a08665dc02..b3a7d60c3a5ca60be1d9eed184ec1dad593a182b 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -5245,7 +5245,7 @@ static inline int bond_slave_override(struct bonding *bond,
/* Find out if any slaves have the same mapping as this skb. */
bond_for_each_slave_rcu(bond, slave, iter) {
- if (slave->queue_id == skb_get_queue_mapping(skb)) {
+ if (READ_ONCE(slave->queue_id) == skb_get_queue_mapping(skb)) {
if (bond_slave_is_up(slave) &&
slave->link == BOND_LINK_UP) {
bond_dev_queue_xmit(bond, skb, slave->dev);
diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
index 29b4c3d1b9b6ff873fe067e80bedf7cb681d18f1..2a6a424806aa603ad8a00ca797e9e22d38bd0435 100644
--- a/drivers/net/bonding/bond_netlink.c
+++ b/drivers/net/bonding/bond_netlink.c
@@ -51,7 +51,8 @@ static int bond_fill_slave_info(struct sk_buff *skb,
slave_dev->addr_len, slave->perm_hwaddr))
goto nla_put_failure;
- if (nla_put_u16(skb, IFLA_BOND_SLAVE_QUEUE_ID, slave->queue_id))
+ if (nla_put_u16(skb, IFLA_BOND_SLAVE_QUEUE_ID,
+ READ_ONCE(slave->queue_id)))
goto nla_put_failure;
if (nla_put_s32(skb, IFLA_BOND_SLAVE_PRIO, slave->prio))
diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
index 4cdbc7e084f4b4cb3b150656aa765531806d8ad9..0cacd7027e352dbf3204d82b7ce1672469a186de 100644
--- a/drivers/net/bonding/bond_options.c
+++ b/drivers/net/bonding/bond_options.c
@@ -1589,7 +1589,7 @@ static int bond_option_queue_id_set(struct bonding *bond,
goto err_no_cmd;
/* Actually set the qids for the slave */
- update_slave->queue_id = qid;
+ WRITE_ONCE(update_slave->queue_id, qid);
out:
return ret;
diff --git a/drivers/net/bonding/bond_procfs.c b/drivers/net/bonding/bond_procfs.c
index 43be458422b3f9448d96383b0fb140837562f446..7edf72ec816abd8b66917bdecd2c93d237629ffa 100644
--- a/drivers/net/bonding/bond_procfs.c
+++ b/drivers/net/bonding/bond_procfs.c
@@ -209,7 +209,7 @@ static void bond_info_show_slave(struct seq_file *seq,
seq_printf(seq, "Permanent HW addr: %*phC\n",
slave->dev->addr_len, slave->perm_hwaddr);
- seq_printf(seq, "Slave queue ID: %d\n", slave->queue_id);
+ seq_printf(seq, "Slave queue ID: %d\n", READ_ONCE(slave->queue_id));
if (BOND_MODE(bond) == BOND_MODE_8023AD) {
const struct port *port = &SLAVE_AD_INFO(slave)->port;
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 75ee7ca369034ef6fa58fc9399b566dd7044fedc..1e13bb17051567e2b5d9451ceef47f2cf1a588ec 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -625,10 +625,9 @@ static ssize_t bonding_show_queue_id(struct device *d,
struct slave *slave;
int res = 0;
- if (!rtnl_trylock())
- return restart_syscall();
+ rcu_read_lock();
- bond_for_each_slave(bond, slave, iter) {
+ bond_for_each_slave_rcu(bond, slave, iter) {
if (res > (PAGE_SIZE - IFNAMSIZ - 6)) {
/* not enough space for another interface_name:queue_id pair */
if ((PAGE_SIZE - res) > 10)
@@ -637,12 +636,13 @@ static ssize_t bonding_show_queue_id(struct device *d,
break;
}
res += sysfs_emit_at(buf, res, "%s:%d ",
- slave->dev->name, slave->queue_id);
+ slave->dev->name,
+ READ_ONCE(slave->queue_id));
}
if (res)
buf[res-1] = '\n'; /* eat the leftover space */
- rtnl_unlock();
+ rcu_read_unlock();
return res;
}
diff --git a/drivers/net/bonding/bond_sysfs_slave.c b/drivers/net/bonding/bond_sysfs_slave.c
index 313866f2c0e49ac96299ffea307b1613955713ec..36d0e8440b5b94464b3226ce1a04f32361de5aa6 100644
--- a/drivers/net/bonding/bond_sysfs_slave.c
+++ b/drivers/net/bonding/bond_sysfs_slave.c
@@ -53,7 +53,7 @@ static SLAVE_ATTR_RO(perm_hwaddr);
static ssize_t queue_id_show(struct slave *slave, char *buf)
{
- return sysfs_emit(buf, "%d\n", slave->queue_id);
+ return sysfs_emit(buf, "%d\n", READ_ONCE(slave->queue_id));
}
static SLAVE_ATTR_RO(queue_id);
--
2.44.0.478.gd926399ef9-goog
^ permalink raw reply related
* [PATCH net-next 2/3] bonding: no longer use RTNL in bonding_show_slaves()
From: Eric Dumazet @ 2024-04-08 19:04 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Jay Vosburgh, Andy Gospodarek, netdev, eric.dumazet, Eric Dumazet
In-Reply-To: <20240408190437.2214473-1-edumazet@google.com>
Slave devices are already RCU protected, simply
switch to bond_for_each_slave_rcu(),
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/bonding/bond_sysfs.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 9132033f85fb0e33093e97c55f885a997c95cb4a..75ee7ca369034ef6fa58fc9399b566dd7044fedc 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -170,10 +170,9 @@ static ssize_t bonding_show_slaves(struct device *d,
struct slave *slave;
int res = 0;
- if (!rtnl_trylock())
- return restart_syscall();
+ rcu_read_lock();
- bond_for_each_slave(bond, slave, iter) {
+ bond_for_each_slave_rcu(bond, slave, iter) {
if (res > (PAGE_SIZE - IFNAMSIZ)) {
/* not enough space for another interface name */
if ((PAGE_SIZE - res) > 10)
@@ -184,7 +183,7 @@ static ssize_t bonding_show_slaves(struct device *d,
res += sysfs_emit_at(buf, res, "%s ", slave->dev->name);
}
- rtnl_unlock();
+ rcu_read_unlock();
if (res)
buf[res-1] = '\n'; /* eat the leftover space */
--
2.44.0.478.gd926399ef9-goog
^ permalink raw reply related
* [PATCH net-next 1/3] bonding: no longer use RTNL in bonding_show_bonds()
From: Eric Dumazet @ 2024-04-08 19:04 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Jay Vosburgh, Andy Gospodarek, netdev, eric.dumazet, Eric Dumazet
In-Reply-To: <20240408190437.2214473-1-edumazet@google.com>
netdev structures are already RCU protected.
Change bond_init() and bond_uninit() to use RCU
enabled list_add_tail_rcu() and list_del_rcu().
Then bonding_show_bonds() can use rcu_read_lock()
while iterating through bn->dev_list.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/bonding/bond_main.c | 4 ++--
drivers/net/bonding/bond_sysfs.c | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index c9f0415f780ab0a9ecb26424795695eff951421a..08e9bdbf450afdc103931249259c58a08665dc02 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -5933,7 +5933,7 @@ static void bond_uninit(struct net_device *bond_dev)
bond_set_slave_arr(bond, NULL, NULL);
- list_del(&bond->bond_list);
+ list_del_rcu(&bond->bond_list);
bond_debug_unregister(bond);
}
@@ -6347,7 +6347,7 @@ static int bond_init(struct net_device *bond_dev)
spin_lock_init(&bond->stats_lock);
netdev_lockdep_set_classes(bond_dev);
- list_add_tail(&bond->bond_list, &bn->dev_list);
+ list_add_tail_rcu(&bond->bond_list, &bn->dev_list);
bond_prepare_sysfs_group(bond);
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 2805135a7205ba444ccaf412df33f621f55a729a..9132033f85fb0e33093e97c55f885a997c95cb4a 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -37,12 +37,12 @@ static ssize_t bonding_show_bonds(const struct class *cls,
{
const struct bond_net *bn =
container_of_const(attr, struct bond_net, class_attr_bonding_masters);
- int res = 0;
struct bonding *bond;
+ int res = 0;
- rtnl_lock();
+ rcu_read_lock();
- list_for_each_entry(bond, &bn->dev_list, bond_list) {
+ list_for_each_entry_rcu(bond, &bn->dev_list, bond_list) {
if (res > (PAGE_SIZE - IFNAMSIZ)) {
/* not enough space for another interface name */
if ((PAGE_SIZE - res) > 10)
@@ -55,7 +55,7 @@ static ssize_t bonding_show_bonds(const struct class *cls,
if (res)
buf[res-1] = '\n'; /* eat the leftover space */
- rtnl_unlock();
+ rcu_read_unlock();
return res;
}
--
2.44.0.478.gd926399ef9-goog
^ permalink raw reply related
* [PATCH net-next 0/3] bonding: remove RTNL from three sysfs files
From: Eric Dumazet @ 2024-04-08 19:04 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Jay Vosburgh, Andy Gospodarek, netdev, eric.dumazet, Eric Dumazet
First patch might fix a potential deadlock.
sysfs handlers should use rtnl_trylock() instead of rtnl_lock().
Following files can be read without acquiring RTNL :
- /sys/class/net/bonding_masters
- /sys/class/net/<name>/bonding/slaves
- /sys/class/net/<name>/bonding/queue_id
Eric Dumazet (3):
bonding: no longer use RTNL in bonding_show_bonds()
bonding: no longer use RTNL in bonding_show_slaves()
bonding: no longer use RTNL in bonding_show_queue_id()
drivers/net/bonding/bond_main.c | 6 +++---
drivers/net/bonding/bond_netlink.c | 3 ++-
drivers/net/bonding/bond_options.c | 2 +-
drivers/net/bonding/bond_procfs.c | 2 +-
drivers/net/bonding/bond_sysfs.c | 25 ++++++++++++-------------
drivers/net/bonding/bond_sysfs_slave.c | 2 +-
6 files changed, 20 insertions(+), 20 deletions(-)
--
2.44.0.478.gd926399ef9-goog
^ permalink raw reply
* Re: [RFC] thermal/core: Disable uevent messages for cooling devices
From: John Stultz @ 2024-04-08 19:03 UTC (permalink / raw)
To: Roman Stratiienko
Cc: linux-pm, rafael, daniel.lezcano, amitk, rui.zhang, linux-kernel,
megi
In-Reply-To: <CAGphcdnK8Hx-YsA-HukRKbvC-HpnLktCtq8qFicQUL-8ZHC+1w@mail.gmail.com>
On Mon, Apr 8, 2024 at 11:59 AM Roman Stratiienko
<r.stratiienko@gmail.com> wrote:
>
> I haven't worked on it since I posted it initially. But it looks like
> there's an alternative patch already upstreamed and backported into
> stable:
>
> https://lore.kernel.org/linux-kernel/CAJZ5v0hHTuEXmQA=0D90eR_KUsOsfcxYbTS=zQYDTXuY6o_K_Q@mail.gmail.com/T/
Ah! Many thanks for the link! I'll check in with folks to better
understand if there is a functionality gap between what you submitted
and what landed upstream.
Thanks again!
-john
^ permalink raw reply
* Re: [PATCH v1 2/2] ASoC: meson: implement link-name optional property in meson card utils
From: Jerome Brunet @ 2024-04-08 18:53 UTC (permalink / raw)
To: Dmitry Rokosov
Cc: Jerome Brunet, neil.armstrong, lgirdwood, broonie, conor+dt,
robh+dt, krzysztof.kozlowski+dt, perex, tiwai, khilman,
martin.blumenstingl, kernel, rockosov, linux-amlogic, alsa-devel,
linux-sound, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240408184041.3jcav5tabxiblpn4@CAB-WSD-L081021>
On Mon 08 Apr 2024 at 21:40, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
> On Mon, Apr 08, 2024 at 08:15:54PM +0200, Jerome Brunet wrote:
>>
>> On Mon 08 Apr 2024 at 19:49, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
>>
>> > The 'link-name' property presents an optional DT feature that empowers
>> > users to customize the name associated with the DAI link and PCM stream.
>> > This functionality reflects the approach often employed in Qualcomm
>> > audio cards, providing enhanced flexibility in DAI naming conventions
>> > for improved system integration and userspace experience.
>> >
>> > It allows userspace program to easy determine PCM stream purpose, e.g.:
>> > ~ # cat /proc/asound/pcm
>> > 00-00: speaker (*) : : playback 1
>> > 00-01: mics (*) : : capture 1
>> > 00-02: loopback (*) : : capture 1
>>
>> The example above is exactly what you should not do with link names, at
>> least with the amlogic audio system.
>>
>> Userspace pcm, otherwise known as DPCM frontend, are merely that:
>> frontends. What they do is entirely defined by the routing defined by
>> the userspace (amixer and friends)
>>
>> So naming the interface in DT (the FW describing the HW) after what the
>> the userspace SW could possibly set later on is wrong.
>>
>> Bottom line: I have mixed feeling about this change. It could allow all
>> sort of bad names to be set.
>>
>> The only way it could make sense HW wise is if the only allowed names
>> where (fr|to)ddr_[abcd], which could help maps the interface and the
>> kcontrol.
>>
>> Such restriction should be documented in the binding doc.
>>
>
> The link-name is an optional parameter. Yes, you are right, it can be
> routed in a way that it no longer functions as a speaker in most cases.
> However, if you plan to use your board's dt for common purposes, you
> should not change the common names for DAI links. But if you know that
> you have a static setup for speakers, microphones, loopback, or other
> references (you 100% know it, because you are HW developer of this
> board), why not help the user understand the PCM device assignment in
> the easiest way?
>
> Ultimately, it is the responsibility of the DT board developer to define
> specific DAIs and name them based on their own knowledge about HW and
> understanding of the board's usage purposes.
Speaker and mics are NOT statically tied to a frontend. They are tied to a
codec (... possibly). The routing from the frontend to the backend is
dynamic, even while streaming.
So defining FW names based on usage in wrong.
As Mark pointed out as well, DT is not the place for this.
>
>> >
>> > The previous naming approach using auto-generated fe or be strings
>> > continues to be utilized as a fallback.
>> >
>> > Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
>> > ---
>> > sound/soc/meson/meson-card-utils.c | 12 ++++++++----
>> > 1 file changed, 8 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/sound/soc/meson/meson-card-utils.c b/sound/soc/meson/meson-card-utils.c
>> > index ed6c7e2f609c..7bae72905a9b 100644
>> > --- a/sound/soc/meson/meson-card-utils.c
>> > +++ b/sound/soc/meson/meson-card-utils.c
>> > @@ -94,10 +94,14 @@ static int meson_card_set_link_name(struct snd_soc_card *card,
>> > struct device_node *node,
>> > const char *prefix)
>> > {
>> > - char *name = devm_kasprintf(card->dev, GFP_KERNEL, "%s.%s",
>> > - prefix, node->full_name);
>> > - if (!name)
>> > - return -ENOMEM;
>> > + const char *name;
>> > +
>> > + if (of_property_read_string(node, "link-name", &name)) {
>> > + name = devm_kasprintf(card->dev, GFP_KERNEL, "%s.%s",
>> > + prefix, node->full_name);
>> > + if (!name)
>> > + return -ENOMEM;
>> > + }
>> >
>> > link->name = name;
>> > link->stream_name = name;
>>
>>
>> --
>> Jerome
--
Jerome
^ permalink raw reply
* Re: fix kernels without v5 support
From: Zorro Lang @ 2024-04-08 19:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Zorro Lang, Darrick J . Wong , linux-xfs, fstests
In-Reply-To: <20240408145939.GA26949@lst.de>
On Mon, Apr 08, 2024 at 04:59:39PM +0200, Christoph Hellwig wrote:
> On Mon, Apr 08, 2024 at 10:55:54PM +0800, Zorro Lang wrote:
> > > this series ensures tests pass on kernels without v5 support. As a side
> > > effect it also removes support for historic kernels and xfsprogs without
> > > any v5 support, and without mkfs input validation.
> >
> > Thanks for doing this! I'm wondering if fstests should do this "removing"
> > earlier than xfs? Hope to hear more opinions from xfs list and other fstests
> > users (especially from some LTS distro) :)
>
> What is being removed is support for kernels and xfsprogs that do not
> support v5 file systems at all, not testing on v4 file system for the
> test device and the large majority of tests using the scratch device
> without specifying an explicit version.
Sure, I think most of systems testing doesn't need this, except some old
LTS distros.
>
> The exception from the above are two sub-cases for v4 that are removed in
> the this series - if we really care about them I could move them into
> separate tests, but I doubt it's worth it.
Let me check and test this patchset more, before acking it. And give some
time to get more review. Thanks for this patchset!
Thanks,
Zorro
>
^ permalink raw reply
* Re: [PATCH v1 2/2] ASoC: meson: implement link-name optional property in meson card utils
From: Jerome Brunet @ 2024-04-08 18:53 UTC (permalink / raw)
To: Dmitry Rokosov
Cc: Jerome Brunet, neil.armstrong, lgirdwood, broonie, conor+dt,
robh+dt, krzysztof.kozlowski+dt, perex, tiwai, khilman,
martin.blumenstingl, kernel, rockosov, linux-amlogic, alsa-devel,
linux-sound, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240408184041.3jcav5tabxiblpn4@CAB-WSD-L081021>
On Mon 08 Apr 2024 at 21:40, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
> On Mon, Apr 08, 2024 at 08:15:54PM +0200, Jerome Brunet wrote:
>>
>> On Mon 08 Apr 2024 at 19:49, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
>>
>> > The 'link-name' property presents an optional DT feature that empowers
>> > users to customize the name associated with the DAI link and PCM stream.
>> > This functionality reflects the approach often employed in Qualcomm
>> > audio cards, providing enhanced flexibility in DAI naming conventions
>> > for improved system integration and userspace experience.
>> >
>> > It allows userspace program to easy determine PCM stream purpose, e.g.:
>> > ~ # cat /proc/asound/pcm
>> > 00-00: speaker (*) : : playback 1
>> > 00-01: mics (*) : : capture 1
>> > 00-02: loopback (*) : : capture 1
>>
>> The example above is exactly what you should not do with link names, at
>> least with the amlogic audio system.
>>
>> Userspace pcm, otherwise known as DPCM frontend, are merely that:
>> frontends. What they do is entirely defined by the routing defined by
>> the userspace (amixer and friends)
>>
>> So naming the interface in DT (the FW describing the HW) after what the
>> the userspace SW could possibly set later on is wrong.
>>
>> Bottom line: I have mixed feeling about this change. It could allow all
>> sort of bad names to be set.
>>
>> The only way it could make sense HW wise is if the only allowed names
>> where (fr|to)ddr_[abcd], which could help maps the interface and the
>> kcontrol.
>>
>> Such restriction should be documented in the binding doc.
>>
>
> The link-name is an optional parameter. Yes, you are right, it can be
> routed in a way that it no longer functions as a speaker in most cases.
> However, if you plan to use your board's dt for common purposes, you
> should not change the common names for DAI links. But if you know that
> you have a static setup for speakers, microphones, loopback, or other
> references (you 100% know it, because you are HW developer of this
> board), why not help the user understand the PCM device assignment in
> the easiest way?
>
> Ultimately, it is the responsibility of the DT board developer to define
> specific DAIs and name them based on their own knowledge about HW and
> understanding of the board's usage purposes.
Speaker and mics are NOT statically tied to a frontend. They are tied to a
codec (... possibly). The routing from the frontend to the backend is
dynamic, even while streaming.
So defining FW names based on usage in wrong.
As Mark pointed out as well, DT is not the place for this.
>
>> >
>> > The previous naming approach using auto-generated fe or be strings
>> > continues to be utilized as a fallback.
>> >
>> > Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
>> > ---
>> > sound/soc/meson/meson-card-utils.c | 12 ++++++++----
>> > 1 file changed, 8 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/sound/soc/meson/meson-card-utils.c b/sound/soc/meson/meson-card-utils.c
>> > index ed6c7e2f609c..7bae72905a9b 100644
>> > --- a/sound/soc/meson/meson-card-utils.c
>> > +++ b/sound/soc/meson/meson-card-utils.c
>> > @@ -94,10 +94,14 @@ static int meson_card_set_link_name(struct snd_soc_card *card,
>> > struct device_node *node,
>> > const char *prefix)
>> > {
>> > - char *name = devm_kasprintf(card->dev, GFP_KERNEL, "%s.%s",
>> > - prefix, node->full_name);
>> > - if (!name)
>> > - return -ENOMEM;
>> > + const char *name;
>> > +
>> > + if (of_property_read_string(node, "link-name", &name)) {
>> > + name = devm_kasprintf(card->dev, GFP_KERNEL, "%s.%s",
>> > + prefix, node->full_name);
>> > + if (!name)
>> > + return -ENOMEM;
>> > + }
>> >
>> > link->name = name;
>> > link->stream_name = name;
>>
>>
>> --
>> Jerome
--
Jerome
_______________________________________________
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 v1 2/2] ASoC: meson: implement link-name optional property in meson card utils
From: Jerome Brunet @ 2024-04-08 18:53 UTC (permalink / raw)
To: Dmitry Rokosov
Cc: Jerome Brunet, neil.armstrong, lgirdwood, broonie, conor+dt,
robh+dt, krzysztof.kozlowski+dt, perex, tiwai, khilman,
martin.blumenstingl, kernel, rockosov, linux-amlogic, alsa-devel,
linux-sound, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240408184041.3jcav5tabxiblpn4@CAB-WSD-L081021>
On Mon 08 Apr 2024 at 21:40, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
> On Mon, Apr 08, 2024 at 08:15:54PM +0200, Jerome Brunet wrote:
>>
>> On Mon 08 Apr 2024 at 19:49, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
>>
>> > The 'link-name' property presents an optional DT feature that empowers
>> > users to customize the name associated with the DAI link and PCM stream.
>> > This functionality reflects the approach often employed in Qualcomm
>> > audio cards, providing enhanced flexibility in DAI naming conventions
>> > for improved system integration and userspace experience.
>> >
>> > It allows userspace program to easy determine PCM stream purpose, e.g.:
>> > ~ # cat /proc/asound/pcm
>> > 00-00: speaker (*) : : playback 1
>> > 00-01: mics (*) : : capture 1
>> > 00-02: loopback (*) : : capture 1
>>
>> The example above is exactly what you should not do with link names, at
>> least with the amlogic audio system.
>>
>> Userspace pcm, otherwise known as DPCM frontend, are merely that:
>> frontends. What they do is entirely defined by the routing defined by
>> the userspace (amixer and friends)
>>
>> So naming the interface in DT (the FW describing the HW) after what the
>> the userspace SW could possibly set later on is wrong.
>>
>> Bottom line: I have mixed feeling about this change. It could allow all
>> sort of bad names to be set.
>>
>> The only way it could make sense HW wise is if the only allowed names
>> where (fr|to)ddr_[abcd], which could help maps the interface and the
>> kcontrol.
>>
>> Such restriction should be documented in the binding doc.
>>
>
> The link-name is an optional parameter. Yes, you are right, it can be
> routed in a way that it no longer functions as a speaker in most cases.
> However, if you plan to use your board's dt for common purposes, you
> should not change the common names for DAI links. But if you know that
> you have a static setup for speakers, microphones, loopback, or other
> references (you 100% know it, because you are HW developer of this
> board), why not help the user understand the PCM device assignment in
> the easiest way?
>
> Ultimately, it is the responsibility of the DT board developer to define
> specific DAIs and name them based on their own knowledge about HW and
> understanding of the board's usage purposes.
Speaker and mics are NOT statically tied to a frontend. They are tied to a
codec (... possibly). The routing from the frontend to the backend is
dynamic, even while streaming.
So defining FW names based on usage in wrong.
As Mark pointed out as well, DT is not the place for this.
>
>> >
>> > The previous naming approach using auto-generated fe or be strings
>> > continues to be utilized as a fallback.
>> >
>> > Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
>> > ---
>> > sound/soc/meson/meson-card-utils.c | 12 ++++++++----
>> > 1 file changed, 8 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/sound/soc/meson/meson-card-utils.c b/sound/soc/meson/meson-card-utils.c
>> > index ed6c7e2f609c..7bae72905a9b 100644
>> > --- a/sound/soc/meson/meson-card-utils.c
>> > +++ b/sound/soc/meson/meson-card-utils.c
>> > @@ -94,10 +94,14 @@ static int meson_card_set_link_name(struct snd_soc_card *card,
>> > struct device_node *node,
>> > const char *prefix)
>> > {
>> > - char *name = devm_kasprintf(card->dev, GFP_KERNEL, "%s.%s",
>> > - prefix, node->full_name);
>> > - if (!name)
>> > - return -ENOMEM;
>> > + const char *name;
>> > +
>> > + if (of_property_read_string(node, "link-name", &name)) {
>> > + name = devm_kasprintf(card->dev, GFP_KERNEL, "%s.%s",
>> > + prefix, node->full_name);
>> > + if (!name)
>> > + return -ENOMEM;
>> > + }
>> >
>> > link->name = name;
>> > link->stream_name = name;
>>
>>
>> --
>> Jerome
--
Jerome
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [RFC] thermal/core: Disable uevent messages for cooling devices
From: Roman Stratiienko @ 2024-04-08 18:59 UTC (permalink / raw)
To: John Stultz
Cc: linux-pm, rafael, daniel.lezcano, amitk, rui.zhang, linux-kernel,
megi
In-Reply-To: <CANDhNCpAhtgdwpSUTJ2jo2J5L6rHzQHVB9q+kkZ3ouTt12b-uw@mail.gmail.com>
Hi John,
I haven't worked on it since I posted it initially. But it looks like
there's an alternative patch already upstreamed and backported into
stable:
https://lore.kernel.org/linux-kernel/CAJZ5v0hHTuEXmQA=0D90eR_KUsOsfcxYbTS=zQYDTXuY6o_K_Q@mail.gmail.com/T/
BR,
Roman
пн, 8 апр. 2024 г. в 21:48, John Stultz <jstultz@google.com>:
>
> On Sun, Jul 10, 2022 at 9:40 AM Roman Stratiienko
> <r.stratiienko@gmail.com> wrote:
> >
> > During suspend, the big CPU cluster is turned off first while a little
> > is still running. This forcibly unregisters the cooling device which
> > sends a "REMOVE" uevent to all subscribers [1].
> >
> > In case userspace netlink subscriber has set the EPOLLWAKEUP flag, a
> > wakeup event is triggered that causes suspend to be aborted.
> >
> > Without this change, suspend doesn't work on PinePhone PRO with AOSP
> > userland.
> >
> > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c238a8b599f1ae25eaeb08ad0e9e13e2b9eb023
> > Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
>
> Hey Roman,
> I wanted to drudge this patch up, to ask what the current status of
> it was? Is there an alternative solution that you've been using since
> this was last sent out?
> I've heard of some vendors working around something similar, so I
> wanted to see if we could get a common fix upstream.
>
> thanks
> -john
^ permalink raw reply
* ✗ Fi.CI.BAT: failure for drm: debug logging improvements (rev2)
From: Patchwork @ 2024-04-08 18:59 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
In-Reply-To: <cover.1712568037.git.jani.nikula@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3826 bytes --]
== Series Details ==
Series: drm: debug logging improvements (rev2)
URL : https://patchwork.freedesktop.org/series/130881/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14543 -> Patchwork_130881v2
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_130881v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_130881v2, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v2/index.html
Participating hosts (41 -> 37)
------------------------------
Missing (4): fi-glk-j4005 fi-cfl-8109u fi-apl-guc fi-kbl-8809g
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_130881v2:
### IGT changes ###
#### Possible regressions ####
* igt@i915_selftest@live@gt_mocs:
- bat-adlp-11: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-adlp-11/igt@i915_selftest@live@gt_mocs.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v2/bat-adlp-11/igt@i915_selftest@live@gt_mocs.html
* igt@i915_selftest@live@objects:
- bat-arls-2: [PASS][3] -> [DMESG-FAIL][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-arls-2/igt@i915_selftest@live@objects.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v2/bat-arls-2/igt@i915_selftest@live@objects.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_mocs:
- {bat-arls-4}: [PASS][5] -> [DMESG-WARN][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-arls-4/igt@i915_selftest@live@gt_mocs.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v2/bat-arls-4/igt@i915_selftest@live@gt_mocs.html
Known issues
------------
Here are the changes found in Patchwork_130881v2 that come from known issues:
### IGT changes ###
#### Possible fixes ####
* igt@kms_flip@basic-flip-vs-dpms@a-dp6:
- {bat-mtlp-9}: [DMESG-WARN][7] ([i915#10435]) -> [PASS][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14543/bat-mtlp-9/igt@kms_flip@basic-flip-vs-dpms@a-dp6.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v2/bat-mtlp-9/igt@kms_flip@basic-flip-vs-dpms@a-dp6.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10435]: https://gitlab.freedesktop.org/drm/intel/issues/10435
Build changes
-------------
* Linux: CI_DRM_14543 -> Patchwork_130881v2
CI-20190529: 20190529
CI_DRM_14543: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7801: 7801
Patchwork_130881v2: a533b51ca017728c1228432e8e1e9aba4fd65b02 @ git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
fd8df2b8a798 drm: prefer DRM_MODE_FMT/ARG over drm_mode_debug_printmodeline()
adc78f76eb2b drm/crtc-helper: switch to drm device based logging and warns
a83408378298 drm/crtc: switch to drm device based logging
bfd64144ecbc drm/client: switch to drm device based logging, and more
ac3c8a489c1f drm/sysfs: switch to drm device based logging
eddb4a71e3c1 drm/modes: switch to drm device based error logging
7830c15dc1f6 drm/probe-helper: switch to drm device based logging
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130881v2/index.html
[-- Attachment #2: Type: text/html, Size: 4587 bytes --]
^ permalink raw reply
* Re: [PATCHv4 0/7] nvmet: debugfs support
From: Sagi Grimberg @ 2024-04-08 18:59 UTC (permalink / raw)
To: Daniel Wagner, Keith Busch; +Cc: Christoph Hellwig, linux-nvme, Hannes Reinecke
In-Reply-To: <uvkgxqndcvgkphwuto7o6nimdsria35hc27v43zzo2h7kokor4@5olfmdazhi4f>
On 08/04/2024 19:07, Daniel Wagner wrote:
> Any chance to get this picked up?
I'm fine with it, the only question would be the fc additions, which
perhaps can use a review tag from one of the fc folks.
^ permalink raw reply
* Re: [PATCH] mm/userfaultfd: Allow hugetlb change protection upon poison entry
From: David Hildenbrand @ 2024-04-08 18:59 UTC (permalink / raw)
To: peterx, linux-mm, linux-kernel
Cc: Andrew Morton, Axel Rasmussen, linux-stable,
syzbot+b07c8ac8eee3d4d8440f
In-Reply-To: <20240405231920.1772199-1-peterx@redhat.com>
On 06.04.24 01:19, peterx@redhat.com wrote:
> From: Peter Xu <peterx@redhat.com>
>
> After UFFDIO_POISON, there can be two kinds of hugetlb pte markers, either
> the POISON one or UFFD_WP one.
>
> Allow change protection to run on a poisoned marker just like !hugetlb
> cases, ignoring the marker irrelevant of the permission.
>
> Here the two bits are mutual exclusive. For example, when install a
> poisoned entry it must not be UFFD_WP already (by checking pte_none()
> before such install). And it also means if UFFD_WP is set there must have
> no POISON bit set. It makes sense because UFFD_WP is a bit to reflect
> permission, and permissions do not apply if the pte is poisoned and
> destined to sigbus.
>
> So here we simply check uffd_wp bit set first, do nothing otherwise.
>
> Attach the Fixes to UFFDIO_POISON work, as before that it should not be
> possible to have poison entry for hugetlb (e.g., hugetlb doesn't do swap,
> so no chance of swapin errors).
>
> Cc: Axel Rasmussen <axelrasmussen@google.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: linux-stable <stable@vger.kernel.org> # 6.6+
> Link: https://lore.kernel.org/r/000000000000920d5e0615602dd1@google.com
> Reported-by: syzbot+b07c8ac8eee3d4d8440f@syzkaller.appspotmail.com
> Fixes: fc71884a5f59 ("mm: userfaultfd: add new UFFDIO_POISON ioctl")
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
> mm/hugetlb.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 8267e221ca5d..ba7162441adf 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6960,9 +6960,13 @@ long hugetlb_change_protection(struct vm_area_struct *vma,
> if (!pte_same(pte, newpte))
> set_huge_pte_at(mm, address, ptep, newpte, psize);
> } else if (unlikely(is_pte_marker(pte))) {
> - /* No other markers apply for now. */
> - WARN_ON_ONCE(!pte_marker_uffd_wp(pte));
> - if (uffd_wp_resolve)
> + /*
> + * Do nothing on a poison marker; page is
> + * corrupted, permissons do not apply. Here
> + * pte_marker_uffd_wp()==true implies !poison
> + * because they're mutual exclusive.
> + */
> + if (pte_marker_uffd_wp(pte) && uffd_wp_resolve)
> /* Safe to modify directly (non-present->none). */
> huge_pte_clear(mm, address, ptep, psize);
> } else if (!huge_pte_none(pte)) {
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Cheers,
David / dhildenb
^ permalink raw reply
* Re: [RFC PATCH 2/2] PCI: Add Qualcomm PCIe ECAM root complex driver
From: Mayank Rana @ 2024-04-08 18:57 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
krzysztof.kozlowski+dt, conor+dt, devicetree, linux-arm-msm,
quic_ramkri, quic_nkela, quic_shazhuss, quic_msarkar,
quic_nitegupt
In-Reply-To: <20240406041717.GD2678@thinkpad>
Hi Mani
On 4/5/2024 9:17 PM, Manivannan Sadhasivam wrote:
> On Fri, Apr 05, 2024 at 10:41:15AM -0700, Mayank Rana wrote:
>> Hi Mani
>>
>> On 4/4/2024 10:30 PM, Manivannan Sadhasivam wrote:
>>> On Thu, Apr 04, 2024 at 12:11:24PM -0700, Mayank Rana wrote:
>>>> On some of Qualcomm platform, firmware configures PCIe controller into
>>>> ECAM mode allowing static memory allocation for configuration space of
>>>> supported bus range. Firmware also takes care of bringing up PCIe PHY
>>>> and performing required operation to bring PCIe link into D0. Firmware
>>>> also manages system resources (e.g. clocks/regulators/resets/ bus voting).
>>>> Hence add Qualcomm PCIe ECAM root complex driver which enumerates PCIe
>>>> root complex and connected PCIe devices. Firmware won't be enumerating
>>>> or powering up PCIe root complex until this driver invokes power domain
>>>> based notification to bring PCIe link into D0/D3cold mode.
>>>>
>>>
>>> Is this an in-house PCIe IP of Qualcomm or the same DWC IP that is used in other
>>> SoCs?
>>>
>>> - Mani
>> Driver is validated on SA8775p-ride platform using PCIe DWC IP for
>> now.Although this driver doesn't need to know used PCIe controller and PHY
>> IP as well programming sequence as that would be taken care by firmware.
>>
>
> Ok, so it is the same IP but firmware is controlling the resources now. This
> information should be present in the commit message.
>
> Btw, there is an existing generic ECAM host controller driver:
> drivers/pci/controller/pci-host-generic.c
>
> This driver is already being used by several vendors as well. So we should try
> to extend it for Qcom usecase also.
I did review pci-host-generic.c driver for usage. although there are
more functionalityneeded for use case purpose as below:
1. MSI functionality
2. Suspend/Resume
3. Wakeup Functionality (not part of current change, but would be added
later)
4. Here this driver provides way to virtualized PCIe controller. So VMs
only talk to a generic ECAM whereas HW is only directed accessed by
service VM.
5. Adding more Auto based safety use cases related implementation
Hence keeping pci-host-generic.c as generic driver where above
functionality may not be needed. Also here we may add more functionality
using PM runtime based GenPD/Power Domain with SCMI communication with
firmware.
>>>> This driver also support MSI functionality using PCIe controller based
>>>> MSI controller as GIC ITS based MSI functionality is not available on
>>>> some of platform.
>>>>
>
> So is this the same internal MSI controller in the DWC IP? If so, then we
> already have the MSI implementation in
> drivers/pci/controller/dwc/pcie-designware-host.c and that should be reused here
> instead of duplicating the code.
If you are referring just MSI implementation as duplication code than I
agree with you.
Although proposed new driver is agnostic to specific PCIe controller
related IP. Currently we are using PCIe DWC controller based MSI
controller for MSI functionality using controller specific SPIs.
Although I am looking into implementation where we can use free SPIs
(there is no free SPIs available on SA877p-ride platform) or extended
SPIs to use for MSI functionality so we don't need to use PCIe
controller based MSI controller. extended SPI based MSI functionality
related work is under progress and eventually will replace current
proposed solution based MSI implementation. With that we would have
generic enough implementation for MSI functionality using free
SPIs/extended SPIs with this new driver.
> - Mani
>
Regards,
Mayank
>>>> Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
>>>> ---
>>>> drivers/pci/controller/Kconfig | 12 +
>>>> drivers/pci/controller/Makefile | 1 +
>>>> drivers/pci/controller/pcie-qcom-ecam.c | 575 ++++++++++++++++++++++++++++++++
>>>> 3 files changed, 588 insertions(+)
>>>> create mode 100644 drivers/pci/controller/pcie-qcom-ecam.c
>>>>
>>>> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
>>>> index e534c02..abbd9f2 100644
>>>> --- a/drivers/pci/controller/Kconfig
>>>> +++ b/drivers/pci/controller/Kconfig
>>>> @@ -353,6 +353,18 @@ config PCIE_XILINX_CPM
>>>> Say 'Y' here if you want kernel support for the
>>>> Xilinx Versal CPM host bridge.
>>>> +config PCIE_QCOM_ECAM
>>>> + tristate "QCOM PCIe ECAM host controller"
>>>> + depends on ARCH_QCOM && PCI
>>>> + depends on OF
>>>> + select PCI_MSI
>>>> + select PCI_HOST_COMMON
>>>> + select IRQ_DOMAIN
>>>> + help
>>>> + Say 'Y' here if you want to use ECAM shift mode compatible Qualcomm
>>>> + PCIe root host controller. The controller is programmed using firmware
>>>> + to support ECAM compatible memory address space.
>>>> +
>>>> source "drivers/pci/controller/cadence/Kconfig"
>>>> source "drivers/pci/controller/dwc/Kconfig"
>>>> source "drivers/pci/controller/mobiveil/Kconfig"
>>>> diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
>>>> index f2b19e6..2f1ee1e 100644
>>>> --- a/drivers/pci/controller/Makefile
>>>> +++ b/drivers/pci/controller/Makefile
>>>> @@ -40,6 +40,7 @@ obj-$(CONFIG_PCI_LOONGSON) += pci-loongson.o
>>>> obj-$(CONFIG_PCIE_HISI_ERR) += pcie-hisi-error.o
>>>> obj-$(CONFIG_PCIE_APPLE) += pcie-apple.o
>>>> obj-$(CONFIG_PCIE_MT7621) += pcie-mt7621.o
>>>> +obj-$(CONFIG_PCIE_QCOM_ECAM) += pcie-qcom-ecam.o
>>>> # pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
>>>> obj-y += dwc/
>>>> diff --git a/drivers/pci/controller/pcie-qcom-ecam.c b/drivers/pci/controller/pcie-qcom-ecam.c
>>>> new file mode 100644
>>>> index 00000000..5b4c68b
>>>> --- /dev/null
>>>> +++ b/drivers/pci/controller/pcie-qcom-ecam.c
>>>> @@ -0,0 +1,575 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>> +/*
>>>> + * Qualcomm PCIe ECAM root host controller driver
>>>> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
>>>> + */
>>>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>>>> +
>>>> +#include <linux/irq.h>
>>>> +#include <linux/irqchip/chained_irq.h>
>>>> +#include <linux/irqdomain.h>
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/msi.h>
>>>> +#include <linux/of_address.h>
>>>> +#include <linux/of_irq.h>
>>>> +#include <linux/of_pci.h>
>>>> +#include <linux/pci.h>
>>>> +#include <linux/pci-ecam.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/pm_domain.h>
>>>> +#include <linux/pm_runtime.h>
>>>> +#include <linux/slab.h>
>>>> +#include <linux/types.h>
>>>> +
>>>> +#define PCIE_MSI_CTRL_BASE (0x820)
>>>> +#define PCIE_MSI_CTRL_SIZE (0x68)
>>>> +#define PCIE_MSI_CTRL_ADDR_OFFS (0x0)
>>>> +#define PCIE_MSI_CTRL_UPPER_ADDR_OFFS (0x4)
>>>> +#define PCIE_MSI_CTRL_INT_N_EN_OFFS(n) (0x8 + 0xc * (n))
>>>> +#define PCIE_MSI_CTRL_INT_N_MASK_OFFS(n) (0xc + 0xc * (n))
>>>> +#define PCIE_MSI_CTRL_INT_N_STATUS_OFFS(n) (0x10 + 0xc * (n))
>>>> +
>>>> +#define MSI_DB_ADDR 0xa0000000
>>>> +#define MSI_IRQ_PER_GRP (32)
>>>> +
>>>> +/**
>>>> + * struct qcom_msi_irq - MSI IRQ information
>>>> + * @client: pointer to MSI client struct
>>>> + * @grp: group the irq belongs to
>>>> + * @grp_index: index in group
>>>> + * @hwirq: hwirq number
>>>> + * @virq: virq number
>>>> + * @pos: position in MSI bitmap
>>>> + */
>>>> +struct qcom_msi_irq {
>>>> + struct qcom_msi_client *client;
>>>> + struct qcom_msi_grp *grp;
>>>> + unsigned int grp_index;
>>>> + unsigned int hwirq;
>>>> + unsigned int virq;
>>>> + u32 pos;
>>>> +};
>>>> +
>>>> +/**
>>>> + * struct qcom_msi_grp - MSI group information
>>>> + * @int_en_reg: memory-mapped interrupt enable register address
>>>> + * @int_mask_reg: memory-mapped interrupt mask register address
>>>> + * @int_status_reg: memory-mapped interrupt status register address
>>>> + * @mask: tracks masked/unmasked MSI
>>>> + * @irqs: structure to MSI IRQ information
>>>> + */
>>>> +struct qcom_msi_grp {
>>>> + void __iomem *int_en_reg;
>>>> + void __iomem *int_mask_reg;
>>>> + void __iomem *int_status_reg;
>>>> + u32 mask;
>>>> + struct qcom_msi_irq irqs[MSI_IRQ_PER_GRP];
>>>> +};
>>>> +
>>>> +/**
>>>> + * struct qcom_msi - PCIe controller based MSI controller information
>>>> + * @clients: list for tracking clients
>>>> + * @dev: platform device node
>>>> + * @nr_hwirqs: total number of hardware IRQs
>>>> + * @nr_virqs: total number of virqs
>>>> + * @nr_grps: total number of groups
>>>> + * @grps: pointer to all groups information
>>>> + * @bitmap: tracks used/unused MSI
>>>> + * @mutex: for modifying MSI client list and bitmap
>>>> + * @inner_domain: parent domain; gen irq related
>>>> + * @msi_domain: child domain; pcie related
>>>> + * @msi_db_addr: MSI doorbell address
>>>> + * @cfg_lock: lock for configuring MSI controller registers
>>>> + * @pcie_msi_cfg: memory-mapped MSI controller register space
>>>> + */
>>>> +struct qcom_msi {
>>>> + struct list_head clients;
>>>> + struct device *dev;
>>>> + int nr_hwirqs;
>>>> + int nr_virqs;
>>>> + int nr_grps;
>>>> + struct qcom_msi_grp *grps;
>>>> + unsigned long *bitmap;
>>>> + struct mutex mutex;
>>>> + struct irq_domain *inner_domain;
>>>> + struct irq_domain *msi_domain;
>>>> + phys_addr_t msi_db_addr;
>>>> + spinlock_t cfg_lock;
>>>> + void __iomem *pcie_msi_cfg;
>>>> +};
>>>> +
>>>> +/**
>>>> + * struct qcom_msi_client - structure for each client of MSI controller
>>>> + * @node: list to track number of MSI clients
>>>> + * @msi: client specific MSI controller based resource pointer
>>>> + * @dev: client's dev of pci_dev
>>>> + * @nr_irqs: number of irqs allocated for client
>>>> + * @msi_addr: MSI doorbell address
>>>> + */
>>>> +struct qcom_msi_client {
>>>> + struct list_head node;
>>>> + struct qcom_msi *msi;
>>>> + struct device *dev;
>>>> + unsigned int nr_irqs;
>>>> + phys_addr_t msi_addr;
>>>> +};
>>>> +
>>>> +static void qcom_msi_handler(struct irq_desc *desc)
>>>> +{
>>>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>>>> + struct qcom_msi_grp *msi_grp;
>>>> + u32 status;
>>>> + int i;
>>>> +
>>>> + chained_irq_enter(chip, desc);
>>>> +
>>>> + msi_grp = irq_desc_get_handler_data(desc);
>>>> + status = readl_relaxed(msi_grp->int_status_reg);
>>>> + status ^= (msi_grp->mask & status);
>>>> + writel(status, msi_grp->int_status_reg);
>>>> +
>>>> + for (i = 0; status; i++, status >>= 1)
>>>> + if (status & 0x1)
>>>> + generic_handle_irq(msi_grp->irqs[i].virq);
>>>> +
>>>> + chained_irq_exit(chip, desc);
>>>> +}
>>>> +
>>>> +static void qcom_msi_mask_irq(struct irq_data *data)
>>>> +{
>>>> + struct irq_data *parent_data;
>>>> + struct qcom_msi_irq *msi_irq;
>>>> + struct qcom_msi_grp *msi_grp;
>>>> + struct qcom_msi *msi;
>>>> + unsigned long flags;
>>>> +
>>>> + parent_data = data->parent_data;
>>>> + if (!parent_data)
>>>> + return;
>>>> +
>>>> + msi_irq = irq_data_get_irq_chip_data(parent_data);
>>>> + msi = msi_irq->client->msi;
>>>> + msi_grp = msi_irq->grp;
>>>> +
>>>> + spin_lock_irqsave(&msi->cfg_lock, flags);
>>>> + pci_msi_mask_irq(data);
>>>> + msi_grp->mask |= BIT(msi_irq->grp_index);
>>>> + writel(msi_grp->mask, msi_grp->int_mask_reg);
>>>> + spin_unlock_irqrestore(&msi->cfg_lock, flags);
>>>> +}
>>>> +
>>>> +static void qcom_msi_unmask_irq(struct irq_data *data)
>>>> +{
>>>> + struct irq_data *parent_data;
>>>> + struct qcom_msi_irq *msi_irq;
>>>> + struct qcom_msi_grp *msi_grp;
>>>> + struct qcom_msi *msi;
>>>> + unsigned long flags;
>>>> +
>>>> + parent_data = data->parent_data;
>>>> + if (!parent_data)
>>>> + return;
>>>> +
>>>> + msi_irq = irq_data_get_irq_chip_data(parent_data);
>>>> + msi = msi_irq->client->msi;
>>>> + msi_grp = msi_irq->grp;
>>>> +
>>>> + spin_lock_irqsave(&msi->cfg_lock, flags);
>>>> + msi_grp->mask &= ~BIT(msi_irq->grp_index);
>>>> + writel(msi_grp->mask, msi_grp->int_mask_reg);
>>>> + pci_msi_unmask_irq(data);
>>>> + spin_unlock_irqrestore(&msi->cfg_lock, flags);
>>>> +}
>>>> +
>>>> +static struct irq_chip qcom_msi_irq_chip = {
>>>> + .name = "qcom_pci_msi",
>>>> + .irq_enable = qcom_msi_unmask_irq,
>>>> + .irq_disable = qcom_msi_mask_irq,
>>>> + .irq_mask = qcom_msi_mask_irq,
>>>> + .irq_unmask = qcom_msi_unmask_irq,
>>>> +};
>>>> +
>>>> +static int qcom_msi_domain_prepare(struct irq_domain *domain, struct device *dev,
>>>> + int nvec, msi_alloc_info_t *arg)
>>>> +{
>>>> + struct qcom_msi *msi = domain->parent->host_data;
>>>> + struct qcom_msi_client *client;
>>>> +
>>>> + client = kzalloc(sizeof(*client), GFP_KERNEL);
>>>> + if (!client)
>>>> + return -ENOMEM;
>>>> +
>>>> + client->msi = msi;
>>>> + client->dev = dev;
>>>> + client->msi_addr = msi->msi_db_addr;
>>>> + mutex_lock(&msi->mutex);
>>>> + list_add_tail(&client->node, &msi->clients);
>>>> + mutex_unlock(&msi->mutex);
>>>> +
>>>> + /* zero out struct for pcie msi framework */
>>>> + memset(arg, 0, sizeof(*arg));
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static struct msi_domain_ops qcom_msi_domain_ops = {
>>>> + .msi_prepare = qcom_msi_domain_prepare,
>>>> +};
>>>> +
>>>> +static struct msi_domain_info qcom_msi_domain_info = {
>>>> + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
>>>> + MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
>>>> + .ops = &qcom_msi_domain_ops,
>>>> + .chip = &qcom_msi_irq_chip,
>>>> +};
>>>> +
>>>> +static int qcom_msi_irq_set_affinity(struct irq_data *data,
>>>> + const struct cpumask *mask, bool force)
>>>> +{
>>>> + struct irq_data *parent_data = irq_get_irq_data(irqd_to_hwirq(data));
>>>> + int ret = 0;
>>>> +
>>>> + if (!parent_data)
>>>> + return -ENODEV;
>>>> +
>>>> + /* set affinity for MSI HW IRQ */
>>>> + if (parent_data->chip->irq_set_affinity)
>>>> + ret = parent_data->chip->irq_set_affinity(parent_data, mask, force);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static void qcom_msi_irq_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
>>>> +{
>>>> + struct irq_data *parent_data = irq_get_irq_data(irqd_to_hwirq(data));
>>>> + struct qcom_msi_irq *msi_irq = irq_data_get_irq_chip_data(data);
>>>> + struct qcom_msi_client *client = msi_irq->client;
>>>> +
>>>> + if (!parent_data)
>>>> + return;
>>>> +
>>>> + msg->address_lo = lower_32_bits(client->msi_addr);
>>>> + msg->address_hi = upper_32_bits(client->msi_addr);
>>>> + msg->data = msi_irq->pos;
>>>> +}
>>>> +
>>>> +static struct irq_chip qcom_msi_bottom_irq_chip = {
>>>> + .name = "qcom_msi",
>>>> + .irq_set_affinity = qcom_msi_irq_set_affinity,
>>>> + .irq_compose_msi_msg = qcom_msi_irq_compose_msi_msg,
>>>> +};
>>>> +
>>>> +static int qcom_msi_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
>>>> + unsigned int nr_irqs, void *args)
>>>> +{
>>>> + struct device *dev = ((msi_alloc_info_t *)args)->desc->dev;
>>>> + struct qcom_msi_client *tmp, *client = NULL;
>>>> + struct qcom_msi *msi = domain->host_data;
>>>> + int i, ret = 0;
>>>> + int pos;
>>>> +
>>>> + mutex_lock(&msi->mutex);
>>>> + list_for_each_entry(tmp, &msi->clients, node) {
>>>> + if (tmp->dev == dev) {
>>>> + client = tmp;
>>>> + break;
>>>> + }
>>>> + }
>>>> +
>>>> + if (!client) {
>>>> + dev_err(msi->dev, "failed to find MSI client dev\n");
>>>> + ret = -ENODEV;
>>>> + goto out;
>>>> + }
>>>> +
>>>> + pos = bitmap_find_next_zero_area(msi->bitmap, msi->nr_virqs, 0,
>>>> + nr_irqs, nr_irqs - 1);
>>>> + if (pos > msi->nr_virqs) {
>>>> + ret = -ENOSPC;
>>>> + goto out;
>>>> + }
>>>> +
>>>> + bitmap_set(msi->bitmap, pos, nr_irqs);
>>>> + for (i = 0; i < nr_irqs; i++) {
>>>> + u32 grp = pos / MSI_IRQ_PER_GRP;
>>>> + u32 index = pos % MSI_IRQ_PER_GRP;
>>>> + struct qcom_msi_irq *msi_irq = &msi->grps[grp].irqs[index];
>>>> +
>>>> + msi_irq->virq = virq + i;
>>>> + msi_irq->client = client;
>>>> + irq_domain_set_info(domain, msi_irq->virq,
>>>> + msi_irq->hwirq,
>>>> + &qcom_msi_bottom_irq_chip, msi_irq,
>>>> + handle_simple_irq, NULL, NULL);
>>>> + client->nr_irqs++;
>>>> + pos++;
>>>> + }
>>>> +out:
>>>> + mutex_unlock(&msi->mutex);
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static void qcom_msi_irq_domain_free(struct irq_domain *domain, unsigned int virq,
>>>> + unsigned int nr_irqs)
>>>> +{
>>>> + struct irq_data *data = irq_domain_get_irq_data(domain, virq);
>>>> + struct qcom_msi_client *client;
>>>> + struct qcom_msi_irq *msi_irq;
>>>> + struct qcom_msi *msi;
>>>> +
>>>> + if (!data)
>>>> + return;
>>>> +
>>>> + msi_irq = irq_data_get_irq_chip_data(data);
>>>> + client = msi_irq->client;
>>>> + msi = client->msi;
>>>> +
>>>> + mutex_lock(&msi->mutex);
>>>> + bitmap_clear(msi->bitmap, msi_irq->pos, nr_irqs);
>>>> +
>>>> + client->nr_irqs -= nr_irqs;
>>>> + if (!client->nr_irqs) {
>>>> + list_del(&client->node);
>>>> + kfree(client);
>>>> + }
>>>> + mutex_unlock(&msi->mutex);
>>>> +
>>>> + irq_domain_free_irqs_parent(domain, virq, nr_irqs);
>>>> +}
>>>> +
>>>> +static const struct irq_domain_ops msi_domain_ops = {
>>>> + .alloc = qcom_msi_irq_domain_alloc,
>>>> + .free = qcom_msi_irq_domain_free,
>>>> +};
>>>> +
>>>> +static int qcom_msi_alloc_domains(struct qcom_msi *msi)
>>>> +{
>>>> + msi->inner_domain = irq_domain_add_linear(NULL, msi->nr_virqs,
>>>> + &msi_domain_ops, msi);
>>>> + if (!msi->inner_domain) {
>>>> + dev_err(msi->dev, "failed to create IRQ inner domain\n");
>>>> + return -ENOMEM;
>>>> + }
>>>> +
>>>> + msi->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(msi->dev->of_node),
>>>> + &qcom_msi_domain_info, msi->inner_domain);
>>>> + if (!msi->msi_domain) {
>>>> + dev_err(msi->dev, "failed to create MSI domain\n");
>>>> + irq_domain_remove(msi->inner_domain);
>>>> + return -ENOMEM;
>>>> + }
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int qcom_msi_irq_setup(struct qcom_msi *msi)
>>>> +{
>>>> + struct qcom_msi_grp *msi_grp;
>>>> + struct qcom_msi_irq *msi_irq;
>>>> + int i, index, ret;
>>>> + unsigned int irq;
>>>> +
>>>> + /* setup each MSI group. nr_hwirqs == nr_grps */
>>>> + for (i = 0; i < msi->nr_hwirqs; i++) {
>>>> + irq = irq_of_parse_and_map(msi->dev->of_node, i);
>>>> + if (!irq) {
>>>> + dev_err(msi->dev,
>>>> + "MSI: failed to parse/map interrupt\n");
>>>> + ret = -ENODEV;
>>>> + goto free_irqs;
>>>> + }
>>>> +
>>>> + msi_grp = &msi->grps[i];
>>>> + msi_grp->int_en_reg = msi->pcie_msi_cfg +
>>>> + PCIE_MSI_CTRL_INT_N_EN_OFFS(i);
>>>> + msi_grp->int_mask_reg = msi->pcie_msi_cfg +
>>>> + PCIE_MSI_CTRL_INT_N_MASK_OFFS(i);
>>>> + msi_grp->int_status_reg = msi->pcie_msi_cfg +
>>>> + PCIE_MSI_CTRL_INT_N_STATUS_OFFS(i);
>>>> +
>>>> + for (index = 0; index < MSI_IRQ_PER_GRP; index++) {
>>>> + msi_irq = &msi_grp->irqs[index];
>>>> +
>>>> + msi_irq->grp = msi_grp;
>>>> + msi_irq->grp_index = index;
>>>> + msi_irq->pos = (i * MSI_IRQ_PER_GRP) + index;
>>>> + msi_irq->hwirq = irq;
>>>> + }
>>>> +
>>>> + irq_set_chained_handler_and_data(irq, qcom_msi_handler, msi_grp);
>>>> + }
>>>> +
>>>> + return 0;
>>>> +
>>>> +free_irqs:
>>>> + for (--i; i >= 0; i--) {
>>>> + irq = msi->grps[i].irqs[0].hwirq;
>>>> +
>>>> + irq_set_chained_handler_and_data(irq, NULL, NULL);
>>>> + irq_dispose_mapping(irq);
>>>> + }
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static void qcom_msi_config(struct irq_domain *domain)
>>>> +{
>>>> + struct qcom_msi *msi;
>>>> + int i;
>>>> +
>>>> + msi = domain->parent->host_data;
>>>> +
>>>> + /* program termination address */
>>>> + writel(msi->msi_db_addr, msi->pcie_msi_cfg + PCIE_MSI_CTRL_ADDR_OFFS);
>>>> + writel(0, msi->pcie_msi_cfg + PCIE_MSI_CTRL_UPPER_ADDR_OFFS);
>>>> +
>>>> + /* restore mask and enable all interrupts for each group */
>>>> + for (i = 0; i < msi->nr_grps; i++) {
>>>> + struct qcom_msi_grp *msi_grp = &msi->grps[i];
>>>> +
>>>> + writel(msi_grp->mask, msi_grp->int_mask_reg);
>>>> + writel(~0, msi_grp->int_en_reg);
>>>> + }
>>>> +}
>>>> +
>>>> +static void qcom_msi_deinit(struct qcom_msi *msi)
>>>> +{
>>>> + irq_domain_remove(msi->msi_domain);
>>>> + irq_domain_remove(msi->inner_domain);
>>>> +}
>>>> +
>>>> +static struct qcom_msi *qcom_msi_init(struct device *dev)
>>>> +{
>>>> + struct qcom_msi *msi;
>>>> + u64 addr;
>>>> + int ret;
>>>> +
>>>> + msi = devm_kzalloc(dev, sizeof(*msi), GFP_KERNEL);
>>>> + if (!msi)
>>>> + return ERR_PTR(-ENOMEM);
>>>> +
>>>> + msi->dev = dev;
>>>> + mutex_init(&msi->mutex);
>>>> + spin_lock_init(&msi->cfg_lock);
>>>> + INIT_LIST_HEAD(&msi->clients);
>>>> +
>>>> + msi->msi_db_addr = MSI_DB_ADDR;
>>>> + msi->nr_hwirqs = of_irq_count(dev->of_node);
>>>> + if (!msi->nr_hwirqs) {
>>>> + dev_err(msi->dev, "no hwirqs found\n");
>>>> + return ERR_PTR(-ENODEV);
>>>> + }
>>>> +
>>>> + if (of_property_read_reg(dev->of_node, 0, &addr, NULL) < 0) {
>>>> + dev_err(msi->dev, "failed to get reg address\n");
>>>> + return ERR_PTR(-ENODEV);
>>>> + }
>>>> +
>>>> + dev_dbg(msi->dev, "hwirq:%d pcie_msi_cfg:%llx\n", msi->nr_hwirqs, addr);
>>>> + msi->pcie_msi_cfg = devm_ioremap(dev, addr + PCIE_MSI_CTRL_BASE, PCIE_MSI_CTRL_SIZE);
>>>> + if (!msi->pcie_msi_cfg)
>>>> + return ERR_PTR(-ENOMEM);
>>>> +
>>>> + msi->nr_virqs = msi->nr_hwirqs * MSI_IRQ_PER_GRP;
>>>> + msi->nr_grps = msi->nr_hwirqs;
>>>> + msi->grps = devm_kcalloc(dev, msi->nr_grps, sizeof(*msi->grps), GFP_KERNEL);
>>>> + if (!msi->grps)
>>>> + return ERR_PTR(-ENOMEM);
>>>> +
>>>> + msi->bitmap = devm_kcalloc(dev, BITS_TO_LONGS(msi->nr_virqs),
>>>> + sizeof(*msi->bitmap), GFP_KERNEL);
>>>> + if (!msi->bitmap)
>>>> + return ERR_PTR(-ENOMEM);
>>>> +
>>>> + ret = qcom_msi_alloc_domains(msi);
>>>> + if (ret)
>>>> + return ERR_PTR(ret);
>>>> +
>>>> + ret = qcom_msi_irq_setup(msi);
>>>> + if (ret) {
>>>> + qcom_msi_deinit(msi);
>>>> + return ERR_PTR(ret);
>>>> + }
>>>> +
>>>> + qcom_msi_config(msi->msi_domain);
>>>> + return msi;
>>>> +}
>>>> +
>>>> +static int qcom_pcie_ecam_suspend_noirq(struct device *dev)
>>>> +{
>>>> + return pm_runtime_put_sync(dev);
>>>> +}
>>>> +
>>>> +static int qcom_pcie_ecam_resume_noirq(struct device *dev)
>>>> +{
>>>> + return pm_runtime_get_sync(dev);
>>>> +}
>>>> +
>>>> +static int qcom_pcie_ecam_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct device *dev = &pdev->dev;
>>>> + struct qcom_msi *msi;
>>>> + int ret;
>>>> +
>>>> + ret = devm_pm_runtime_enable(dev);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + ret = pm_runtime_resume_and_get(dev);
>>>> + if (ret < 0) {
>>>> + dev_err(dev, "fail to enable pcie controller: %d\n", ret);
>>>> + return ret;
>>>> + }
>>>> +
>>>> + msi = qcom_msi_init(dev);
>>>> + if (IS_ERR(msi)) {
>>>> + pm_runtime_put_sync(dev);
>>>> + return PTR_ERR(msi);
>>>> + }
>>>> +
>>>> + ret = pci_host_common_probe(pdev);
>>>> + if (ret) {
>>>> + dev_err(dev, "pci_host_common_probe() failed:%d\n", ret);
>>>> + qcom_msi_deinit(msi);
>>>> + pm_runtime_put_sync(dev);
>>>> + }
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static const struct dev_pm_ops qcom_pcie_ecam_pm_ops = {
>>>> + NOIRQ_SYSTEM_SLEEP_PM_OPS(qcom_pcie_ecam_suspend_noirq,
>>>> + qcom_pcie_ecam_resume_noirq)
>>>> +};
>>>> +
>>>> +static const struct pci_ecam_ops qcom_pcie_ecam_ops = {
>>>> + .pci_ops = {
>>>> + .map_bus = pci_ecam_map_bus,
>>>> + .read = pci_generic_config_read,
>>>> + .write = pci_generic_config_write,
>>>> + }
>>>> +};
>>>> +
>>>> +static const struct of_device_id qcom_pcie_ecam_of_match[] = {
>>>> + {
>>>> + .compatible = "qcom,pcie-ecam-rc",
>>>> + .data = &qcom_pcie_ecam_ops,
>>>> + },
>>>> + { },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, qcom_pcie_ecam_of_match);
>>>> +
>>>> +static struct platform_driver qcom_pcie_ecam_driver = {
>>>> + .probe = qcom_pcie_ecam_probe,
>>>> + .driver = {
>>>> + .name = "qcom-pcie-ecam-rc",
>>>> + .suppress_bind_attrs = true,
>>>> + .of_match_table = qcom_pcie_ecam_of_match,
>>>> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
>>>> + .pm = &qcom_pcie_ecam_pm_ops,
>>>> + },
>>>> +};
>>>> +module_platform_driver(qcom_pcie_ecam_driver);
>>>> +
>>>> +MODULE_DESCRIPTION("Qualcomm PCIe ECAM root complex driver");
>>>> +MODULE_LICENSE("GPL");
>>>> --
>>>> 2.7.4
>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH 1/2] Fix typo to allow migrate_qmp_fail command with 'channels' argument
From: Peter Xu @ 2024-04-08 18:56 UTC (permalink / raw)
To: Het Gala
Cc: QEMU Developers, Thomas Huth, Laurent Vivier, Paolo Bonzini,
Fabiano Rosas, Prerna Saxena
In-Reply-To: <76fa8f88-02e2-4431-bb28-5c29bbaa8436@nutanix.com>
[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]
Het,
It's all fine, no worries! This is good enough. Let's finish the
discussion in the next patch before a repost.
Thanks,
On Mon, Apr 8, 2024, 2:35 p.m. Het Gala <het.gala@nutanix.com> wrote:
>
> On 08/04/24 9:05 pm, Peter Xu wrote:
>
> !-------------------------------------------------------------------|
> CAUTION: External Email
>
> |-------------------------------------------------------------------!
>
> Hey, Het,
>
> On Sun, Apr 07, 2024 at 01:21:24PM +0000, Het Gala wrote:
>
> Fixes: (tests/qtest/migration: Add negative tests to validate migration QAPIs)
>
>
> I think I get your intention to provide two fixup patches on top of
> migration-next, which indeed would be preferred so that I can squash them
> into the patches before the pull.
>
> However please next time use "git commit --fixup" so that a better subject
> will be generated, and that'll make my life (and Fabiano's I suppose in the
> future) easier because git rebase understand those subjects. Then you
> don't need Fixes with an empty commit ID. They'll start with "fixup: XXX"
> pointing to a commit with subject rather than commit IDs.
>
> I apologize for any inconvenience caused by not using "git commit --fixup"
> in my previous submission. Let me resend the patchset with correct message
> convention. Will take care of this in future patches too, thanks for
> bringing it to my notice. Regards, Het Gala
>
[-- Attachment #2: Type: text/html, Size: 2486 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/2] gpio-cdev: Release IRQ used by gpio-cdev on gpio chip removal
From: Bartosz Golaszewski @ 2024-04-08 18:57 UTC (permalink / raw)
To: Herve Codina
Cc: Linus Walleij, Kent Gibson, Saravana Kannan, linux-gpio,
linux-kernel, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20240408152715.37948577@bootlin.com>
On Mon, Apr 8, 2024 at 3:27 PM Herve Codina <herve.codina@bootlin.com> wrote:
>
> Hi Bartosz,
>
> On Fri, 1 Mar 2024 08:21:09 +0100
> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> ...
> >
> > I DO want to fix it, don't get me wrong. I don't want to just leave it
> > like this, especially since we've made so much progress with
> > hotpluggability recently. I just don't believe this is the right fix,
> > I will try to come up with a solution that addresses the issue
> > globally.
> >
>
> I didn't see anything but I could miss something.
> Did you move forward on this topic ?
>
No, I'm currently spending almost 100% of my GPIO time on getting the
libgpiod DBus API ready and I should send the first version by the end
of this week. After that I'll be at EOSS and then on vacation, so the
earliest I will get to working on it is early May.
If you feel like giving it another shot - go for it. I believe the
device link problem I described previously[1] must be fixed first. I
would also consider a more generic solution in the interrupt subsystem
that would make it aware that interrupt controllers may be torn down
with interrupts still requested.
As I said: I will get to it but not in the following couple weeks.
Bart
[1] https://lore.kernel.org/lkml/CAMRc=Mf5fRWoOMsJ41vzvE=-vp3wi-Obw=j5fBk3DuQaZNQP2Q@mail.gmail.com/
^ permalink raw reply
* Re: [PATCH v3 07/11] drm/xe/xe2hpg: Remove extra allocation of CCS pages for dgfx
From: Ghimiray, Himal Prasad @ 2024-04-08 18:57 UTC (permalink / raw)
To: intel-xe
In-Reply-To: <20240408170545.3769566-8-balasubramani.vivekanandan@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
On 08-04-2024 22:35, Balasubramani Vivekanandan wrote:
> From: Akshata Jahagirdar<akshata.jahagirdar@intel.com>
>
> On Xe2 dGPU, compression is only supported with VRAM. When copying from
> VRAM -> system memory the KMD uses mapping with uncompressed PAT
> so the copy in system memory is guaranteed to be uncompressed.
> When restoring such buffers from system memory -> VRAM the KMD can't
> easily know which pages were originally compressed, so we always use
> uncompressed -> uncompressed here.
> so this means that there's no need for extra CCS storage on such
> platforms.
>
> v2: More description added to commit message
>
> Signed-off-by: Akshata Jahagirdar<akshata.jahagirdar@intel.com>
> Signed-off-by: Balasubramani Vivekanandan<balasubramani.vivekanandan@intel.com>
> ---
> drivers/gpu/drm/xe/xe_bo.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 6166bc715656..fdeb3691d3f6 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -2201,6 +2201,9 @@ bool xe_bo_needs_ccs_pages(struct xe_bo *bo)
> {
> struct xe_device *xe = xe_bo_device(bo);
>
> + if (GRAPHICS_VER(xe) >= 20 && IS_DGFX(xe))
> + return false;
> +
LGTM.
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> if (!xe_device_has_flat_ccs(xe) || bo->ttm.type != ttm_bo_type_device)
> return false;
>
[-- Attachment #2: Type: text/html, Size: 37755 bytes --]
^ permalink raw reply
* Re: [PATCH v5 0/1] platform/x86: Add wmi driver for Casper Excalibur laptops
From: Armin Wolf @ 2024-04-08 18:56 UTC (permalink / raw)
To: Stella Bloom, Mustafa Ekşi
Cc: Alviro Iskandar Setiawan, Ammar Faizi, Bedirhan KURT,
GNU/Weeb Mailing List, hdegoede, ilpo.jarvinen, jdelvare, lee,
linux-hwmon, linux-kernel, linux-leds, linux, pavel,
platform-driver-x86, Stella Bloom
In-Reply-To: <20240408161345.143779-1-windowz414@gnuweeb.org>
Am 08.04.24 um 18:13 schrieb Stella Bloom:
> On Mon, 2024-04-08 at 18:23 +0300, Mustafa Ekşi wrote:
>> On 7.04.2024 03:57, Stella Bloom wrote:
>>>> From: Mustafa Ekşi <mustafa.eskieksi@gmail.com>
>>>>
>>>> Hi,
>>>> I want to note that moving mutex_init to the bottom of the function
>>>> crashes the driver when mutex_lock is called. I didn't investigate it
>>>> further but I wanted to say that since Ai Chao also did it like that.
>>>>
>>>> Driver sets all leds to white on start. Before that, when a led's
>>>> brightness is changed, that led's color gets set to white but others
>>>> keep their old colors which creates a bad user experience (at least for
>>>> me). Please inform me if this is a bad approach.
>>>> Also, this driver still lacks support for changing modes and I seek
>>>> advise for that.
>>>>
>>>> Mustafa Ekşi (1):
>>>> platform/x86: Add wmi driver for Casper Excalibur laptops
>>>>
>>>> MAINTAINERS | 6 +
>>>> drivers/platform/x86/Kconfig | 14 +
>>>> drivers/platform/x86/Makefile | 1 +
>>>> drivers/platform/x86/casper-wmi.c | 641 ++++++++++++++++++++++++++++++
>>>> 4 files changed, 662 insertions(+)
>>>> create mode 100644 drivers/platform/x86/casper-wmi.c
>>>>
>>> Hi there,
>>>
>>> I just wanted to pitch in by testing the driver on the kernel I use
>>> on my Arch install on an Excalibur G770.1245, namely xdevs23's
>>> linux-nitrous (https://gitlab.com/xdevs23/linux-nitrous), but trying to
>>> compile the driver using LLVM, which is the default compilation behavior
>>> in this kernel's AUR package, spits out the following error;
>>> ```
>>> drivers/platform/x86/casper-wmi.c:633:3: error: field designator 'no_singleton' does not refer to any field in type 'struct wmi_driver'
>>> 633 | .no_singleton = true,
>>> | ~^~~~~~~~~~~~~~~~~~~
>>> 1 error generated.
>>> make[5]: *** [scripts/Makefile.build:243: drivers/platform/x86/casper-wmi.o] Error 1
>>> make[4]: *** [scripts/Makefile.build:481: drivers/platform/x86] Error 2
>>> make[3]: *** [scripts/Makefile.build:481: drivers/platform] Error 2
>>> make[2]: *** [scripts/Makefile.build:481: drivers] Error 2
>>> make[1]: *** [/home/stella/.cache/yay/linux-nitrous/src/linux-nitrous/Makefile:1919: .] Error 2
>>> make: *** [Makefile:240: __sub-make] Error 2
>>> ```
>>>
>>> I want to help debug this somehow, but I'm more of an Android custom
>>> ROM developer than a Linux kernel maintainer, so my knowledge on the
>>> programming and build system languages other than Java, Makefile, Bash,
>>> etc is pretty much limited if not outright non-existent.
>> Hi,
>> This is because of a newly merged patch from Armin Wolf:
>> https://lore.kernel.org/platform-driver-x86/20240226193557.2888-2-W_Armin@gmx.de/
>> You can comment that line or apply that patch to your tree to make it
>> compile. Also, you'll probablyneed to change the call to wmidev_block_set in
>> casper_query function with wmi_set_block (which is now deprecated).
> Well, I prefer not to touch the driver itself, so I already resorted to
> picking the patch over the latest RC, which is v6.9-rc2 as of now, and
> got onto compiling `linux-mainline` AUR package with it. It will be
> kind of a hassle considering how I have to write systemd-boot entries
> after the installation to get the kernel to appear (one for normal
> initramfs and the other for fallback one) and sign the kernel image
> using `sbctl` so I don't fail secure boot, but I'm willing to go
> through it just for the sake of seeing this driver in action without
> bugs related to the "backport" modifications I would do to it.
Hi,
if you use kernel 6.9-rc2, then wmidev_block_set() is already available, so you do not
have to change that.
You just have to comment out the line with the no_singleton flag, then the driver should
work.
Thanks,
Armin Wolf
>>> I would *love* to see this driver actually hit mainline repos, and
>>> eventually the upcoming kernel releases, given how much I need to use
>>> this laptop of mine as a computer engineering student.
>>>
>>> Asking just for the case I manage to get this driver up and going on
>>> my end somehow: Is there a tool made for controlling the LED colors yet?
>>> I can still use CLI tools much like on ASUS ROG series laptops, but it
>>> would be much easier and more appreciated to have a GUI provided
>>> Excalibur series laptops' LED lights can virtually take any color in
>>> the RGB space - At least that's how I interpreted with the
>>> configurations I used to do on mine using Excalibur Control Center
>>> on Windows 10/11.
>> No, there isn't a tool yet but controlling leds via sysfs ispretty easy.
>> For example, if you wanted to change the left led zone's color to red:
>> ```
>> # echo 0xff0000 > /sys/class/leds/casper\:\:kbd_zoned_backlight-left/multi_intensity
>> ```
> Oh so the LED zones are in different sysfs directories, that's pretty
> good. I might code a simple Bash script to make things easier later
> down the road.
>> And don't forget that all leds' initial brightnesses are 0.
> Yeah I think I read that somewhere in the initial message. Can't I
> change the brightness of the LEDs using Fn+Space anyway if I can't find
> the sysfs entries for that? At least it works just fine on the latest
> stable release - v6.8.4.
>> Also, I'm planning to add support for this API in OpenRGB.
> That's pretty nice to hear! If you need someone to test it out on a
> 12th gen G770, I'm more than willing to do so!
>>> And as for the profiles, let me make sure we're talking about the same
>>> thing in this term: You're talking about the "Office", "Gaming" and
>>> "High Performance" modes as seen in Excalibur Control Center, right?
>> For laptops with 11th gen processors or newer: yes.
>> For laptops with 10th gen processors or older: no, there are 4 power
>> profiles for these laptops (High Performance, Gaming, Text Mode andPower
>> save).
> Oh so that's a yes in my case as my laptop has a 12th gen processor.
> Glad to know.
>>> If so, can this be somehow integrated into `power-profiles-daemon`
>>> SystemD service for easier controlling with GNOME and other DEs that
>>> use it? It's fine if it can't be, this was just a thought struck on my
>>> mind for whatever reason.
>> Yes, power-profiles-daemon is already integrated with platform_profile.
> Now that's exciting to hear. I haven't seen a laptop that has its power
> profiles integrated into the system with a driver in terms of Linux...
> At least on the Monster and ASUS laptops I've tried Ubuntu on IIRC.
>>> Please do CC me and the people I've added to the CC list with this email
>>> of mine on the upcoming revisions, if any. We would love to keep track
>>> of this driver and I personally would love to contribute into testing
>>> as a power user.
>>>
>>> Cc: Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>
>>> Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org>
>>> Cc: GNU/Weeb Mailing List <gwml@vger.gnuweeb.org>
>>>
>>> Also adding my organizational and school email addresses to the CC list
>>> so I can still be notified while I stay offline on this email address.
>>> GNOME Evolution doesn't run in the background and periodically check
>>> for emails sadly, and I switch ROMs every now and then on my phone as a
>>> source maintainer of 3 different custom ROMs. :/
>>>
>>> Cc: Stella Bloom <stelbl@elrant.team>
>>> Cc: Bedirhan KURT <bedirhan_kurt22@erdogan.edu.tr>
>>>
>>> --
>>> Stella Bloom
>> Thanks for your interest,
>> Mustafa Ekşi
> Also I apologize for the previous (empty) email. I forgot to put one
> newline after the "Subject" line, which caused git-send-email to not
> pick up the email content.
>
> --
> Stella Bloom
>
^ permalink raw reply
* Re: [LSF/MM/BPF TOPIC] Multi-sized THP performance benchmarks and analysis on ARM64
From: Zi Yan @ 2024-04-08 18:56 UTC (permalink / raw)
To: Matthew Wilcox, Christoph Lameter
Cc: Jonathan Cameron, Yang Shi, lsf-pc, olivier.singla, Linux MM,
Michal Hocko, Dan Williams, Ryan Roberts
In-Reply-To: <ZhQbu8eLYwpTbhah@casper.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]
On 8 Apr 2024, at 12:30, Matthew Wilcox wrote:
> On Thu, Apr 04, 2024 at 11:57:03AM -0700, Christoph Lameter (Ampere) wrote:
>> On Mon, 1 Apr 2024, Jonathan Cameron wrote:
>>
>>> Sounds like useful data, but is it a suitable topic for LSF-MM?
>>> What open questions etc is it raising?
>>
>>
>> mTHP is new functionality that will require additional work to support more
>> use cases. It is also unclear at this point in what usecases mTHP is useful
>> and where no benefit can so far be seen. Also the effect of coalescing
>> multiple PTE entries into one TLB entry is new to MM (CONT_PTE).
I think we need a clarification of CONT_PTE from Christoph.
From the context of ARM CPUs, CONT_PTE might be a group of PTEs with contiguous
bit set. It was used by hugetlb and kernel linear mapping before Ryan added
CONT_PTE support for mTHPs. This requires software support (setting contiguous bits)
to be able to coalesce PTEs. But ARM also has this Hardware Page Aggregation (HPA)
feature[1], which can coalesce PTEs without software intervention. I am not
sure which ARM CPUs actually implement it.
From the context of all CPUs, AMD has "PTE coalescing/clustering"[2] feature
from Zen1. It is similar to ARM's HPA, not requiring software changes to
coalesce PTEs. RISC-V also has Svnapot (Naturally-Aligned Power-of-Two
Address-Translation Contiguity) [3], which requires software help.
So with Matthew's folio patches back in 2020, hardware-only CONT_PTE
would work since then. But software-assist CONT_PTE just began to work
on ARM CPUs with Ryan's cont-pte patchset for anonymous memory and page cache.
>>
>> Ultimately it would be useful to have mTHP support also provide larger
>> blocksize capabilities for filesystem etc etc. mTHP needs to mature and an
>> analysis of the arguable a bit experimental state of affairs can help a lot
>> in getting there.
>
> Have you been paying attention to anything that's been happening in Linux
> development in the last three years? 7b230db3b8d3 introduced folios
> in December 2020 (was merged in November 2021 for v5.16). v5.17 (March
> 2022) did everything short of enabling large folios for the page cache,
> which landed in v5.18 (May 2022). We started using cont-PTEs for large
> folios in August 2023. Again, the page cache led the way here and we're
> just adding support for anonymous large folios (called mTHP) now.
Matthew, your cont-PTE here is "New page table range API" right? There is
no ARM contiguous bit manipulation, right?
>
> There's still a ton of work to do, but we've been busy doing it since
> LSFMM in Puerto Rico (2019) with READ_ONLY_THP_FOR_FS being the very
> first result from the group of interested developers.
>
> And if you haven't seen the results that Ryan Roberts has posted for
> the tests he's run, I suggest you look them up. He does a great job
> of breaking down how much benefit he sees from the hardware side (use of
> contPTE) vs the software side (shorter LRU lists, fewer atomic ops).
It is definitely helpful to distinguish hardware and software benefits,
since not all CPUs can coalesce PTEs.
[1] https://developer.arm.com/documentation/100616/0301/register-descriptions/aarch64-system-registers/cpuectlr-el1--cpu-extended-control-register--el1
[2] https://www.eliot.so/memsys23.pdf
[3] https://github.com/riscv/virtual-memory?tab=readme-ov-file#svnapot-naturally-aligned-power-of-two-address-translation-contiguity
--
Best Regards,
Yan, Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply
* Re: [PATCH] mm: set pageblock_order to HPAGE_PMD_ORDER in case with !CONFIG_HUGETLB_PAGE but THP enabled
From: David Hildenbrand @ 2024-04-08 18:56 UTC (permalink / raw)
To: Baolin Wang, akpm; +Cc: mgorman, vbabka, linux-mm, linux-kernel
In-Reply-To: <3d57d253070035bdc0f6d6e5681ce1ed0e1934f7.1712286863.git.baolin.wang@linux.alibaba.com>
On 05.04.24 14:24, Baolin Wang wrote:
> As Vlastimil suggested in previous discussion[1], it doesn't make sense to set
> pageblock_order as MAX_PAGE_ORDER when hugetlbfs is not enabled and THP is enabled.
> Instead, it should be set to HPAGE_PMD_ORDER.
>
> [1] https://lore.kernel.org/all/76457ec5-d789-449b-b8ca-dcb6ceb12445@suse.cz/
> Suggested-by: Vlastimil Babka <vbabka@suse.cz>
> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> ---
> include/linux/pageblock-flags.h | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/pageblock-flags.h b/include/linux/pageblock-flags.h
> index 3f2409b968ec..547e82cdc89a 100644
> --- a/include/linux/pageblock-flags.h
> +++ b/include/linux/pageblock-flags.h
> @@ -28,7 +28,7 @@ enum pageblock_bits {
> NR_PAGEBLOCK_BITS
> };
>
> -#ifdef CONFIG_HUGETLB_PAGE
> +#if defined(CONFIG_HUGETLB_PAGE)
>
> #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
>
> @@ -45,7 +45,11 @@ extern unsigned int pageblock_order;
>
> #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
>
> -#else /* CONFIG_HUGETLB_PAGE */
> +#elif defined(CONFIG_TRANSPARENT_HUGEPAGE)
> +
> +#define pageblock_order min_t(unsigned int, HPAGE_PMD_ORDER, MAX_PAGE_ORDER)
> +
> +#else /* CONFIG_TRANSPARENT_HUGEPAGE */
>
> /* If huge pages are not used, group by MAX_ORDER_NR_PAGES */
> #define pageblock_order MAX_PAGE_ORDER
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v19 108/130] KVM: TDX: Handle TDX PV HLT hypercall
From: Isaku Yamahata @ 2024-04-08 18:56 UTC (permalink / raw)
To: Chao Gao
Cc: Isaku Yamahata, Sean Christopherson, kvm, linux-kernel,
isaku.yamahata, Paolo Bonzini, erdemaktas, Sagi Shahar, Kai Huang,
chen.bo, hang.yuan, tina.zhang, isaku.yamahata
In-Reply-To: <ZhIX7K0WK+gYtcan@chao-email>
On Sun, Apr 07, 2024 at 11:50:04AM +0800,
Chao Gao <chao.gao@intel.com> wrote:
> >> > >+ union tdx_vcpu_state_details details;
> >> > >+ struct vcpu_tdx *tdx = to_tdx(vcpu);
> >> > >+
> >> > >+ if (ret || vcpu->arch.mp_state != KVM_MP_STATE_HALTED)
> >> > >+ return true;
> >> >
> >> > Question: why mp_state matters here?
> >> > >+
> >> > >+ if (tdx->interrupt_disabled_hlt)
> >> > >+ return false;
> >> >
> >> > Shouldn't we move this into vt_interrupt_allowed()? VMX calls the function to
> >> > check if interrupt is disabled.
> >
> >Chao, are you suggesting to implement tdx_interrupt_allowed() as
> >"EXIT_REASON_HLT && a0" instead of "return true"?
> >I don't think it makes sense because it's rare case and we can't avoid spurious
> >wakeup for TDX case.
>
> Yes. KVM differeniates "interrupt allowed" from "has interrupt", e.g.,
>
> static inline bool kvm_vcpu_has_events(struct kvm_vcpu *vcpu)
> ...
>
> if (kvm_arch_interrupt_allowed(vcpu) &&
> (kvm_cpu_has_interrupt(vcpu) ||
> kvm_guest_apic_has_interrupt(vcpu)))
> return true;
>
>
> I think tdx_protected_apic_has_interrupt() mixes them together, which isn't
> good.
Your point is code clarity. Ok, we can code in that way. I don't expect any
performance difference.
--
Isaku Yamahata <isaku.yamahata@intel.com>
^ permalink raw reply
* [PATCH 9/9] tools/include: Sync arm64 asm/cputype.h with the kernel sources
From: Namhyung Kim @ 2024-04-08 18:55 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Ian Rogers, Kan Liang
Cc: Jiri Olsa, Adrian Hunter, Peter Zijlstra, Ingo Molnar, LKML,
linux-perf-users, Catalin Marinas, Will Deacon, linux-arm-kernel
In-Reply-To: <20240408185520.1550865-1-namhyung@kernel.org>
To pick up the changes from:
fb091ff39479 ("arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata")
This should address these tools/perf build warnings:
Warning: Kernel ABI header differences:
diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
tools/arch/arm64/include/asm/cputype.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/arch/arm64/include/asm/cputype.h b/tools/arch/arm64/include/asm/cputype.h
index 7c7493cb571f..52f076afeb96 100644
--- a/tools/arch/arm64/include/asm/cputype.h
+++ b/tools/arch/arm64/include/asm/cputype.h
@@ -61,6 +61,7 @@
#define ARM_CPU_IMP_HISI 0x48
#define ARM_CPU_IMP_APPLE 0x61
#define ARM_CPU_IMP_AMPERE 0xC0
+#define ARM_CPU_IMP_MICROSOFT 0x6D
#define ARM_CPU_PART_AEM_V8 0xD0F
#define ARM_CPU_PART_FOUNDATION 0xD00
@@ -135,6 +136,8 @@
#define AMPERE_CPU_PART_AMPERE1 0xAC3
+#define MICROSOFT_CPU_PART_AZURE_COBALT_100 0xD49 /* Based on r0p0 of ARM Neoverse N2 */
+
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
#define MIDR_CORTEX_A72 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A72)
@@ -193,6 +196,7 @@
#define MIDR_APPLE_M2_BLIZZARD_MAX MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE, APPLE_CPU_PART_M2_BLIZZARD_MAX)
#define MIDR_APPLE_M2_AVALANCHE_MAX MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE, APPLE_CPU_PART_M2_AVALANCHE_MAX)
#define MIDR_AMPERE1 MIDR_CPU_MODEL(ARM_CPU_IMP_AMPERE, AMPERE_CPU_PART_AMPERE1)
+#define MIDR_MICROSOFT_AZURE_COBALT_100 MIDR_CPU_MODEL(ARM_CPU_IMP_MICROSOFT, MICROSOFT_CPU_PART_AZURE_COBALT_100)
/* Fujitsu Erratum 010001 affects A64FX 1.0 and 1.1, (v0r0 and v1r0) */
#define MIDR_FUJITSU_ERRATUM_010001 MIDR_FUJITSU_A64FX
--
2.44.0.478.gd926399ef9-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 9/9] tools/include: Sync arm64 asm/cputype.h with the kernel sources
From: Namhyung Kim @ 2024-04-08 18:55 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Ian Rogers, Kan Liang
Cc: Jiri Olsa, Adrian Hunter, Peter Zijlstra, Ingo Molnar, LKML,
linux-perf-users, Catalin Marinas, Will Deacon, linux-arm-kernel
In-Reply-To: <20240408185520.1550865-1-namhyung@kernel.org>
To pick up the changes from:
fb091ff39479 ("arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata")
This should address these tools/perf build warnings:
Warning: Kernel ABI header differences:
diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
tools/arch/arm64/include/asm/cputype.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/arch/arm64/include/asm/cputype.h b/tools/arch/arm64/include/asm/cputype.h
index 7c7493cb571f..52f076afeb96 100644
--- a/tools/arch/arm64/include/asm/cputype.h
+++ b/tools/arch/arm64/include/asm/cputype.h
@@ -61,6 +61,7 @@
#define ARM_CPU_IMP_HISI 0x48
#define ARM_CPU_IMP_APPLE 0x61
#define ARM_CPU_IMP_AMPERE 0xC0
+#define ARM_CPU_IMP_MICROSOFT 0x6D
#define ARM_CPU_PART_AEM_V8 0xD0F
#define ARM_CPU_PART_FOUNDATION 0xD00
@@ -135,6 +136,8 @@
#define AMPERE_CPU_PART_AMPERE1 0xAC3
+#define MICROSOFT_CPU_PART_AZURE_COBALT_100 0xD49 /* Based on r0p0 of ARM Neoverse N2 */
+
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
#define MIDR_CORTEX_A72 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A72)
@@ -193,6 +196,7 @@
#define MIDR_APPLE_M2_BLIZZARD_MAX MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE, APPLE_CPU_PART_M2_BLIZZARD_MAX)
#define MIDR_APPLE_M2_AVALANCHE_MAX MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE, APPLE_CPU_PART_M2_AVALANCHE_MAX)
#define MIDR_AMPERE1 MIDR_CPU_MODEL(ARM_CPU_IMP_AMPERE, AMPERE_CPU_PART_AMPERE1)
+#define MIDR_MICROSOFT_AZURE_COBALT_100 MIDR_CPU_MODEL(ARM_CPU_IMP_MICROSOFT, MICROSOFT_CPU_PART_AZURE_COBALT_100)
/* Fujitsu Erratum 010001 affects A64FX 1.0 and 1.1, (v0r0 and v1r0) */
#define MIDR_FUJITSU_ERRATUM_010001 MIDR_FUJITSU_A64FX
--
2.44.0.478.gd926399ef9-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.