Re: [PATCH] docs: move powerpc under arch

2023-10-03 Thread Michael Ellerman



On October 4, 2023 3:05:48 AM GMT+11:00, Jonathan Corbet  wrote:
>Costa Shulyupin  writes:
>
>> and fix all in-tree references.
>>
>> Architecture-specific documentation is being moved into Documentation/arch/
>> as a way of cleaning up the top-level documentation directory and making
>> the docs hierarchy more closely match the source hierarchy.
>>
>> Signed-off-by: Costa Shulyupin 
>
>So this patch appears to have not been picked up, and to have received
>no comments.  I'll happily carry it in docs-next, but it would be nice
>to have an ack from the powerpc folks...?

I acked it a few months back, and said I assumed you were merging it:

https://lore.kernel.org/linuxppc-dev/87bkfwem93.fsf@mail.lhotse/

I don't mind who merges it, I figured you merging it would generate fewer 
conflicts, but I'm happy to take it if you think that would be better.

Anyway here's another:

Acked-by: Michael Ellerman  (powerpc)

cheers
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.


Re: [PATCH] docs: move powerpc under arch

2023-10-03 Thread Linas Vepstas
Hi Jon,

Got the message; I'm not an active maintainer, haven't been for over a
decade, and cannot comment on style issues. But if all the other arches are
doing this, I see no reason why not. Feel free to interpret this as an
Acked-by: if that's appropriate.

-- linas

On Tue, Oct 3, 2023 at 11:05 AM Jonathan Corbet  wrote:

> Costa Shulyupin  writes:
>
> > and fix all in-tree references.
> >
> > Architecture-specific documentation is being moved into
> Documentation/arch/
> > as a way of cleaning up the top-level documentation directory and making
> > the docs hierarchy more closely match the source hierarchy.
> >
> > Signed-off-by: Costa Shulyupin 
>
> So this patch appears to have not been picked up, and to have received
> no comments.  I'll happily carry it in docs-next, but it would be nice
> to have an ack from the powerpc folks...?
>
> Thanks,
>
> jon
>


-- 
Patrick: Are they laughing at us?
Sponge Bob: No, Patrick, they are laughing next to us.


Re: [PATCH v3 03/13] mm/execmem, arch: convert simple overrides of module_alloc to execmem

2023-10-03 Thread Edgecombe, Rick P
On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> +
> +static void execmem_init_missing(struct execmem_params *p)
> +{
> +   struct execmem_range *default_range = 
> >ranges[EXECMEM_DEFAULT];
> +
> +   for (int i = EXECMEM_DEFAULT + 1; i < EXECMEM_TYPE_MAX; i++)
> {
> +   struct execmem_range *r = >ranges[i];
> +
> +   if (!r->start) {
> +   r->pgprot = default_range->pgprot;
> +   r->alignment = default_range->alignment;
> +   r->start = default_range->start;
> +   r->end = default_range->end;
> +   }
> +   }
> +}
> +

It seems a bit weird to copy all of this. Is it trying to be faster or
something?

Couldn't it just check r->start in execmem_text/data_alloc() path and
switch to EXECMEM_DEFAULT if needed then? The execmem_range_is_data()
part that comes later could be added to the logic there too. So this
seems like unnecessary complexity to me or I don't see the reason.


Re: [PATCH v3 04/13] mm/execmem, arch: convert remaining overrides of module_alloc to execmem

2023-10-03 Thread Edgecombe, Rick P
On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> index 5f71a0cf4399..9d37375e2f05 100644
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -36,55 +37,30 @@ do
> {\
>  } while (0)
>  #endif
>  
> -#ifdef CONFIG_RANDOMIZE_BASE
> -static unsigned long module_load_offset;
> +static struct execmem_params execmem_params __ro_after_init = {
> +   .ranges = {
> +   [EXECMEM_DEFAULT] = {
> +   .flags = EXECMEM_KASAN_SHADOW,
> +   .alignment = MODULE_ALIGN,
> +   },
> +   },
> +};
>  
> -/* Mutex protects the module_load_offset. */
> -static DEFINE_MUTEX(module_kaslr_mutex);
> -
> -static unsigned long int get_module_load_offset(void)
> -{
> -   if (kaslr_enabled()) {
> -   mutex_lock(_kaslr_mutex);
> -   /*
> -    * Calculate the module_load_offset the first time
> this
> -    * code is called. Once calculated it stays the same
> until
> -    * reboot.
> -    */
> -   if (module_load_offset == 0)
> -   module_load_offset =
> -   get_random_u32_inclusive(1, 1024) *
> PAGE_SIZE;
> -   mutex_unlock(_kaslr_mutex);
> -   }
> -   return module_load_offset;
> -}
> -#else
> -static unsigned long int get_module_load_offset(void)
> -{
> -   return 0;
> -}
> -#endif
> -
> -void *module_alloc(unsigned long size)
> +struct execmem_params __init *execmem_arch_params(void)
>  {
> -   gfp_t gfp_mask = GFP_KERNEL;
> -   void *p;
> -
> -   if (PAGE_ALIGN(size) > MODULES_LEN)
> -   return NULL;
> +   unsigned long module_load_offset = 0;
> +   unsigned long start;
>  
> -   p = __vmalloc_node_range(size, MODULE_ALIGN,
> -    MODULES_VADDR +
> get_module_load_offset(),
> -    MODULES_END, gfp_mask, PAGE_KERNEL,
> -    VM_FLUSH_RESET_PERMS |
> VM_DEFER_KMEMLEAK,
> -    NUMA_NO_NODE,
> __builtin_return_address(0));
> +   if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && kaslr_enabled())
> +   module_load_offset =
> +   get_random_u32_inclusive(1, 1024) *
> PAGE_SIZE;

Minor:
I think you can skip the IS_ENABLED(CONFIG_RANDOMIZE_BASE) part because
CONFIG_RANDOMIZE_MEMORY depends on CONFIG_RANDOMIZE_BASE (which is
checked in kaslr_enabled()).


[net-next PATCH v2 4/4] netdev: use napi_schedule bool instead of napi_schedule_prep/__napi_schedule

2023-10-03 Thread Christian Marangi
Replace if condition of napi_schedule_prep/__napi_schedule and use bool
from napi_schedule directly where possible.

Signed-off-by: Christian Marangi 
---
 drivers/net/ethernet/atheros/atlx/atl1.c | 4 +---
 drivers/net/ethernet/toshiba/tc35815.c   | 4 +---
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 4 +---
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c 
b/drivers/net/ethernet/atheros/atlx/atl1.c
index 02aa6fd8ebc2..a9014d7932db 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -2446,7 +2446,7 @@ static int atl1_rings_clean(struct napi_struct *napi, int 
budget)
 
 static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter)
 {
-   if (!napi_schedule_prep(>napi))
+   if (!napi_schedule(>napi))
/* It is possible in case even the RX/TX ints are disabled via 
IMR
 * register the ISR bits are set anyway (but do not produce 
IRQ).
 * To handle such situation the napi functions used to check is
@@ -2454,8 +2454,6 @@ static inline int atl1_sched_rings_clean(struct 
atl1_adapter* adapter)
 */
return 0;
 
-   __napi_schedule(>napi);
-
/*
 * Disable RX/TX ints via IMR register if it is
 * allowed. NAPI handler must reenable them in same
diff --git a/drivers/net/ethernet/toshiba/tc35815.c 
b/drivers/net/ethernet/toshiba/tc35815.c
index 14cf6ecf6d0d..a8b8a0e13f9a 100644
--- a/drivers/net/ethernet/toshiba/tc35815.c
+++ b/drivers/net/ethernet/toshiba/tc35815.c
@@ -1436,9 +1436,7 @@ static irqreturn_t tc35815_interrupt(int irq, void 
*dev_id)
if (!(dmactl & DMA_IntMask)) {
/* disable interrupts */
tc_writel(dmactl | DMA_IntMask, >DMA_Ctl);
-   if (napi_schedule_prep(>napi))
-   __napi_schedule(>napi);
-   else {
+   if (!napi_schedule(>napi)) {
printk(KERN_ERR "%s: interrupt taken in poll\n",
   dev->name);
BUG();
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index 23b5a0adcbd6..146bc7bd14fb 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1660,9 +1660,7 @@ irqreturn_t iwl_pcie_irq_rx_msix_handler(int irq, void 
*dev_id)
IWL_DEBUG_ISR(trans, "[%d] Got interrupt\n", entry->entry);
 
local_bh_disable();
-   if (napi_schedule_prep(>napi))
-   __napi_schedule(>napi);
-   else
+   if (!napi_schedule(>napi))
iwl_pcie_clear_irq(trans, entry->entry);
local_bh_enable();
 
-- 
2.40.1



[net-next PATCH v2 3/4] netdev: replace napi_reschedule with napi_schedule

2023-10-03 Thread Christian Marangi
Now that napi_schedule return a bool, we can drop napi_reschedule that
does the same exact function. The function comes from a very old commit
bfe13f54f502 ("ibm_emac: Convert to use napi_struct independent of struct
net_device") and the purpose is actually deprecated in favour of
different logic.

Convert every user of napi_reschedule to napi_schedule.

Signed-off-by: Christian Marangi 
Acked-by: Jeff Johnson  # ath10k
Acked-by: Nick Child  # ibm
Acked-by: Marc Kleine-Budde  # for can/dev/rx-offload.c
---
Changes v2:
- Add ack tag
---
 drivers/infiniband/ulp/ipoib/ipoib_ib.c|  4 ++--
 drivers/net/can/dev/rx-offload.c   |  2 +-
 drivers/net/ethernet/chelsio/cxgb4/sge.c   |  2 +-
 drivers/net/ethernet/chelsio/cxgb4vf/sge.c |  2 +-
 drivers/net/ethernet/ezchip/nps_enet.c |  2 +-
 drivers/net/ethernet/google/gve/gve_main.c |  2 +-
 drivers/net/ethernet/ibm/ehea/ehea_main.c  |  2 +-
 drivers/net/ethernet/ibm/emac/mal.c|  2 +-
 drivers/net/ethernet/ibm/ibmveth.c |  2 +-
 drivers/net/ethernet/ibm/ibmvnic.c |  2 +-
 drivers/net/ethernet/mellanox/mlx4/en_rx.c |  2 +-
 drivers/net/ethernet/ni/nixge.c|  2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c |  2 +-
 drivers/net/ethernet/xscale/ixp4xx_eth.c   |  4 ++--
 drivers/net/fjes/fjes_main.c   |  2 +-
 drivers/net/wan/ixp4xx_hss.c   |  4 ++--
 drivers/net/wireless/ath/ath10k/pci.c  |  2 +-
 drivers/net/wwan/t7xx/t7xx_hif_dpmaif_rx.c |  2 +-
 include/linux/netdevice.h  | 10 --
 19 files changed, 21 insertions(+), 31 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c 
b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index ed25061fac62..7f84d9866cef 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -488,7 +488,7 @@ int ipoib_rx_poll(struct napi_struct *napi, int budget)
if (unlikely(ib_req_notify_cq(priv->recv_cq,
  IB_CQ_NEXT_COMP |
  IB_CQ_REPORT_MISSED_EVENTS)) &&
-   napi_reschedule(napi))
+   napi_schedule(napi))
goto poll_more;
}
 
@@ -518,7 +518,7 @@ int ipoib_tx_poll(struct napi_struct *napi, int budget)
napi_complete(napi);
if (unlikely(ib_req_notify_cq(priv->send_cq, IB_CQ_NEXT_COMP |
  IB_CQ_REPORT_MISSED_EVENTS)) &&
-   napi_reschedule(napi))
+   napi_schedule(napi))
goto poll_more;
}
return n < 0 ? 0 : n;
diff --git a/drivers/net/can/dev/rx-offload.c b/drivers/net/can/dev/rx-offload.c
index 77091f7d1fa7..46e7b6db4a1e 100644
--- a/drivers/net/can/dev/rx-offload.c
+++ b/drivers/net/can/dev/rx-offload.c
@@ -67,7 +67,7 @@ static int can_rx_offload_napi_poll(struct napi_struct *napi, 
int quota)
 
/* Check if there was another interrupt */
if (!skb_queue_empty(>skb_queue))
-   napi_reschedule(>napi);
+   napi_schedule(>napi);
}
 
return work_done;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 98dd78551d89..b5ff2e1a9975 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -4261,7 +4261,7 @@ static void sge_rx_timer_cb(struct timer_list *t)
 
if (fl_starving(adap, fl)) {
rxq = container_of(fl, struct sge_eth_rxq, fl);
-   if (napi_reschedule(>rspq.napi))
+   if (napi_schedule(>rspq.napi))
fl->starving++;
else
set_bit(id, s->starving_fl);
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
index 2d0cf76fb3c5..5b1d746e6563 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
@@ -2094,7 +2094,7 @@ static void sge_rx_timer_cb(struct timer_list *t)
struct sge_eth_rxq *rxq;
 
rxq = container_of(fl, struct sge_eth_rxq, fl);
-   if (napi_reschedule(>rspq.napi))
+   if (napi_schedule(>rspq.napi))
fl->starving++;
else
set_bit(id, s->starving_fl);
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c 

[net-next PATCH v2 2/4] netdev: make napi_schedule return bool on NAPI successful schedule

2023-10-03 Thread Christian Marangi
Change napi_schedule to return a bool on NAPI successful schedule.
This might be useful for some driver to do additional steps after a
NAPI has been scheduled.

Suggested-by: Eric Dumazet 
Signed-off-by: Christian Marangi 
Reviewed-by: Eric Dumazet 
---
Changes v2:
- Add Suggested-by tag
- Add Reviewed-by tag
---
 include/linux/netdevice.h | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 7e520c14eb8c..2bead8e2a14d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -490,11 +490,18 @@ bool napi_schedule_prep(struct napi_struct *n);
  *
  * Schedule NAPI poll routine to be called if it is not already
  * running.
+ * Return true if we schedule a NAPI or false if not.
+ * Refer to napi_schedule_prep() for additional reason on why
+ * a NAPI might not be scheduled.
  */
-static inline void napi_schedule(struct napi_struct *n)
+static inline bool napi_schedule(struct napi_struct *n)
 {
-   if (napi_schedule_prep(n))
+   if (napi_schedule_prep(n)) {
__napi_schedule(n);
+   return true;
+   }
+
+   return false;
 }
 
 /**
-- 
2.40.1



[net-next PATCH v2 1/4] netdev: replace simple napi_schedule_prep/__napi_schedule to napi_schedule

2023-10-03 Thread Christian Marangi
Replace drivers that still use napi_schedule_prep/__napi_schedule
with napi_schedule helper as it does the same exact check and call.

Signed-off-by: Christian Marangi 
---
Changes v2:
- Add missing semicolon
---
 drivers/net/ethernet/ni/nixge.c | 3 +--
 drivers/net/ethernet/wiznet/w5100.c | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/ni/nixge.c b/drivers/net/ethernet/ni/nixge.c
index 97f4798f4b42..f71a4f8bbb89 100644
--- a/drivers/net/ethernet/ni/nixge.c
+++ b/drivers/net/ethernet/ni/nixge.c
@@ -755,8 +755,7 @@ static irqreturn_t nixge_rx_irq(int irq, void *_ndev)
cr &= ~(XAXIDMA_IRQ_IOC_MASK | XAXIDMA_IRQ_DELAY_MASK);
nixge_dma_write_reg(priv, XAXIDMA_RX_CR_OFFSET, cr);
 
-   if (napi_schedule_prep(>napi))
-   __napi_schedule(>napi);
+   napi_schedule(>napi);
goto out;
}
if (!(status & XAXIDMA_IRQ_ALL_MASK)) {
diff --git a/drivers/net/ethernet/wiznet/w5100.c 
b/drivers/net/ethernet/wiznet/w5100.c
index 341ee2f249fd..b26fd15c25ae 100644
--- a/drivers/net/ethernet/wiznet/w5100.c
+++ b/drivers/net/ethernet/wiznet/w5100.c
@@ -930,8 +930,8 @@ static irqreturn_t w5100_interrupt(int irq, void 
*ndev_instance)
 
if (priv->ops->may_sleep)
queue_work(priv->xfer_wq, >rx_work);
-   else if (napi_schedule_prep(>napi))
-   __napi_schedule(>napi);
+   else
+   napi_schedule(>napi);
}
 
return IRQ_HANDLED;
-- 
2.40.1



Re: [PATCH] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries

2023-10-03 Thread Peter Bergner
On 10/3/23 9:08 AM, Adhemerval Zanella Netto wrote:
> What it is not clear to me is what kind of ABI boundary you are trying to
> preemptively add support here. The TCB ABI for __builtin_cpu_supports is
> userland only, so if your intention is just to allow gcc to work on older
> glibcs, it should be a matter to just reserve the space on tcbhead_t.

Yes, extending tcbhead_t to contain the slots for hwcap3 and hwcap4 are the
ABI extensions we are interested in, and not something that can be backported
into a distro point release.  Yes, we don't strictly need the AT_HWCAP3 and
AT_HWCAP4 kernel defines to reserve (and clear) that space in glibc, but



> If your intention is to also add support on glibc, it makes more sense to
> already reserve it.  For __builtin_cpu_supports it should work, although
> for glibc itself some backporting would be required (to correctly showing
> the bits with LD_SHOW_AUXV).

Our intention is to also add the glibc support too once we have the
AT_HWCAP3 and AT_HWCAP4 kernel macros defined.  1) Once the defines are
there, adding the support should be pretty straight forward, so why wait?
And 2) part of the glibc and compiler support introduces a new symbol
that is exported by glibc and referenced by the compilers to ensure the
compilers *never* access the hwcap* fields in the TCB unless the glibc
supports them.  See the symbol __parse_hwcap_and_convert_at_platform used
for HWCAP/HWCAP2.  We'll need a similar one for HWCAP3/HWCAP4 and I'm
doubtful whether the distros will allow the backport of a patch that
introduces a new exported symbol from glibc in a distro point release.


Peter




Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes

2023-10-03 Thread Sean Christopherson
On Tue, Oct 03, 2023, Fuad Tabba wrote:
> On Tue, Oct 3, 2023 at 4:59 PM Sean Christopherson  wrote:
> > On Tue, Oct 03, 2023, Fuad Tabba wrote:
> > > > +#define KVM_MEMORY_ATTRIBUTE_PRIVATE   (1ULL << 3)
> > > > +
> > >
> > > In pKVM, we don't want to allow setting (or clearing) of PRIVATE/SHARED
> > > attributes from userspace.
> >
> > Why not?  The whole thing falls apart if userspace doesn't *know* the state 
> > of a
> > page, and the only way for userspace to know the state of a page at a given 
> > moment
> > in time is if userspace controls the attributes.  E.g. even if KVM were to 
> > provide
> > a way for userspace to query attributes, the attributes exposed to usrspace 
> > would
> > become stale the instant KVM drops slots_lock (or whatever lock protects 
> > the attributes)
> > since userspace couldn't prevent future changes.
> 
> I think I might not quite understand the purpose of the
> KVM_SET_MEMORY_ATTRIBUTES ABI. In pKVM, all of a protected guest's memory is
> private by default, until the guest shares it with the host (via a
> hypercall), or another guest (future work). When the guest shares it,
> userspace is notified via KVM_EXIT_HYPERCALL. In many use cases, userspace
> doesn't need to keep track directly of all of this, but can reactively un/map
> the memory being un/shared.

Yes, and then userspace needs to tell KVM, via KVM_SET_MEMORY_ATTRIBUTES, that
userspace has agreed to change the state of the page.  Userspace may not 
need/want
to explicitly track the state of pages, but userspace still needs to tell KVM 
what
userspace wants.

KVM is primarily an accelerator, e.g. KVM's role is to make things go fast 
(relative
to doing things in userspace) and provide access to resources/instructions that
require elevated privileges.  As a general rule, we try to avoid defining the 
vCPU
model, security policies, etc. in KVM, because hardcoding policy into KVM (and 
the
kernel as a whole) eventually limits the utility of KVM.

As it pertains to PRIVATE vs. SHARED, KVM's role is to define and enforce the 
basic
rules, but KVM shouldn't do things like define when it is (il)legal to convert
memory to/from SHARED, what pages can be converted, what happens if the guest 
and
userspace disagree, etc.

> > Why does pKVM need to prevent userspace from stating *its* view of 
> > attributes?
> >
> > If the goal is to reduce memory overhead, that can be solved by using an 
> > internal,
> > non-ABI attributes flag to track pKVM's view of SHARED vs. PRIVATE.  If the 
> > guest
> > attempts to access memory where pKVM and userspace don't agree on the state,
> > generate an exit to userspace.  Or kill the guest.  Or do something else 
> > entirely.
> 
> For the pKVM hypervisor the guest's view of the attributes doesn't
> matter. The hypervisor at the end of the day is the ultimate arbiter
> for what is shared and with how. For pKVM (at least in my port of
> guestmem), we use the memory attributes from guestmem essentially to
> control which memory can be mapped by the host.

The guest's view absolutely matters.  The guest's view may not be expressed at
access time, e.g. as you note below, pKVM and other software-protected VMs don't
have a dedicated shared vs. private bit like TDX and SNP.  But the view is still
there, e.g. in the pKVM model, the guest expresses its desire for shared vs.
private via hypercall, and IIRC, the guest's view is tracked by the hypervisor
in the stage-2 PTEs.  pKVM itself may track the guest's view on things, but the
view is still the guest's.

E.g. if the guest thinks a page is private, but in reality KVM and host 
userspace
have it as shared, then the guest may unintentionally leak data to the untrusted
world.

IIUC, you have implemented guest_memfd support in pKVM by changing the 
attributes
when the guest makes the hypercall.  This can work, but only so long as the 
guest
and userspace are well-behaved, and it will likely paint pKVM into a corner in
the long run.

E.g. if the guest makes a hypercall to convert memory to PRIVATE, but there is
no memslot or the memslot doesn't support private memory, then unless there is
policy baked into KVM, or an ABI for the guest<=>host hypercall interface that
allows unwinding the program counter, you're stuck.  Returning an error for the
hypercall straight from KVM is undesirable as that would put policy into KVM 
that
doesn't need to be there, e.g. that would prevent userspace from manipulating
memslots in response to (un)share requests from the guest.  It's a similar story
if KVM marks the page as PRIVATE, as that would prevent userspace from returning
an error for the hypercall, i.e. would prevent usersepace from denying the 
request
to convert to PRIVATE.

> One difference between pKVM and TDX (as I understand it), is that TDX
> uses the msb of the guest's IPA to indicate whether memory is shared
> or private, and that can generate a mismatch on guest memory access
> between what it thinks the state is, and what the sharing 

Re: [PATCH RESEND 1/5] ASoC: Explicitly include correct DT includes

2023-10-03 Thread Jernej Škrabec
Dne torek, 03. oktober 2023 ob 20:13:10 CEST je Rob Herring napisal(a):
> The DT of_device.h and of_platform.h date back to the separate
> of_platform_bus_type before it was merged into the regular platform bus.
> As part of that merge prepping Arm DT support 13 years ago, they
> "temporarily" include each other. They also include platform_device.h
> and of.h. As a result, there's a pretty much random mix of those include
> files used throughout the tree. In order to detangle these headers and
> replace the implicit includes with struct declarations, users need to
> explicitly include the correct includes.
> 
> Signed-off-by: Rob Herring 
> ---
>  sound/soc/atmel/atmel_wm8904.c | 1 -
>  sound/soc/atmel/mchp-i2s-mcc.c | 2 +-
>  sound/soc/atmel/tse850-pcm5142.c   | 1 -
>  sound/soc/bcm/cygnus-ssp.c | 2 +-
>  sound/soc/codecs/adau1701.c| 1 -
>  sound/soc/codecs/adau1977-spi.c| 1 -
>  sound/soc/codecs/ak4104.c  | 2 +-
>  sound/soc/codecs/ak4118.c  | 2 +-
>  sound/soc/codecs/ak4375.c  | 2 +-
>  sound/soc/codecs/ak4458.c  | 2 +-
>  sound/soc/codecs/ak4613.c  | 2 +-
>  sound/soc/codecs/ak4642.c  | 2 +-
>  sound/soc/codecs/ak5558.c  | 2 +-
>  sound/soc/codecs/cs35l32.c | 2 +-
>  sound/soc/codecs/cs35l33.c | 2 --
>  sound/soc/codecs/cs35l34.c | 2 +-
>  sound/soc/codecs/cs35l35.c | 3 +--
>  sound/soc/codecs/cs35l36.c | 3 +--
>  sound/soc/codecs/cs35l41-i2c.c | 2 +-
>  sound/soc/codecs/cs35l41.c | 1 -
>  sound/soc/codecs/cs4270.c  | 2 +-
>  sound/soc/codecs/cs42l42.c | 1 -
>  sound/soc/codecs/cs42l56.c | 2 +-
>  sound/soc/codecs/cs42xx8-i2c.c | 2 +-
>  sound/soc/codecs/cs43130.c | 3 +--
>  sound/soc/codecs/cs4349.c  | 2 +-
>  sound/soc/codecs/da7213.c  | 2 +-
>  sound/soc/codecs/da7219.c  | 2 +-
>  sound/soc/codecs/da9055.c  | 1 -
>  sound/soc/codecs/es8328.c  | 1 -
>  sound/soc/codecs/gtm601.c  | 2 +-
>  sound/soc/codecs/lpass-macro-common.c  | 2 +-
>  sound/soc/codecs/mt6351.c  | 2 +-
>  sound/soc/codecs/mt6358.c  | 2 +-
>  sound/soc/codecs/mt6359-accdet.c   | 4 
>  sound/soc/codecs/mt6359.c  | 2 +-
>  sound/soc/codecs/nau8540.c | 2 +-
>  sound/soc/codecs/pcm1681.c | 2 --
>  sound/soc/codecs/rt715.c   | 2 --
>  sound/soc/codecs/sgtl5000.c| 2 +-
>  sound/soc/codecs/sma1303.c | 2 +-
>  sound/soc/codecs/sta32x.c  | 3 +--
>  sound/soc/codecs/sta350.c  | 3 +--
>  sound/soc/codecs/tas571x.c | 2 +-
>  sound/soc/codecs/uda1334.c | 2 +-
>  sound/soc/codecs/wm8510.c  | 2 +-
>  sound/soc/codecs/wm8523.c  | 2 +-
>  sound/soc/codecs/wm8524.c  | 2 +-
>  sound/soc/codecs/wm8580.c  | 2 +-
>  sound/soc/codecs/wm8711.c  | 2 +-
>  sound/soc/codecs/wm8728.c  | 2 +-
>  sound/soc/codecs/wm8731-i2c.c  | 2 +-
>  sound/soc/codecs/wm8731-spi.c  | 2 +-
>  sound/soc/codecs/wm8737.c  | 2 +-
>  sound/soc/codecs/wm8741.c  | 2 +-
>  sound/soc/codecs/wm8750.c  | 2 +-
>  sound/soc/codecs/wm8753.c  | 2 +-
>  sound/soc/codecs/wm8770.c  | 2 +-
>  sound/soc/codecs/wm8776.c  | 2 +-
>  sound/soc/codecs/wm8804.c  | 1 -
>  sound/soc/fsl/efika-audio-fabric.c | 4 ++--
>  sound/soc/fsl/fsl_aud2htx.c| 3 +--
>  sound/soc/fsl/fsl_mqs.c| 2 

Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes

2023-10-03 Thread Fuad Tabba
Hi Sean,


On Tue, Oct 3, 2023 at 4:59 PM Sean Christopherson  wrote:
>
> On Tue, Oct 03, 2023, Fuad Tabba wrote:
> > Hi,
> >
> > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > > index d2d913acf0df..f8642ff2eb9d 100644
> > > --- a/include/uapi/linux/kvm.h
> > > +++ b/include/uapi/linux/kvm.h
> > > @@ -1227,6 +1227,7 @@ struct kvm_ppc_resize_hpt {
> > >  #define KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE 228
> > >  #define KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES 229
> > >  #define KVM_CAP_USER_MEMORY2 230
> > > +#define KVM_CAP_MEMORY_ATTRIBUTES 231
> > >
> > >  #ifdef KVM_CAP_IRQ_ROUTING
> > >
> > > @@ -2293,4 +2294,17 @@ struct kvm_s390_zpci_op {
> > >  /* flags for kvm_s390_zpci_op->u.reg_aen.flags */
> > >  #define KVM_S390_ZPCIOP_REGAEN_HOST(1 << 0)
> > >
> > > +/* Available with KVM_CAP_MEMORY_ATTRIBUTES */
> > > +#define KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES_IOR(KVMIO,  0xd2, __u64)
> > > +#define KVM_SET_MEMORY_ATTRIBUTES  _IOW(KVMIO,  0xd3, struct 
> > > kvm_memory_attributes)
> > > +
> > > +struct kvm_memory_attributes {
> > > +   __u64 address;
> > > +   __u64 size;
> > > +   __u64 attributes;
> > > +   __u64 flags;
> > > +};
> > > +
> > > +#define KVM_MEMORY_ATTRIBUTE_PRIVATE   (1ULL << 3)
> > > +
> >
> > In pKVM, we don't want to allow setting (or clearing) of PRIVATE/SHARED
> > attributes from userspace.
>
> Why not?  The whole thing falls apart if userspace doesn't *know* the state 
> of a
> page, and the only way for userspace to know the state of a page at a given 
> moment
> in time is if userspace controls the attributes.  E.g. even if KVM were to 
> provide
> a way for userspace to query attributes, the attributes exposed to usrspace 
> would
> become stale the instant KVM drops slots_lock (or whatever lock protects the 
> attributes)
> since userspace couldn't prevent future changes.

I think I might not quite understand the purpose of the
KVM_SET_MEMORY_ATTRIBUTES ABI. In pKVM, all of a protected guest's
memory is private by default, until the guest shares it with the host
(via a hypercall), or another guest (future work). When the guest
shares it, userspace is notified via KVM_EXIT_HYPERCALL. In many use
cases, userspace doesn't need to keep track directly of all of this,
but can reactively un/map the memory being un/shared.

> Why does pKVM need to prevent userspace from stating *its* view of attributes?
>
> If the goal is to reduce memory overhead, that can be solved by using an 
> internal,
> non-ABI attributes flag to track pKVM's view of SHARED vs. PRIVATE.  If the 
> guest
> attempts to access memory where pKVM and userspace don't agree on the state,
> generate an exit to userspace.  Or kill the guest.  Or do something else 
> entirely.

For the pKVM hypervisor the guest's view of the attributes doesn't
matter. The hypervisor at the end of the day is the ultimate arbiter
for what is shared and with how. For pKVM (at least in my port of
guestmem), we use the memory attributes from guestmem essentially to
control which memory can be mapped by the host.

One difference between pKVM and TDX (as I understand it), is that TDX
uses the msb of the guest's IPA to indicate whether memory is shared
or private, and that can generate a mismatch on guest memory access
between what it thinks the state is, and what the sharing state in
reality is. pKVM doesn't have that. Memory is private by default, and
can be shared in-place, both in the guest's IPA space as well as the
underlying physical page.

> > However, we'd like to use the attributes xarray to track the sharing state 
> > of
> > guest pages at the host kernel.
> >
> > Moreover, we'd rather the default guest page state be PRIVATE, and
> > only specify which pages are shared. All pKVM guest pages start off as
> > private, and the majority will remain so.
>
> I would rather optimize kvm_vm_set_mem_attributes() to generate range-based
> xarray entries, at which point it shouldn't matter all that much whether 
> PRIVATE
> or SHARED is the default "empty" state.  We opted not to do that for the 
> initial
> merge purely to keep the code as simple as possible (which is obviously still 
> not
> exactly simple).
>
> With range-based xarray entries, the cost of tagging huge chunks of memory as
> PRIVATE should be a non-issue.  And if that's not enough for whatever reason, 
> I
> would rather define the polarity of PRIVATE on a per-VM basis, but only for 
> internal
> storage.

Sounds good.

> > I'm not sure if this is the best way to do this: One idea would be to move
> > the definition of KVM_MEMORY_ATTRIBUTE_PRIVATE to
> > arch/*/include/asm/kvm_host.h, which is where 
> > kvm_arch_supported_attributes()
> > lives as well. This would allow different architectures to specify their own
> > attributes (i.e., instead we'd have a KVM_MEMORY_ATTRIBUTE_SHARED for pKVM).
> > This wouldn't help in terms of preventing userspace from clearing attributes
> > (i.e., setting a 0 attribute) though.
> >
> > 

Re: [PATCH v2] syscalls: Cleanup references to sys_lookup_dcookie()

2023-10-03 Thread Sohil Mehta
On 10/3/2023 10:53 AM, Arnd Bergmann wrote:
> Thanks a lot for the reminder, I've added it to my asm-generic
> branch for v6.7 now, it should be in linux-next tomorrow.
> 

No problem at all. Thanks for picking up the patch!

Sohil


Re: [PATCH v2] syscalls: Cleanup references to sys_lookup_dcookie()

2023-10-03 Thread Arnd Bergmann
On Tue, Oct 3, 2023, at 19:47, Sohil Mehta wrote:
> Arnd, is this a good candidate for 6.7? Though old, the patch applies
> cleanly on 6.6-rc4. I can re-send this one if you would prefer that.
>

Thanks a lot for the reminder, I've added it to my asm-generic
branch for v6.7 now, it should be in linux-next tomorrow.

 Arnd


Re: [PATCH v2] syscalls: Cleanup references to sys_lookup_dcookie()

2023-10-03 Thread Sohil Mehta
Arnd, is this a good candidate for 6.7? Though old, the patch applies
cleanly on 6.6-rc4. I can re-send this one if you would prefer that.

On 8/3/2023 2:44 PM, Sohil Mehta wrote:
> On 7/10/2023 11:51 AM, Sohil Mehta wrote:
>> commit 'be65de6b03aa ("fs: Remove dcookies support")' removed the
>> syscall definition for lookup_dcookie.  However, syscall tables still
>> point to the old sys_lookup_dcookie() definition. Update syscall tables
>> of all architectures to directly point to sys_ni_syscall() instead.
>>
>> Signed-off-by: Sohil Mehta 
>> Reviewed-by: Randy Dunlap 
>> Acked-by: Namhyung Kim  # for perf
> 
> The patch has received a couple of additional Acks.
> 

Namely,

Acked-by: Geert Uytterhoeven 
Acked-by: Russell King (Oracle) 

> Does this seem like a valuable cleanup? If so, should it go through the
> asm-generic tree?
> 

The main motivation here is to make readers aware upfront (via the
syscall table itself) that no implementation exists for lookup_dcookie
instead of them searching for one and realizing the same. The syscall
tables do something similar for _sysctl().

Please let me know if this change seems unnecessary. I can drop the
annoying pings in that case.

Thanks,
Sohil



Re: [PATCH v2] arch: Reserve map_shadow_stack() syscall number for all architectures

2023-10-03 Thread Geert Uytterhoeven
On Thu, Sep 14, 2023 at 8:59 PM Sohil Mehta  wrote:
> commit c35559f94ebc ("x86/shstk: Introduce map_shadow_stack syscall")
> recently added support for map_shadow_stack() but it is limited to x86
> only for now. There is a possibility that other architectures (namely,
> arm64 and RISC-V), that are implementing equivalent support for shadow
> stacks, might need to add support for it.
>
> Independent of that, reserving arch-specific syscall numbers in the
> syscall tables of all architectures is good practice and would help
> avoid future conflicts. map_shadow_stack() is marked as a conditional
> syscall in sys_ni.c. Adding it to the syscall tables of other
> architectures is harmless and would return ENOSYS when exercised.
>
> Note, map_shadow_stack() was assigned #453 during the merge process
> since #452 was taken by fchmodat2().
>
> For Powerpc, map it to sys_ni_syscall() as is the norm for Powerpc
> syscall tables.
>
> For Alpha, map_shadow_stack() takes up #563 as Alpha still diverges from
> the common syscall numbering system in the other architectures.
>
> Link: 
> https://lore.kernel.org/lkml/20230515212255.ga562...@debug.ba.rivosinc.com/
> Link: 
> https://lore.kernel.org/lkml/b402b80b-a7c6-4ef0-b977-c0f5f582b...@sirena.org.uk/
>
> Signed-off-by: Sohil Mehta 

>  arch/m68k/kernel/syscalls/syscall.tbl   | 1 +

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v2] arch: Reserve map_shadow_stack() syscall number for all architectures

2023-10-03 Thread Sohil Mehta
On 10/3/2023 9:54 AM, Arnd Bergmann wrote:
> On Tue, Oct 3, 2023, at 18:35, Sohil Mehta wrote:
>>
>> Gentle ping...
>>
>> Are there any additional comments? It applies cleanly on 6.6-rc4.
>>
>> Or does it seem ready to be merged? It has the following
>> acknowledgements until now:
>>
>> Reviewed-by: Rick Edgecombe 
>> Acked-by: Michael Ellerman  (powerpc)
>>
> 
> Reviewed-by: Arnd Bergmann 
> 

Thanks Arnd.

> If you like, I can pick this up for 6.7 through the asm-generic
> tree. If you think this should be part of 6.6, I would suggest
> to merge it through the tree that originally contained the
> syscall code.
> 

Dave, Ingo, would you prefer to take this patch through 6.6 or defer it
until 6.7?

It's not necessarily a fix but it does help finish up the shstk syscall
added with 6.6. Also, it might help reduce some merge conflicts later if
newer syscalls are being added during the 6.7 window.

Sohil



Re: [PATCH v2] arch: Reserve map_shadow_stack() syscall number for all architectures

2023-10-03 Thread Arnd Bergmann
On Tue, Oct 3, 2023, at 18:35, Sohil Mehta wrote:
> On 9/14/2023 11:58 AM, Sohil Mehta wrote:
>> commit c35559f94ebc ("x86/shstk: Introduce map_shadow_stack syscall")
>> recently added support for map_shadow_stack() but it is limited to x86
>> only for now. There is a possibility that other architectures (namely,
>> arm64 and RISC-V), that are implementing equivalent support for shadow
>> stacks, might need to add support for it.
>> 
>> Independent of that, reserving arch-specific syscall numbers in the
>> syscall tables of all architectures is good practice and would help
>> avoid future conflicts. map_shadow_stack() is marked as a conditional
>> syscall in sys_ni.c. Adding it to the syscall tables of other
>> architectures is harmless and would return ENOSYS when exercised.
>> 
>> Note, map_shadow_stack() was assigned #453 during the merge process
>> since #452 was taken by fchmodat2().
>> 
>> For Powerpc, map it to sys_ni_syscall() as is the norm for Powerpc
>> syscall tables.
>> 
>> For Alpha, map_shadow_stack() takes up #563 as Alpha still diverges from
>> the common syscall numbering system in the other architectures.
>> 
>> Link: 
>> https://lore.kernel.org/lkml/20230515212255.ga562...@debug.ba.rivosinc.com/
>> Link: 
>> https://lore.kernel.org/lkml/b402b80b-a7c6-4ef0-b977-c0f5f582b...@sirena.org.uk/
>> 
>> Signed-off-by: Sohil Mehta 
>> ---
>
> Gentle ping...
>
> Are there any additional comments? It applies cleanly on 6.6-rc4.
>
> Or does it seem ready to be merged? It has the following
> acknowledgements until now:
>
> Reviewed-by: Rick Edgecombe 
> Acked-by: Michael Ellerman  (powerpc)
>

Reviewed-by: Arnd Bergmann 

If you like, I can pick this up for 6.7 through the asm-generic
tree. If you think this should be part of 6.6, I would suggest
to merge it through the tree that originally contained the
syscall code.

  Arnd


Re: [PATCH v2] arch: Reserve map_shadow_stack() syscall number for all architectures

2023-10-03 Thread Sohil Mehta
On 9/14/2023 11:58 AM, Sohil Mehta wrote:
> commit c35559f94ebc ("x86/shstk: Introduce map_shadow_stack syscall")
> recently added support for map_shadow_stack() but it is limited to x86
> only for now. There is a possibility that other architectures (namely,
> arm64 and RISC-V), that are implementing equivalent support for shadow
> stacks, might need to add support for it.
> 
> Independent of that, reserving arch-specific syscall numbers in the
> syscall tables of all architectures is good practice and would help
> avoid future conflicts. map_shadow_stack() is marked as a conditional
> syscall in sys_ni.c. Adding it to the syscall tables of other
> architectures is harmless and would return ENOSYS when exercised.
> 
> Note, map_shadow_stack() was assigned #453 during the merge process
> since #452 was taken by fchmodat2().
> 
> For Powerpc, map it to sys_ni_syscall() as is the norm for Powerpc
> syscall tables.
> 
> For Alpha, map_shadow_stack() takes up #563 as Alpha still diverges from
> the common syscall numbering system in the other architectures.
> 
> Link: 
> https://lore.kernel.org/lkml/20230515212255.ga562...@debug.ba.rivosinc.com/
> Link: 
> https://lore.kernel.org/lkml/b402b80b-a7c6-4ef0-b977-c0f5f582b...@sirena.org.uk/
> 
> Signed-off-by: Sohil Mehta 
> ---

Gentle ping...

Are there any additional comments? It applies cleanly on 6.6-rc4.

Or does it seem ready to be merged? It has the following
acknowledgements until now:

Reviewed-by: Rick Edgecombe 
Acked-by: Michael Ellerman  (powerpc)

>  arch/alpha/kernel/syscalls/syscall.tbl  | 1 +
>  arch/arm/tools/syscall.tbl  | 1 +
>  arch/arm64/include/asm/unistd.h | 2 +-
>  arch/arm64/include/asm/unistd32.h   | 2 ++
>  arch/ia64/kernel/syscalls/syscall.tbl   | 1 +
>  arch/m68k/kernel/syscalls/syscall.tbl   | 1 +
>  arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
>  arch/mips/kernel/syscalls/syscall_n32.tbl   | 1 +
>  arch/mips/kernel/syscalls/syscall_n64.tbl   | 1 +
>  arch/mips/kernel/syscalls/syscall_o32.tbl   | 1 +
>  arch/parisc/kernel/syscalls/syscall.tbl | 1 +
>  arch/powerpc/kernel/syscalls/syscall.tbl| 1 +
>  arch/s390/kernel/syscalls/syscall.tbl   | 1 +
>  arch/sh/kernel/syscalls/syscall.tbl | 1 +
>  arch/sparc/kernel/syscalls/syscall.tbl  | 1 +
>  arch/x86/entry/syscalls/syscall_32.tbl  | 1 +
>  arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
>  include/uapi/asm-generic/unistd.h   | 5 -
>  18 files changed, 22 insertions(+), 2 deletions(-)
>> diff --git a/arch/alpha/kernel/syscalls/syscall.tbl
b/arch/alpha/kernel/syscalls/syscall.tbl
> index ad37569d0507..6e8479c96e65 100644
> --- a/arch/alpha/kernel/syscalls/syscall.tbl
> +++ b/arch/alpha/kernel/syscalls/syscall.tbl
> @@ -492,3 +492,4 @@
>  560  common  set_mempolicy_home_node sys_ni_syscall
>  561  common  cachestat   sys_cachestat
>  562  common  fchmodat2   sys_fchmodat2
> +563  common  map_shadow_stacksys_map_shadow_stack
> diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
> index c572d6c3dee0..6d494dfbf5e4 100644
> --- a/arch/arm/tools/syscall.tbl
> +++ b/arch/arm/tools/syscall.tbl
> @@ -466,3 +466,4 @@
>  450  common  set_mempolicy_home_node sys_set_mempolicy_home_node
>  451  common  cachestat   sys_cachestat
>  452  common  fchmodat2   sys_fchmodat2
> +453  common  map_shadow_stacksys_map_shadow_stack
> diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
> index bd77253b62e0..6a28fb91b85d 100644
> --- a/arch/arm64/include/asm/unistd.h
> +++ b/arch/arm64/include/asm/unistd.h
> @@ -39,7 +39,7 @@
>  #define __ARM_NR_compat_set_tls  (__ARM_NR_COMPAT_BASE + 5)
>  #define __ARM_NR_COMPAT_END  (__ARM_NR_COMPAT_BASE + 0x800)
>  
> -#define __NR_compat_syscalls 453
> +#define __NR_compat_syscalls 454
>  #endif
>  
>  #define __ARCH_WANT_SYS_CLONE
> diff --git a/arch/arm64/include/asm/unistd32.h 
> b/arch/arm64/include/asm/unistd32.h
> index 78b68311ec81..a201d842ec82 100644
> --- a/arch/arm64/include/asm/unistd32.h
> +++ b/arch/arm64/include/asm/unistd32.h
> @@ -911,6 +911,8 @@ __SYSCALL(__NR_set_mempolicy_home_node, 
> sys_set_mempolicy_home_node)
>  __SYSCALL(__NR_cachestat, sys_cachestat)
>  #define __NR_fchmodat2 452
>  __SYSCALL(__NR_fchmodat2, sys_fchmodat2)
> +#define __NR_map_shadow_stack 453
> +__SYSCALL(__NR_map_shadow_stack, sys_map_shadow_stack)
>  
>  /*
>   * Please add new compat syscalls above this comment and update
> diff --git a/arch/ia64/kernel/syscalls/syscall.tbl 
> b/arch/ia64/kernel/syscalls/syscall.tbl
> index 83d8609aec03..be02ce9d376f 100644
> --- a/arch/ia64/kernel/syscalls/syscall.tbl
> +++ b/arch/ia64/kernel/syscalls/syscall.tbl
> @@ -373,3 +373,4 @@
>  450  common  set_mempolicy_home_node sys_set_mempolicy_home_node
>  451  common  cachestat 

Re: [net-next PATCH 3/4] netdev: replace napi_reschedule with napi_schedule

2023-10-03 Thread Marc Kleine-Budde
On 03.10.2023 13:18:33, Christian Marangi wrote:
> On Tue, Oct 03, 2023 at 09:16:33AM +0200, Marc Kleine-Budde wrote:
> > On 02.10.2023 17:10:22, Christian Marangi wrote:
> > > Now that napi_schedule return a bool, we can drop napi_reschedule that
> > > does the same exact function. The function comes from a very old commit
> > > bfe13f54f502 ("ibm_emac: Convert to use napi_struct independent of struct
> > > net_device") and the purpose is actually deprecated in favour of
> > > different logic.
> > > 
> > > Convert every user of napi_reschedule to napi_schedule.
> > > 
> > > Signed-off-by: Christian Marangi 
> > > ---
> > >  drivers/infiniband/ulp/ipoib/ipoib_ib.c|  4 ++--
> > >  drivers/net/can/dev/rx-offload.c   |  2 +-
> > 
> > Acked-by: Marc Kleine-Budde # for can/dev/rx-offload.c
> 
> Just to make sure can I use the correct tag: (you didn't include the
> mail)

Doh! Sure.

> Acked-by: Marc Kleine-Budde  # for can/dev/rx-offload.c

Acked-by: Marc Kleine-Budde  # for can/dev/rx-offload.c

Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde  |
Embedded Linux   | https://www.pengutronix.de |
Vertretung Nürnberg  | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |


signature.asc
Description: PGP signature


Re: [net-next PATCH 3/4] netdev: replace napi_reschedule with napi_schedule

2023-10-03 Thread Christian Marangi
On Tue, Oct 03, 2023 at 09:16:33AM +0200, Marc Kleine-Budde wrote:
> On 02.10.2023 17:10:22, Christian Marangi wrote:
> > Now that napi_schedule return a bool, we can drop napi_reschedule that
> > does the same exact function. The function comes from a very old commit
> > bfe13f54f502 ("ibm_emac: Convert to use napi_struct independent of struct
> > net_device") and the purpose is actually deprecated in favour of
> > different logic.
> > 
> > Convert every user of napi_reschedule to napi_schedule.
> > 
> > Signed-off-by: Christian Marangi 
> > ---
> >  drivers/infiniband/ulp/ipoib/ipoib_ib.c|  4 ++--
> >  drivers/net/can/dev/rx-offload.c   |  2 +-
> 
> Acked-by: Marc Kleine-Budde # for can/dev/rx-offload.c

Just to make sure can I use the correct tag: (you didn't include the
mail)

Acked-by: Marc Kleine-Budde  # for can/dev/rx-offload.c

?

-- 
Ansuel


Re: [net-next PATCH 2/4] netdev: make napi_schedule return bool on NAPI successful schedule

2023-10-03 Thread Christian Marangi
On Tue, Oct 03, 2023 at 07:21:46AM +0200, Eric Dumazet wrote:
> On Mon, Oct 2, 2023 at 5:10 PM Christian Marangi  wrote:
> >
> > Change napi_schedule to return a bool on NAPI successful schedule. This
> > might be useful for some driver to do additional step after a NAPI ahs
> 
> This might be useful for some drivers to do additional steps after a
> NAPI has been scheduled.
> 
> > been scheduled.
> >
> > Signed-off-by: Christian Marangi 
> 
> Yeah, I guess you forgot to mention I suggested this patch ...
> 
> Reviewed-by: Eric Dumazet 

Yes sorry, totally forgot to add this here. I already have the patch for the
other driver (but it's dependant on this so I'm waiting) and I forgot to
add the tag also for this piece.

-- 
Ansuel


Re: [net-next PATCH 3/4] netdev: replace napi_reschedule with napi_schedule

2023-10-03 Thread Marc Kleine-Budde
On 02.10.2023 17:10:22, Christian Marangi wrote:
> Now that napi_schedule return a bool, we can drop napi_reschedule that
> does the same exact function. The function comes from a very old commit
> bfe13f54f502 ("ibm_emac: Convert to use napi_struct independent of struct
> net_device") and the purpose is actually deprecated in favour of
> different logic.
> 
> Convert every user of napi_reschedule to napi_schedule.
> 
> Signed-off-by: Christian Marangi 
> ---
>  drivers/infiniband/ulp/ipoib/ipoib_ib.c|  4 ++--
>  drivers/net/can/dev/rx-offload.c   |  2 +-

Acked-by: Marc Kleine-Budde # for can/dev/rx-offload.c

regards,
Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde  |
Embedded Linux   | https://www.pengutronix.de |
Vertretung Nürnberg  | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |


signature.asc
Description: PGP signature


[PATCH RESEND 3/5] ASoC: da7218: Use i2c_get_match_data()

2023-10-03 Thread Rob Herring
Use preferred i2c_get_match_data() instead of of_match_device() and
i2c_match_id() to get the driver match data. With this, adjust the
includes to explicitly include the correct headers.

Avoid using 0 for enum da7218_dev_id so that no match data can be
distinguished.

Signed-off-by: Rob Herring 
---
 sound/soc/codecs/da7218.c | 29 ++---
 sound/soc/codecs/da7218.h |  2 +-
 2 files changed, 3 insertions(+), 28 deletions(-)

diff --git a/sound/soc/codecs/da7218.c b/sound/soc/codecs/da7218.c
index 3f456b08b809..8aacd7350798 100644
--- a/sound/soc/codecs/da7218.c
+++ b/sound/soc/codecs/da7218.c
@@ -9,7 +9,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -2285,16 +2285,6 @@ static const struct of_device_id da7218_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, da7218_of_match);
 
-static inline int da7218_of_get_id(struct device *dev)
-{
-   const struct of_device_id *id = of_match_device(da7218_of_match, dev);
-
-   if (id)
-   return (uintptr_t)id->data;
-   else
-   return -EINVAL;
-}
-
 static enum da7218_micbias_voltage
da7218_of_micbias_lvl(struct snd_soc_component *component, u32 val)
 {
@@ -3253,18 +3243,6 @@ static const struct regmap_config da7218_regmap_config = 
{
  * I2C layer
  */
 
-static const struct i2c_device_id da7218_i2c_id[];
-
-static inline int da7218_i2c_get_id(struct i2c_client *i2c)
-{
-   const struct i2c_device_id *id = i2c_match_id(da7218_i2c_id, i2c);
-
-   if (id)
-   return (uintptr_t)id->driver_data;
-   else
-   return -EINVAL;
-}
-
 static int da7218_i2c_probe(struct i2c_client *i2c)
 {
struct da7218_priv *da7218;
@@ -3276,10 +3254,7 @@ static int da7218_i2c_probe(struct i2c_client *i2c)
 
i2c_set_clientdata(i2c, da7218);
 
-   if (i2c->dev.of_node)
-   da7218->dev_id = da7218_of_get_id(>dev);
-   else
-   da7218->dev_id = da7218_i2c_get_id(i2c);
+   da7218->dev_id = (uintptr_t)i2c_get_match_data(i2c);
 
if ((da7218->dev_id != DA7217_DEV_ID) &&
(da7218->dev_id != DA7218_DEV_ID)) {
diff --git a/sound/soc/codecs/da7218.h b/sound/soc/codecs/da7218.h
index 9ac2892092b5..7f6a4aea2c7a 100644
--- a/sound/soc/codecs/da7218.h
+++ b/sound/soc/codecs/da7218.h
@@ -1369,7 +1369,7 @@ enum da7218_sys_clk {
 };
 
 enum da7218_dev_id {
-   DA7217_DEV_ID = 0,
+   DA7217_DEV_ID = 1,
DA7218_DEV_ID,
 };
 

-- 
2.40.1



[PATCH RESEND 5/5] ASoC: Use device_get_match_data()

2023-10-03 Thread Rob Herring
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.

Signed-off-by: Rob Herring 
---
 sound/soc/intel/keembay/kmb_platform.c | 13 +
 sound/soc/qcom/lpass-cpu.c | 15 +--
 sound/soc/rockchip/rockchip_i2s.c  |  8 +++-
 sound/soc/rockchip/rockchip_i2s_tdm.c  | 20 +++-
 sound/soc/rockchip/rockchip_pdm.c  |  6 +-
 sound/soc/samsung/smdk_wm8994.c| 27 +++
 sound/soc/stm/stm32_i2s.c  |  7 ++-
 sound/soc/stm/stm32_sai.c  |  8 
 sound/soc/stm/stm32_sai_sub.c  |  6 +-
 sound/soc/stm/stm32_spdifrx.c  |  8 ++--
 sound/soc/tegra/tegra210_amx.c |  7 +--
 sound/soc/ti/davinci-evm.c |  7 ++-
 sound/soc/ti/davinci-mcasp.c   |  9 -
 sound/soc/ti/omap-mcbsp.c  | 10 --
 14 files changed, 40 insertions(+), 111 deletions(-)

diff --git a/sound/soc/intel/keembay/kmb_platform.c 
b/sound/soc/intel/keembay/kmb_platform.c
index e929497a5eb5..37ea2e1d2e92 100644
--- a/sound/soc/intel/keembay/kmb_platform.c
+++ b/sound/soc/intel/keembay/kmb_platform.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -820,7 +819,6 @@ static int kmb_plat_dai_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
struct snd_soc_dai_driver *kmb_i2s_dai;
-   const struct of_device_id *match;
struct device *dev = >dev;
struct kmb_i2s_info *kmb_i2s;
struct resource *res;
@@ -831,16 +829,7 @@ static int kmb_plat_dai_probe(struct platform_device *pdev)
if (!kmb_i2s)
return -ENOMEM;
 
-   kmb_i2s_dai = devm_kzalloc(dev, sizeof(*kmb_i2s_dai), GFP_KERNEL);
-   if (!kmb_i2s_dai)
-   return -ENOMEM;
-
-   match = of_match_device(kmb_plat_of_match, >dev);
-   if (!match) {
-   dev_err(>dev, "Error: No device match found\n");
-   return -ENODEV;
-   }
-   kmb_i2s_dai = (struct snd_soc_dai_driver *) match->data;
+   kmb_i2s_dai = (struct snd_soc_dai_driver 
*)device_get_match_data(>dev);
 
/* Prepare the related clocks */
kmb_i2s->clk_apb = devm_clk_get(dev, "apb_clk");
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 18aff2654f89..ac0feb89b458 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -1106,7 +1105,6 @@ int asoc_qcom_lpass_cpu_platform_probe(struct 
platform_device *pdev)
struct resource *res;
const struct lpass_variant *variant;
struct device *dev = >dev;
-   const struct of_device_id *match;
int ret, i, dai_id;
 
dsp_of_node = of_parse_phandle(pdev->dev.of_node, "qcom,adsp", 0);
@@ -1121,17 +1119,14 @@ int asoc_qcom_lpass_cpu_platform_probe(struct 
platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, drvdata);
 
-   match = of_match_device(dev->driver->of_match_table, dev);
-   if (!match || !match->data)
+   variant = device_get_match_data(dev);
+   if (!variant)
return -EINVAL;
 
-   if (of_device_is_compatible(dev->of_node, "qcom,lpass-cpu-apq8016")) {
-   dev_warn(dev, "%s compatible is deprecated\n",
-match->compatible);
-   }
+   if (of_device_is_compatible(dev->of_node, "qcom,lpass-cpu-apq8016"))
+   dev_warn(dev, "qcom,lpass-cpu-apq8016 compatible is 
deprecated\n");
 
-   drvdata->variant = (struct lpass_variant *)match->data;
-   variant = drvdata->variant;
+   drvdata->variant = variant;
 
of_lpass_cpu_parse_dai_data(dev, drvdata);
 
diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index 74e7d6ee0f28..b0c3ef030e06 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -10,8 +10,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -736,7 +736,6 @@ static int rockchip_i2s_init_dai(struct rk_i2s_dev *i2s, 
struct resource *res,
 static int rockchip_i2s_probe(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
-   const struct of_device_id *of_id;
struct rk_i2s_dev *i2s;
struct snd_soc_dai_driver *dai;
struct resource *res;
@@ -752,11 +751,10 @@ static int rockchip_i2s_probe(struct platform_device 
*pdev)
 
i2s->grf = syscon_regmap_lookup_by_phandle(node, "rockchip,grf");
if (!IS_ERR(i2s->grf)) {
-   of_id = of_match_device(rockchip_i2s_match, >dev);
-   if (!of_id || !of_id->data)
+   i2s->pins = device_get_match_data(>dev);
+  

[PATCH RESEND 2/5] ASoC: Drop unnecessary of_match_device() calls

2023-10-03 Thread Rob Herring
If probe is reached, we've already matched the device and in the case of
DT matching, the struct device_node pointer will be set. Therefore, there
is no need to call of_match_device() in probe.

Signed-off-by: Rob Herring 
---
 sound/soc/codecs/ak5386.c  |  7 ++-
 sound/soc/codecs/cs4271.c  | 22 ++
 sound/soc/codecs/tas5086.c |  6 +-
 3 files changed, 9 insertions(+), 26 deletions(-)

diff --git a/sound/soc/codecs/ak5386.c b/sound/soc/codecs/ak5386.c
index 0c5e00679c7d..21a44476f48d 100644
--- a/sound/soc/codecs/ak5386.c
+++ b/sound/soc/codecs/ak5386.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -168,7 +167,6 @@ static int ak5386_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
-   priv->reset_gpio = -EINVAL;
dev_set_drvdata(dev, priv);
 
for (i = 0; i < ARRAY_SIZE(supply_names); i++)
@@ -179,9 +177,8 @@ static int ak5386_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
 
-   if (of_match_device(of_match_ptr(ak5386_dt_ids), dev))
-   priv->reset_gpio = of_get_named_gpio(dev->of_node,
- "reset-gpio", 0);
+   priv->reset_gpio = of_get_named_gpio(dev->of_node,
+"reset-gpio", 0);
 
if (gpio_is_valid(priv->reset_gpio))
if (devm_gpio_request_one(dev, priv->reset_gpio,
diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c
index 188b8b43c524..9e6f8a048dd5 100644
--- a/sound/soc/codecs/cs4271.c
+++ b/sound/soc/codecs/cs4271.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -563,19 +562,12 @@ static int cs4271_component_probe(struct 
snd_soc_component *component)
struct cs4271_private *cs4271 = 
snd_soc_component_get_drvdata(component);
struct cs4271_platform_data *cs4271plat = component->dev->platform_data;
int ret;
-   bool amutec_eq_bmutec = false;
+   bool amutec_eq_bmutec;
 
-#ifdef CONFIG_OF
-   if (of_match_device(cs4271_dt_ids, component->dev)) {
-   if (of_get_property(component->dev->of_node,
-"cirrus,amutec-eq-bmutec", NULL))
-   amutec_eq_bmutec = true;
-
-   if (of_get_property(component->dev->of_node,
-"cirrus,enable-soft-reset", NULL))
-   cs4271->enable_soft_reset = true;
-   }
-#endif
+   amutec_eq_bmutec = of_property_read_bool(component->dev->of_node,
+"cirrus,amutec-eq-bmutec");
+   cs4271->enable_soft_reset = 
of_property_read_bool(component->dev->of_node,
+ 
"cirrus,enable-soft-reset");
 
ret = regulator_bulk_enable(ARRAY_SIZE(cs4271->supplies),
cs4271->supplies);
@@ -655,9 +647,7 @@ static int cs4271_common_probe(struct device *dev,
if (!cs4271)
return -ENOMEM;
 
-   if (of_match_device(cs4271_dt_ids, dev))
-   cs4271->gpio_nreset =
-   of_get_named_gpio(dev->of_node, "reset-gpio", 0);
+   cs4271->gpio_nreset = of_get_named_gpio(dev->of_node, "reset-gpio", 0);
 
if (cs4271plat)
cs4271->gpio_nreset = cs4271plat->gpio_nreset;
diff --git a/sound/soc/codecs/tas5086.c b/sound/soc/codecs/tas5086.c
index 60e59e993ba6..f52c14b43f28 100644
--- a/sound/soc/codecs/tas5086.c
+++ b/sound/soc/codecs/tas5086.c
@@ -940,11 +940,7 @@ static int tas5086_i2c_probe(struct i2c_client *i2c)
 
i2c_set_clientdata(i2c, priv);
 
-   if (of_match_device(of_match_ptr(tas5086_dt_ids), dev)) {
-   struct device_node *of_node = dev->of_node;
-   gpio_nreset = of_get_named_gpio(of_node, "reset-gpio", 0);
-   }
-
+   gpio_nreset = of_get_named_gpio(dev->of_node, "reset-gpio", 0);
if (gpio_is_valid(gpio_nreset))
if (devm_gpio_request(dev, gpio_nreset, "TAS5086 Reset"))
gpio_nreset = -EINVAL;

-- 
2.40.1



[PATCH RESEND 4/5] ASoC: qcom/lpass: Constify struct lpass_variant

2023-10-03 Thread Rob Herring
'struct lpass_variant' is used for driver match data which is supposed to
be constant. It's not modified anywhere, so it's just a matter of adding
'const' everywhere.

Signed-off-by: Rob Herring 
---
 sound/soc/qcom/lpass-apq8016.c  |  6 +++---
 sound/soc/qcom/lpass-cdc-dma.c  |  2 +-
 sound/soc/qcom/lpass-cpu.c  | 28 ++--
 sound/soc/qcom/lpass-ipq806x.c  |  2 +-
 sound/soc/qcom/lpass-platform.c | 36 ++--
 sound/soc/qcom/lpass-sc7180.c   |  6 +++---
 sound/soc/qcom/lpass-sc7280.c   |  6 +++---
 sound/soc/qcom/lpass.h  |  2 +-
 8 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c
index f919d46e18ca..8ce75b442b64 100644
--- a/sound/soc/qcom/lpass-apq8016.c
+++ b/sound/soc/qcom/lpass-apq8016.c
@@ -123,7 +123,7 @@ static struct snd_soc_dai_driver 
apq8016_lpass_cpu_dai_driver[] = {
 static int apq8016_lpass_alloc_dma_channel(struct lpass_data *drvdata,
   int direction, unsigned int dai_id)
 {
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
int chan = 0;
 
if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
@@ -157,7 +157,7 @@ static int apq8016_lpass_free_dma_channel(struct lpass_data 
*drvdata, int chan,
 static int apq8016_lpass_init(struct platform_device *pdev)
 {
struct lpass_data *drvdata = platform_get_drvdata(pdev);
-   struct lpass_variant *variant = drvdata->variant;
+   const struct lpass_variant *variant = drvdata->variant;
struct device *dev = >dev;
int ret, i;
 
@@ -223,7 +223,7 @@ static int apq8016_lpass_exit(struct platform_device *pdev)
 }
 
 
-static struct lpass_variant apq8016_data = {
+static const struct lpass_variant apq8016_data = {
.i2sctrl_reg_base   = 0x1000,
.i2sctrl_reg_stride = 0x1000,
.i2s_ports  = 4,
diff --git a/sound/soc/qcom/lpass-cdc-dma.c b/sound/soc/qcom/lpass-cdc-dma.c
index 8221e2cbe35c..6389c7b6051e 100644
--- a/sound/soc/qcom/lpass-cdc-dma.c
+++ b/sound/soc/qcom/lpass-cdc-dma.c
@@ -37,7 +37,7 @@ static void __lpass_get_dmactl_handle(struct 
snd_pcm_substream *substream, struc
struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
struct snd_pcm_runtime *rt = substream->runtime;
struct lpass_pcm_data *pcm_data = rt->private_data;
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
unsigned int dai_id = cpu_dai->driver->id;
 
switch (dai_id) {
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 39571fed4001..18aff2654f89 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -44,7 +44,7 @@ static int lpass_cpu_init_i2sctl_bitfields(struct device *dev,
struct lpaif_i2sctl *i2sctl, struct regmap *map)
 {
struct lpass_data *drvdata = dev_get_drvdata(dev);
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
 
i2sctl->loopback = devm_regmap_field_alloc(dev, map, v->loopback);
i2sctl->spken = devm_regmap_field_alloc(dev, map, v->spken);
@@ -463,7 +463,7 @@ static int asoc_qcom_of_xlate_dai_name(struct 
snd_soc_component *component,
   const char **dai_name)
 {
struct lpass_data *drvdata = snd_soc_component_get_drvdata(component);
-   struct lpass_variant *variant = drvdata->variant;
+   const struct lpass_variant *variant = drvdata->variant;
int id = args->args[0];
int ret = -EINVAL;
int i;
@@ -488,7 +488,7 @@ static const struct snd_soc_component_driver 
lpass_cpu_comp_driver = {
 static bool lpass_cpu_regmap_writeable(struct device *dev, unsigned int reg)
 {
struct lpass_data *drvdata = dev_get_drvdata(dev);
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
int i;
 
for (i = 0; i < v->i2s_ports; ++i)
@@ -530,7 +530,7 @@ static bool lpass_cpu_regmap_writeable(struct device *dev, 
unsigned int reg)
 static bool lpass_cpu_regmap_readable(struct device *dev, unsigned int reg)
 {
struct lpass_data *drvdata = dev_get_drvdata(dev);
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
int i;
 
for (i = 0; i < v->i2s_ports; ++i)
@@ -578,7 +578,7 @@ static bool lpass_cpu_regmap_readable(struct device *dev, 
unsigned int reg)
 static bool lpass_cpu_regmap_volatile(struct device *dev, unsigned int reg)
 {
struct lpass_data *drvdata = dev_get_drvdata(dev);
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
int i;
 
for (i = 0; i < v->irq_ports; ++i) {
@@ -613,7 +613,7 @@ static struct regmap_config 

[PATCH RESEND 1/5] ASoC: Explicitly include correct DT includes

2023-10-03 Thread Rob Herring
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring 
---
 sound/soc/atmel/atmel_wm8904.c | 1 -
 sound/soc/atmel/mchp-i2s-mcc.c | 2 +-
 sound/soc/atmel/tse850-pcm5142.c   | 1 -
 sound/soc/bcm/cygnus-ssp.c | 2 +-
 sound/soc/codecs/adau1701.c| 1 -
 sound/soc/codecs/adau1977-spi.c| 1 -
 sound/soc/codecs/ak4104.c  | 2 +-
 sound/soc/codecs/ak4118.c  | 2 +-
 sound/soc/codecs/ak4375.c  | 2 +-
 sound/soc/codecs/ak4458.c  | 2 +-
 sound/soc/codecs/ak4613.c  | 2 +-
 sound/soc/codecs/ak4642.c  | 2 +-
 sound/soc/codecs/ak5558.c  | 2 +-
 sound/soc/codecs/cs35l32.c | 2 +-
 sound/soc/codecs/cs35l33.c | 2 --
 sound/soc/codecs/cs35l34.c | 2 +-
 sound/soc/codecs/cs35l35.c | 3 +--
 sound/soc/codecs/cs35l36.c | 3 +--
 sound/soc/codecs/cs35l41-i2c.c | 2 +-
 sound/soc/codecs/cs35l41.c | 1 -
 sound/soc/codecs/cs4270.c  | 2 +-
 sound/soc/codecs/cs42l42.c | 1 -
 sound/soc/codecs/cs42l56.c | 2 +-
 sound/soc/codecs/cs42xx8-i2c.c | 2 +-
 sound/soc/codecs/cs43130.c | 3 +--
 sound/soc/codecs/cs4349.c  | 2 +-
 sound/soc/codecs/da7213.c  | 2 +-
 sound/soc/codecs/da7219.c  | 2 +-
 sound/soc/codecs/da9055.c  | 1 -
 sound/soc/codecs/es8328.c  | 1 -
 sound/soc/codecs/gtm601.c  | 2 +-
 sound/soc/codecs/lpass-macro-common.c  | 2 +-
 sound/soc/codecs/mt6351.c  | 2 +-
 sound/soc/codecs/mt6358.c  | 2 +-
 sound/soc/codecs/mt6359-accdet.c   | 4 
 sound/soc/codecs/mt6359.c  | 2 +-
 sound/soc/codecs/nau8540.c | 2 +-
 sound/soc/codecs/pcm1681.c | 2 --
 sound/soc/codecs/rt715.c   | 2 --
 sound/soc/codecs/sgtl5000.c| 2 +-
 sound/soc/codecs/sma1303.c | 2 +-
 sound/soc/codecs/sta32x.c  | 3 +--
 sound/soc/codecs/sta350.c  | 3 +--
 sound/soc/codecs/tas571x.c | 2 +-
 sound/soc/codecs/uda1334.c | 2 +-
 sound/soc/codecs/wm8510.c  | 2 +-
 sound/soc/codecs/wm8523.c  | 2 +-
 sound/soc/codecs/wm8524.c  | 2 +-
 sound/soc/codecs/wm8580.c  | 2 +-
 sound/soc/codecs/wm8711.c  | 2 +-
 sound/soc/codecs/wm8728.c  | 2 +-
 sound/soc/codecs/wm8731-i2c.c  | 2 +-
 sound/soc/codecs/wm8731-spi.c  | 2 +-
 sound/soc/codecs/wm8737.c  | 2 +-
 sound/soc/codecs/wm8741.c  | 2 +-
 sound/soc/codecs/wm8750.c  | 2 +-
 sound/soc/codecs/wm8753.c  | 2 +-
 sound/soc/codecs/wm8770.c  | 2 +-
 sound/soc/codecs/wm8776.c  | 2 +-
 sound/soc/codecs/wm8804.c  | 1 -
 sound/soc/fsl/efika-audio-fabric.c | 4 ++--
 sound/soc/fsl/fsl_aud2htx.c| 3 +--
 sound/soc/fsl/fsl_mqs.c| 2 +-
 sound/soc/fsl/fsl_rpmsg.c  | 3 +--
 sound/soc/fsl/fsl_sai.c| 3 +--
 sound/soc/fsl/fsl_spdif.c  | 4 +---
 

[PATCH RESEND 0/5] ASoC: DT matching and header cleanups

2023-10-03 Thread Rob Herring
 +-
 sound/soc/tegra/tegra210_peq.c |  1 -
 sound/soc/tegra/tegra210_sfc.c |  1 -
 sound/soc/tegra/tegra30_i2s.c  |  1 -
 sound/soc/tegra/tegra_asoc_machine.c   |  1 -
 sound/soc/tegra/tegra_audio_graph_card.c   |  2 +-
 sound/soc/ti/davinci-evm.c |  7 +---
 sound/soc/ti/davinci-mcasp.c   |  9 ++---
 sound/soc/ti/omap-dmic.c   |  2 +-
 sound/soc/ti/omap-mcbsp.c  | 10 ++---
 sound/soc/ti/omap-mcpdm.c  |  2 +-
 162 files changed, 205 insertions(+), 390 deletions(-)
---
base-commit: c9f2baaa18b5ea8f006a2b3a616da9597c71d15e
change-id: 20231003-dt-asoc-header-cleanups-87f2cf5a2205

Best regards,
-- 
Rob Herring 



Re: [PATCHv7 4/4] powerpc/setup: alloc extra paca_ptrs to hold boot_cpuid

2023-10-03 Thread Mahesh J Salgaonkar
On 2023-09-25 15:53:48 Mon, Pingfan Liu wrote:
> paca_ptrs should be large enough to hold the boot_cpuid, hence, its
> lower boundary is set to the bigger one between boot_cpuid+1 and
> nr_cpus.
> 
> On the other hand, some kernel component: -1. the timer assumes cpu0
> online since the timer_list->flags subfield 'TIMER_CPUMASK' is zero if
> not initialized to a proper present cpu.  -2. power9_idle_stop() assumes
> the primary thread's paca is allocated.
> 
> Hence lift nr_cpu_ids from one to two to ensure cpu0 is onlined, if the
> boot cpu is not cpu0.
> 
> Result:
> When nr_cpus=1, taskset -c 14 bash -c 'echo c > /proc/sysrq-trigger'
> the kdump kernel brings up two cpus.
> While when taskset -c 4 bash -c 'echo c > /proc/sysrq-trigger',
> the kdump kernel brings up one cpu.

I tried your changes on power9 and power10 systems. However, on power10 lpar I
see bellow backtrace in kdump kernel bootup with nr_cpus=1.

$ taskset -c 4 bash -c 'echo c > /proc/sysrq-trigger'
[...]
[0.00] Hardware name: IBM,9105-22A POWER10 (raw) 0x800200 0xf06 
of:IBM,FW1040.00 (NL1040_005) hv:phyp pSeries
[0.00] printk: bootconsole [udbg0] enabled
[0.00] the round shift between dt seq and the cpu logic number: 8
[0.00] Partition configured for 16 cpus, operating system maximum is 2.
[0.00] CPU maps initialized for 8 threads per core
[...]
[0.002249] BUG: Unable to handle kernel data access at 0x88c0
[0.002260] Faulting instruction address: 0xc0001201226c
[0.002268] Oops: Kernel access of bad area, sig: 11 [#1]
[0.002274] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
[0.002282] Modules linked in:
[0.002288] CPU: 4 PID: 1 Comm: swapper/4 Not tainted 6.6.0-rc4 #1
[0.002296] Hardware name: IBM,9105-22A POWER10 (raw) 0x800200 0xf06 
of:IBM,FW1040.00 (NL1040_005) hv:phyp pSeries
[0.002305] NIP:  c0001201226c LR: c00012012234 CTR: 0004
[0.002312] REGS: c000167ff8f0 TRAP: 0380   Not tainted  (6.6.0-rc4)
[0.002321] MSR:  82009033   CR: 24000844  
XER: 000a
[0.002346] CFAR: c0001201231c IRQMASK: 0
[0.002346] GPR00: c00012012234 c000167ffb90 c00011b61900 
0002
[0.002346] GPR04:  0001 0001 
c0004ffeff80
[0.002346] GPR08:   0002 

[0.002346] GPR12:  c00013141000 c00010011058 

[0.002346] GPR16:    

[0.002346] GPR20: 0028 c00012170968 c000120a3e80 
0016
[0.002346] GPR24: c0004ffdcfd0  c00012b82058 

[0.002346] GPR28: c0004fc80a68 c00012bf0350 c000120a3e2c 

[0.002426] NIP [c0001201226c] update_mask_from_threadgroup+0x98/0x174
[0.002437] LR [c00012012234] update_mask_from_threadgroup+0x60/0x174
[0.002444] Call Trace:
[0.002451] [c000167ffb90] [c00012012234] 
update_mask_from_threadgroup+0x60/0x174 (unreliable)
[0.002464] [c000167ffbe0] [c000120125f8] 
init_thread_group_cache_map+0x2b0/0x328
[0.002477] [c000167ffc50] [c0001201296c] 
smp_prepare_cpus+0x2fc/0x4f0
[0.002497] [c000167ffd10] [c00012004e40] 
kernel_init_freeable+0x198/0x3cc
[0.002509] [c000167ffde0] [c00010011084] kernel_init+0x34/0x1b0
[0.002531] [c000167ffe50] [c0001000dd3c] 
ret_from_kernel_user_thread+0x14/0x1c
[0.002547] --- interrupt: 0 at 0x0
[0.002553] NIP:   LR:  CTR: 
[0.002563] REGS: c000167ffe80 TRAP:    Not tainted  (6.6.0-rc4)
[0.002569] MSR:   <>  CR:   XER: 
[0.002576] CFAR:  IRQMASK: 0
[0.002576] GPR00:    

[0.002576] GPR04:    

[0.002576] GPR08:    

[0.002576] GPR12:    

[0.002576] GPR16:    

[0.002576] GPR20:    

[0.002576] GPR24:    

[0.002576] GPR28:    

[0.002671] NIP [] 0x0
[0.002680] LR [] 0x0
[0.002689] --- interrupt: 0
[0.002697] Code: 7feafb78 813d 7d29fa14 7f895000 409d00d4 3ce20102 
38e74758 79491f24 e87e0006 3900 e8e7 7d27482a  7f834000 
79090020 419e005c
[0.002727] ---[ end trace  ]---
[0.002739]
[

Re: [PATCH 0/3] PCI: PCI_HEADER_TYPE bugfix & cleanups

2023-10-03 Thread Bjorn Helgaas
On Tue, Oct 03, 2023 at 03:52:57PM +0300, Ilpo Järvinen wrote:
> One bugfix and cleanups for PCI_HEADER_TYPE_* literals.
> 
> This series only covers what's within drivers/pci/. I'd have patches
> for other subsystems too but I decided to wait with them until
> PCI_HEADER_TYPE_MFD is in Linus' tree (to keep the series receipient
> count reasonable, the rest can IMO go through the subsystem specific
> trees once the define is there).
> 
> Ilpo Järvinen (3):
>   PCI: vmd: Correct PCI Header Type Register's MFD bit check
>   PCI: Add PCI_HEADER_TYPE_MFD pci_regs.h
>   PCI: Use PCI_HEADER_TYPE_* instead of literals
> 
>  drivers/pci/controller/dwc/pci-layerscape.c   |  2 +-
>  .../controller/mobiveil/pcie-mobiveil-host.c  |  2 +-
>  drivers/pci/controller/pcie-iproc.c   |  2 +-
>  drivers/pci/controller/pcie-rcar-ep.c |  2 +-
>  drivers/pci/controller/pcie-rcar-host.c   |  2 +-
>  drivers/pci/controller/vmd.c  |  5 ++---
>  drivers/pci/hotplug/cpqphp_ctrl.c |  6 ++---
>  drivers/pci/hotplug/cpqphp_pci.c  | 22 +--
>  drivers/pci/hotplug/ibmphp.h  |  5 +++--
>  drivers/pci/hotplug/ibmphp_pci.c  |  2 +-
>  drivers/pci/pci.c |  2 +-
>  drivers/pci/quirks.c  |  6 ++---
>  include/uapi/linux/pci_regs.h |  1 +
>  13 files changed, 30 insertions(+), 29 deletions(-)

Applied to pci/enumeration for v6.7, thanks!


Re: [PATCH v2] vfs: shave work on failed file open

2023-10-03 Thread Nathan Chancellor
Hi Christian,

> >From d266eee9d9d917f07774e2c2bab0115d2119a311 Mon Sep 17 00:00:00 2001
> From: Christian Brauner 
> Date: Fri, 29 Sep 2023 08:45:59 +0200
> Subject: [PATCH] file: convert to SLAB_TYPESAFE_BY_RCU
> 
> In recent discussions around some performance improvements in the file
> handling area we discussed switching the file cache to rely on
> SLAB_TYPESAFE_BY_RCU which allows us to get rid of call_rcu() based
> freeing for files completely. This is a pretty sensitive change overall
> but it might actually be worth doing.
> 
> The main downside is the subtlety. The other one is that we should
> really wait for Jann's patch to land that enables KASAN to handle
> SLAB_TYPESAFE_BY_RCU UAFs. Currently it doesn't but a patch for this
> exists.
> 
> With SLAB_TYPESAFE_BY_RCU objects may be freed and reused multiple times
> which requires a few changes. So it isn't sufficient anymore to just
> acquire a reference to the file in question under rcu using
> atomic_long_inc_not_zero() since the file might have already been
> recycled and someone else might have bumped the reference.
> 
> In other words, callers might see reference count bumps from newer
> users. For this is reason it is necessary to verify that the pointer is
> the same before and after the reference count increment. This pattern
> can be seen in get_file_rcu() and __files_get_rcu().
> 
> In addition, it isn't possible to access or check fields in struct file
> without first aqcuiring a reference on it. Not doing that was always
> very dodgy and it was only usable for non-pointer data in struct file.
> With SLAB_TYPESAFE_BY_RCU it is necessary that callers first acquire a
> reference under rcu or they must hold the files_lock of the fdtable.
> Failing to do either one of this is a bug.
> 
> Thanks to Jann for pointing out that we need to ensure memory ordering
> between reallocations and pointer check by ensuring that all subsequent
> loads have a dependency on the second load in get_file_rcu() and
> providing a fixup that was folded into this patch.
> 
> Cc: Jann Horn 
> Suggested-by: Linus Torvalds 
> Signed-off-by: Christian Brauner 
> ---



> --- a/arch/powerpc/platforms/cell/spufs/coredump.c
> +++ b/arch/powerpc/platforms/cell/spufs/coredump.c
> @@ -74,10 +74,13 @@ static struct spu_context *coredump_next_context(int *fd)
>   *fd = n - 1;
>  
>   rcu_read_lock();
> - file = lookup_fd_rcu(*fd);
> - ctx = SPUFS_I(file_inode(file))->i_ctx;
> - get_spu_context(ctx);
> + file = lookup_fdget_rcu(*fd);
>   rcu_read_unlock();
> + if (file) {
> + ctx = SPUFS_I(file_inode(file))->i_ctx;
> + get_spu_context(ctx);
> + fput(file);
> + }
>  
>   return ctx;
>  }

This hunk now causes a clang warning (or error, since arch/powerpc builds
with -Werror by default) in next-20231003.

  $ make -skj"$(nproc)" ARCH=powerpc LLVM=1 ppc64_guest_defconfig 
arch/powerpc/platforms/cell/spufs/coredump.o
  ...
  arch/powerpc/platforms/cell/spufs/coredump.c:79:6: error: variable 'ctx' is 
used uninitialized whenever 'if' condition is false 
[-Werror,-Wsometimes-uninitialized]
 79 | if (file) {
| ^~~~
  arch/powerpc/platforms/cell/spufs/coredump.c:85:9: note: uninitialized use 
occurs here
 85 | return ctx;
|^~~
  arch/powerpc/platforms/cell/spufs/coredump.c:79:2: note: remove the 'if' if 
its condition is always true
 79 | if (file) {
| ^
  arch/powerpc/platforms/cell/spufs/coredump.c:69:25: note: initialize the 
variable 'ctx' to silence this warning
 69 | struct spu_context *ctx;
|^
| = NULL
  1 error generated.

Cheers,
Nathan


[PATCH 1/5] ASoC: Explicitly include correct DT includes

2023-10-03 Thread Rob Herring
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring 
---
 sound/soc/atmel/atmel_wm8904.c | 1 -
 sound/soc/atmel/mchp-i2s-mcc.c | 2 +-
 sound/soc/atmel/tse850-pcm5142.c   | 1 -
 sound/soc/bcm/cygnus-ssp.c | 2 +-
 sound/soc/codecs/adau1701.c| 1 -
 sound/soc/codecs/adau1977-spi.c| 1 -
 sound/soc/codecs/ak4104.c  | 2 +-
 sound/soc/codecs/ak4118.c  | 2 +-
 sound/soc/codecs/ak4375.c  | 2 +-
 sound/soc/codecs/ak4458.c  | 2 +-
 sound/soc/codecs/ak4613.c  | 2 +-
 sound/soc/codecs/ak4642.c  | 2 +-
 sound/soc/codecs/ak5558.c  | 2 +-
 sound/soc/codecs/cs35l32.c | 2 +-
 sound/soc/codecs/cs35l33.c | 2 --
 sound/soc/codecs/cs35l34.c | 2 +-
 sound/soc/codecs/cs35l35.c | 3 +--
 sound/soc/codecs/cs35l36.c | 3 +--
 sound/soc/codecs/cs35l41-i2c.c | 2 +-
 sound/soc/codecs/cs35l41.c | 1 -
 sound/soc/codecs/cs4270.c  | 2 +-
 sound/soc/codecs/cs42l42.c | 1 -
 sound/soc/codecs/cs42l56.c | 2 +-
 sound/soc/codecs/cs42xx8-i2c.c | 2 +-
 sound/soc/codecs/cs43130.c | 3 +--
 sound/soc/codecs/cs4349.c  | 2 +-
 sound/soc/codecs/da7213.c  | 2 +-
 sound/soc/codecs/da7219.c  | 2 +-
 sound/soc/codecs/da9055.c  | 1 -
 sound/soc/codecs/es8328.c  | 1 -
 sound/soc/codecs/gtm601.c  | 2 +-
 sound/soc/codecs/lpass-macro-common.c  | 2 +-
 sound/soc/codecs/mt6351.c  | 2 +-
 sound/soc/codecs/mt6358.c  | 2 +-
 sound/soc/codecs/mt6359-accdet.c   | 4 
 sound/soc/codecs/mt6359.c  | 2 +-
 sound/soc/codecs/nau8540.c | 2 +-
 sound/soc/codecs/pcm1681.c | 2 --
 sound/soc/codecs/rt715.c   | 2 --
 sound/soc/codecs/sgtl5000.c| 2 +-
 sound/soc/codecs/sma1303.c | 2 +-
 sound/soc/codecs/sta32x.c  | 3 +--
 sound/soc/codecs/sta350.c  | 3 +--
 sound/soc/codecs/tas571x.c | 2 +-
 sound/soc/codecs/uda1334.c | 2 +-
 sound/soc/codecs/wm8510.c  | 2 +-
 sound/soc/codecs/wm8523.c  | 2 +-
 sound/soc/codecs/wm8524.c  | 2 +-
 sound/soc/codecs/wm8580.c  | 2 +-
 sound/soc/codecs/wm8711.c  | 2 +-
 sound/soc/codecs/wm8728.c  | 2 +-
 sound/soc/codecs/wm8731-i2c.c  | 2 +-
 sound/soc/codecs/wm8731-spi.c  | 2 +-
 sound/soc/codecs/wm8737.c  | 2 +-
 sound/soc/codecs/wm8741.c  | 2 +-
 sound/soc/codecs/wm8750.c  | 2 +-
 sound/soc/codecs/wm8753.c  | 2 +-
 sound/soc/codecs/wm8770.c  | 2 +-
 sound/soc/codecs/wm8776.c  | 2 +-
 sound/soc/codecs/wm8804.c  | 1 -
 sound/soc/fsl/efika-audio-fabric.c | 4 ++--
 sound/soc/fsl/fsl_aud2htx.c| 3 +--
 sound/soc/fsl/fsl_mqs.c| 2 +-
 sound/soc/fsl/fsl_rpmsg.c  | 3 +--
 sound/soc/fsl/fsl_sai.c| 3 +--
 sound/soc/fsl/fsl_spdif.c  | 4 +---
 

[PATCH 3/5] ASoC: da7218: Use i2c_get_match_data()

2023-10-03 Thread Rob Herring
Use preferred i2c_get_match_data() instead of of_match_device() and
i2c_match_id() to get the driver match data. With this, adjust the
includes to explicitly include the correct headers.

Avoid using 0 for enum da7218_dev_id so that no match data can be
distinguished.

Signed-off-by: Rob Herring 
---
 sound/soc/codecs/da7218.c | 29 ++---
 sound/soc/codecs/da7218.h |  2 +-
 2 files changed, 3 insertions(+), 28 deletions(-)

diff --git a/sound/soc/codecs/da7218.c b/sound/soc/codecs/da7218.c
index 3f456b08b809..8aacd7350798 100644
--- a/sound/soc/codecs/da7218.c
+++ b/sound/soc/codecs/da7218.c
@@ -9,7 +9,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -2285,16 +2285,6 @@ static const struct of_device_id da7218_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, da7218_of_match);
 
-static inline int da7218_of_get_id(struct device *dev)
-{
-   const struct of_device_id *id = of_match_device(da7218_of_match, dev);
-
-   if (id)
-   return (uintptr_t)id->data;
-   else
-   return -EINVAL;
-}
-
 static enum da7218_micbias_voltage
da7218_of_micbias_lvl(struct snd_soc_component *component, u32 val)
 {
@@ -3253,18 +3243,6 @@ static const struct regmap_config da7218_regmap_config = 
{
  * I2C layer
  */
 
-static const struct i2c_device_id da7218_i2c_id[];
-
-static inline int da7218_i2c_get_id(struct i2c_client *i2c)
-{
-   const struct i2c_device_id *id = i2c_match_id(da7218_i2c_id, i2c);
-
-   if (id)
-   return (uintptr_t)id->driver_data;
-   else
-   return -EINVAL;
-}
-
 static int da7218_i2c_probe(struct i2c_client *i2c)
 {
struct da7218_priv *da7218;
@@ -3276,10 +3254,7 @@ static int da7218_i2c_probe(struct i2c_client *i2c)
 
i2c_set_clientdata(i2c, da7218);
 
-   if (i2c->dev.of_node)
-   da7218->dev_id = da7218_of_get_id(>dev);
-   else
-   da7218->dev_id = da7218_i2c_get_id(i2c);
+   da7218->dev_id = (uintptr_t)i2c_get_match_data(i2c);
 
if ((da7218->dev_id != DA7217_DEV_ID) &&
(da7218->dev_id != DA7218_DEV_ID)) {
diff --git a/sound/soc/codecs/da7218.h b/sound/soc/codecs/da7218.h
index 9ac2892092b5..7f6a4aea2c7a 100644
--- a/sound/soc/codecs/da7218.h
+++ b/sound/soc/codecs/da7218.h
@@ -1369,7 +1369,7 @@ enum da7218_sys_clk {
 };
 
 enum da7218_dev_id {
-   DA7217_DEV_ID = 0,
+   DA7217_DEV_ID = 1,
DA7218_DEV_ID,
 };
 

-- 
2.40.1



[PATCH 2/5] ASoC: Drop unnecessary of_match_device() calls

2023-10-03 Thread Rob Herring
If probe is reached, we've already matched the device and in the case of
DT matching, the struct device_node pointer will be set. Therefore, there
is no need to call of_match_device() in probe.

Signed-off-by: Rob Herring 
---
 sound/soc/codecs/ak5386.c  |  7 ++-
 sound/soc/codecs/cs4271.c  | 22 ++
 sound/soc/codecs/tas5086.c |  6 +-
 3 files changed, 9 insertions(+), 26 deletions(-)

diff --git a/sound/soc/codecs/ak5386.c b/sound/soc/codecs/ak5386.c
index 0c5e00679c7d..21a44476f48d 100644
--- a/sound/soc/codecs/ak5386.c
+++ b/sound/soc/codecs/ak5386.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -168,7 +167,6 @@ static int ak5386_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
-   priv->reset_gpio = -EINVAL;
dev_set_drvdata(dev, priv);
 
for (i = 0; i < ARRAY_SIZE(supply_names); i++)
@@ -179,9 +177,8 @@ static int ak5386_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
 
-   if (of_match_device(of_match_ptr(ak5386_dt_ids), dev))
-   priv->reset_gpio = of_get_named_gpio(dev->of_node,
- "reset-gpio", 0);
+   priv->reset_gpio = of_get_named_gpio(dev->of_node,
+"reset-gpio", 0);
 
if (gpio_is_valid(priv->reset_gpio))
if (devm_gpio_request_one(dev, priv->reset_gpio,
diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c
index 188b8b43c524..9e6f8a048dd5 100644
--- a/sound/soc/codecs/cs4271.c
+++ b/sound/soc/codecs/cs4271.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -563,19 +562,12 @@ static int cs4271_component_probe(struct 
snd_soc_component *component)
struct cs4271_private *cs4271 = 
snd_soc_component_get_drvdata(component);
struct cs4271_platform_data *cs4271plat = component->dev->platform_data;
int ret;
-   bool amutec_eq_bmutec = false;
+   bool amutec_eq_bmutec;
 
-#ifdef CONFIG_OF
-   if (of_match_device(cs4271_dt_ids, component->dev)) {
-   if (of_get_property(component->dev->of_node,
-"cirrus,amutec-eq-bmutec", NULL))
-   amutec_eq_bmutec = true;
-
-   if (of_get_property(component->dev->of_node,
-"cirrus,enable-soft-reset", NULL))
-   cs4271->enable_soft_reset = true;
-   }
-#endif
+   amutec_eq_bmutec = of_property_read_bool(component->dev->of_node,
+"cirrus,amutec-eq-bmutec");
+   cs4271->enable_soft_reset = 
of_property_read_bool(component->dev->of_node,
+ 
"cirrus,enable-soft-reset");
 
ret = regulator_bulk_enable(ARRAY_SIZE(cs4271->supplies),
cs4271->supplies);
@@ -655,9 +647,7 @@ static int cs4271_common_probe(struct device *dev,
if (!cs4271)
return -ENOMEM;
 
-   if (of_match_device(cs4271_dt_ids, dev))
-   cs4271->gpio_nreset =
-   of_get_named_gpio(dev->of_node, "reset-gpio", 0);
+   cs4271->gpio_nreset = of_get_named_gpio(dev->of_node, "reset-gpio", 0);
 
if (cs4271plat)
cs4271->gpio_nreset = cs4271plat->gpio_nreset;
diff --git a/sound/soc/codecs/tas5086.c b/sound/soc/codecs/tas5086.c
index 60e59e993ba6..f52c14b43f28 100644
--- a/sound/soc/codecs/tas5086.c
+++ b/sound/soc/codecs/tas5086.c
@@ -940,11 +940,7 @@ static int tas5086_i2c_probe(struct i2c_client *i2c)
 
i2c_set_clientdata(i2c, priv);
 
-   if (of_match_device(of_match_ptr(tas5086_dt_ids), dev)) {
-   struct device_node *of_node = dev->of_node;
-   gpio_nreset = of_get_named_gpio(of_node, "reset-gpio", 0);
-   }
-
+   gpio_nreset = of_get_named_gpio(dev->of_node, "reset-gpio", 0);
if (gpio_is_valid(gpio_nreset))
if (devm_gpio_request(dev, gpio_nreset, "TAS5086 Reset"))
gpio_nreset = -EINVAL;

-- 
2.40.1



[PATCH 4/5] ASoC: qcom/lpass: Constify struct lpass_variant

2023-10-03 Thread Rob Herring
'struct lpass_variant' is used for driver match data which is supposed to
be constant. It's not modified anywhere, so it's just a matter of adding
'const' everywhere.

Signed-off-by: Rob Herring 
---
 sound/soc/qcom/lpass-apq8016.c  |  6 +++---
 sound/soc/qcom/lpass-cdc-dma.c  |  2 +-
 sound/soc/qcom/lpass-cpu.c  | 28 ++--
 sound/soc/qcom/lpass-ipq806x.c  |  2 +-
 sound/soc/qcom/lpass-platform.c | 36 ++--
 sound/soc/qcom/lpass-sc7180.c   |  6 +++---
 sound/soc/qcom/lpass-sc7280.c   |  6 +++---
 sound/soc/qcom/lpass.h  |  2 +-
 8 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c
index f919d46e18ca..8ce75b442b64 100644
--- a/sound/soc/qcom/lpass-apq8016.c
+++ b/sound/soc/qcom/lpass-apq8016.c
@@ -123,7 +123,7 @@ static struct snd_soc_dai_driver 
apq8016_lpass_cpu_dai_driver[] = {
 static int apq8016_lpass_alloc_dma_channel(struct lpass_data *drvdata,
   int direction, unsigned int dai_id)
 {
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
int chan = 0;
 
if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
@@ -157,7 +157,7 @@ static int apq8016_lpass_free_dma_channel(struct lpass_data 
*drvdata, int chan,
 static int apq8016_lpass_init(struct platform_device *pdev)
 {
struct lpass_data *drvdata = platform_get_drvdata(pdev);
-   struct lpass_variant *variant = drvdata->variant;
+   const struct lpass_variant *variant = drvdata->variant;
struct device *dev = >dev;
int ret, i;
 
@@ -223,7 +223,7 @@ static int apq8016_lpass_exit(struct platform_device *pdev)
 }
 
 
-static struct lpass_variant apq8016_data = {
+static const struct lpass_variant apq8016_data = {
.i2sctrl_reg_base   = 0x1000,
.i2sctrl_reg_stride = 0x1000,
.i2s_ports  = 4,
diff --git a/sound/soc/qcom/lpass-cdc-dma.c b/sound/soc/qcom/lpass-cdc-dma.c
index 8221e2cbe35c..6389c7b6051e 100644
--- a/sound/soc/qcom/lpass-cdc-dma.c
+++ b/sound/soc/qcom/lpass-cdc-dma.c
@@ -37,7 +37,7 @@ static void __lpass_get_dmactl_handle(struct 
snd_pcm_substream *substream, struc
struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
struct snd_pcm_runtime *rt = substream->runtime;
struct lpass_pcm_data *pcm_data = rt->private_data;
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
unsigned int dai_id = cpu_dai->driver->id;
 
switch (dai_id) {
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 39571fed4001..18aff2654f89 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -44,7 +44,7 @@ static int lpass_cpu_init_i2sctl_bitfields(struct device *dev,
struct lpaif_i2sctl *i2sctl, struct regmap *map)
 {
struct lpass_data *drvdata = dev_get_drvdata(dev);
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
 
i2sctl->loopback = devm_regmap_field_alloc(dev, map, v->loopback);
i2sctl->spken = devm_regmap_field_alloc(dev, map, v->spken);
@@ -463,7 +463,7 @@ static int asoc_qcom_of_xlate_dai_name(struct 
snd_soc_component *component,
   const char **dai_name)
 {
struct lpass_data *drvdata = snd_soc_component_get_drvdata(component);
-   struct lpass_variant *variant = drvdata->variant;
+   const struct lpass_variant *variant = drvdata->variant;
int id = args->args[0];
int ret = -EINVAL;
int i;
@@ -488,7 +488,7 @@ static const struct snd_soc_component_driver 
lpass_cpu_comp_driver = {
 static bool lpass_cpu_regmap_writeable(struct device *dev, unsigned int reg)
 {
struct lpass_data *drvdata = dev_get_drvdata(dev);
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
int i;
 
for (i = 0; i < v->i2s_ports; ++i)
@@ -530,7 +530,7 @@ static bool lpass_cpu_regmap_writeable(struct device *dev, 
unsigned int reg)
 static bool lpass_cpu_regmap_readable(struct device *dev, unsigned int reg)
 {
struct lpass_data *drvdata = dev_get_drvdata(dev);
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
int i;
 
for (i = 0; i < v->i2s_ports; ++i)
@@ -578,7 +578,7 @@ static bool lpass_cpu_regmap_readable(struct device *dev, 
unsigned int reg)
 static bool lpass_cpu_regmap_volatile(struct device *dev, unsigned int reg)
 {
struct lpass_data *drvdata = dev_get_drvdata(dev);
-   struct lpass_variant *v = drvdata->variant;
+   const struct lpass_variant *v = drvdata->variant;
int i;
 
for (i = 0; i < v->irq_ports; ++i) {
@@ -613,7 +613,7 @@ static struct regmap_config 

[PATCH 5/5] ASoC: Use device_get_match_data()

2023-10-03 Thread Rob Herring
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.

Signed-off-by: Rob Herring 
---
 sound/soc/intel/keembay/kmb_platform.c | 13 +
 sound/soc/qcom/lpass-cpu.c | 15 +--
 sound/soc/rockchip/rockchip_i2s.c  |  8 +++-
 sound/soc/rockchip/rockchip_i2s_tdm.c  | 20 +++-
 sound/soc/rockchip/rockchip_pdm.c  |  6 +-
 sound/soc/samsung/smdk_wm8994.c| 27 +++
 sound/soc/stm/stm32_i2s.c  |  7 ++-
 sound/soc/stm/stm32_sai.c  |  8 
 sound/soc/stm/stm32_sai_sub.c  |  6 +-
 sound/soc/stm/stm32_spdifrx.c  |  8 ++--
 sound/soc/tegra/tegra210_amx.c |  7 +--
 sound/soc/ti/davinci-evm.c |  7 ++-
 sound/soc/ti/davinci-mcasp.c   |  9 -
 sound/soc/ti/omap-mcbsp.c  | 10 --
 14 files changed, 40 insertions(+), 111 deletions(-)

diff --git a/sound/soc/intel/keembay/kmb_platform.c 
b/sound/soc/intel/keembay/kmb_platform.c
index e929497a5eb5..37ea2e1d2e92 100644
--- a/sound/soc/intel/keembay/kmb_platform.c
+++ b/sound/soc/intel/keembay/kmb_platform.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -820,7 +819,6 @@ static int kmb_plat_dai_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
struct snd_soc_dai_driver *kmb_i2s_dai;
-   const struct of_device_id *match;
struct device *dev = >dev;
struct kmb_i2s_info *kmb_i2s;
struct resource *res;
@@ -831,16 +829,7 @@ static int kmb_plat_dai_probe(struct platform_device *pdev)
if (!kmb_i2s)
return -ENOMEM;
 
-   kmb_i2s_dai = devm_kzalloc(dev, sizeof(*kmb_i2s_dai), GFP_KERNEL);
-   if (!kmb_i2s_dai)
-   return -ENOMEM;
-
-   match = of_match_device(kmb_plat_of_match, >dev);
-   if (!match) {
-   dev_err(>dev, "Error: No device match found\n");
-   return -ENODEV;
-   }
-   kmb_i2s_dai = (struct snd_soc_dai_driver *) match->data;
+   kmb_i2s_dai = (struct snd_soc_dai_driver 
*)device_get_match_data(>dev);
 
/* Prepare the related clocks */
kmb_i2s->clk_apb = devm_clk_get(dev, "apb_clk");
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 18aff2654f89..ac0feb89b458 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -1106,7 +1105,6 @@ int asoc_qcom_lpass_cpu_platform_probe(struct 
platform_device *pdev)
struct resource *res;
const struct lpass_variant *variant;
struct device *dev = >dev;
-   const struct of_device_id *match;
int ret, i, dai_id;
 
dsp_of_node = of_parse_phandle(pdev->dev.of_node, "qcom,adsp", 0);
@@ -1121,17 +1119,14 @@ int asoc_qcom_lpass_cpu_platform_probe(struct 
platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, drvdata);
 
-   match = of_match_device(dev->driver->of_match_table, dev);
-   if (!match || !match->data)
+   variant = device_get_match_data(dev);
+   if (!variant)
return -EINVAL;
 
-   if (of_device_is_compatible(dev->of_node, "qcom,lpass-cpu-apq8016")) {
-   dev_warn(dev, "%s compatible is deprecated\n",
-match->compatible);
-   }
+   if (of_device_is_compatible(dev->of_node, "qcom,lpass-cpu-apq8016"))
+   dev_warn(dev, "qcom,lpass-cpu-apq8016 compatible is 
deprecated\n");
 
-   drvdata->variant = (struct lpass_variant *)match->data;
-   variant = drvdata->variant;
+   drvdata->variant = variant;
 
of_lpass_cpu_parse_dai_data(dev, drvdata);
 
diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index 74e7d6ee0f28..b0c3ef030e06 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -10,8 +10,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -736,7 +736,6 @@ static int rockchip_i2s_init_dai(struct rk_i2s_dev *i2s, 
struct resource *res,
 static int rockchip_i2s_probe(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
-   const struct of_device_id *of_id;
struct rk_i2s_dev *i2s;
struct snd_soc_dai_driver *dai;
struct resource *res;
@@ -752,11 +751,10 @@ static int rockchip_i2s_probe(struct platform_device 
*pdev)
 
i2s->grf = syscon_regmap_lookup_by_phandle(node, "rockchip,grf");
if (!IS_ERR(i2s->grf)) {
-   of_id = of_match_device(rockchip_i2s_match, >dev);
-   if (!of_id || !of_id->data)
+   i2s->pins = device_get_match_data(>dev);
+  

[PATCH 0/5] ASoC: DT matching and header cleanups

2023-10-03 Thread Rob Herring
  |  1 -
 sound/soc/tegra/tegra_asoc_machine.c   |  1 -
 sound/soc/tegra/tegra_audio_graph_card.c   |  2 +-
 sound/soc/ti/davinci-evm.c |  7 +---
 sound/soc/ti/davinci-mcasp.c   |  9 ++---
 sound/soc/ti/omap-dmic.c   |  2 +-
 sound/soc/ti/omap-mcbsp.c  | 10 ++---
 sound/soc/ti/omap-mcpdm.c  |  2 +-
 162 files changed, 205 insertions(+), 390 deletions(-)
---
base-commit: c9f2baaa18b5ea8f006a2b3a616da9597c71d15e
change-id: 20231003-dt-asoc-header-cleanups-87f2cf5a2205

Best regards,
-- 
Rob Herring 



[PATCH] ALSA: aoa: Replace asm/prom.h with explicit includes

2023-10-03 Thread Rob Herring
asm/prom.h should not be included directly as it no longer contains
anything drivers need. Drivers should include of.h and/or other headers
which were getting implicitly included.

Signed-off-by: Rob Herring 
---
 sound/aoa/aoa-gpio.h| 1 -
 sound/aoa/aoa.h | 1 -
 sound/aoa/codecs/onyx.c | 1 +
 sound/aoa/codecs/onyx.h | 1 -
 sound/aoa/codecs/tas.c  | 2 +-
 sound/aoa/fabrics/layout.c  | 3 ++-
 sound/aoa/soundbus/core.c   | 2 ++
 sound/aoa/soundbus/i2sbus/control.c | 1 -
 sound/aoa/soundbus/i2sbus/core.c| 1 +
 sound/aoa/soundbus/i2sbus/i2sbus.h  | 1 -
 sound/aoa/soundbus/soundbus.h   | 2 +-
 11 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/sound/aoa/aoa-gpio.h b/sound/aoa/aoa-gpio.h
index 54f9a78fa08e..77ae75d7594c 100644
--- a/sound/aoa/aoa-gpio.h
+++ b/sound/aoa/aoa-gpio.h
@@ -9,7 +9,6 @@
 #define __AOA_GPIO_H
 #include 
 #include 
-#include 
 
 typedef void (*notify_func_t)(void *data);
 
diff --git a/sound/aoa/aoa.h b/sound/aoa/aoa.h
index 3d2d03ff6337..badff9f7cd54 100644
--- a/sound/aoa/aoa.h
+++ b/sound/aoa/aoa.h
@@ -7,7 +7,6 @@
 
 #ifndef __AOA_H
 #define __AOA_H
-#include 
 #include 
 #include 
 #include 
diff --git a/sound/aoa/codecs/onyx.c b/sound/aoa/codecs/onyx.c
index a8a59d71dcec..e90e03bb0dc0 100644
--- a/sound/aoa/codecs/onyx.c
+++ b/sound/aoa/codecs/onyx.c
@@ -30,6 +30,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 MODULE_AUTHOR("Johannes Berg ");
 MODULE_LICENSE("GPL");
diff --git a/sound/aoa/codecs/onyx.h b/sound/aoa/codecs/onyx.h
index 6c31b7373b78..bbdca841fe90 100644
--- a/sound/aoa/codecs/onyx.h
+++ b/sound/aoa/codecs/onyx.h
@@ -8,7 +8,6 @@
 #define __SND_AOA_CODEC_ONYX_H
 #include 
 #include 
-#include 
 
 /* PCM3052 register definitions */
 
diff --git a/sound/aoa/codecs/tas.c b/sound/aoa/codecs/tas.c
index ab1472390061..be9822ebf9f8 100644
--- a/sound/aoa/codecs/tas.c
+++ b/sound/aoa/codecs/tas.c
@@ -60,10 +60,10 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 MODULE_AUTHOR("Johannes Berg ");
diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
index 850dc8c53e9b..0cd19a05db19 100644
--- a/sound/aoa/fabrics/layout.c
+++ b/sound/aoa/fabrics/layout.c
@@ -7,9 +7,10 @@
  * This fabric module looks for sound codecs based on the
  * layout-id or device-id property in the device tree.
  */
-#include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include "../aoa.h"
 #include "../soundbus/soundbus.h"
diff --git a/sound/aoa/soundbus/core.c b/sound/aoa/soundbus/core.c
index 39fb8fe4e6ab..8f24a3eea16b 100644
--- a/sound/aoa/soundbus/core.c
+++ b/sound/aoa/soundbus/core.c
@@ -6,6 +6,8 @@
  */
 
 #include 
+#include 
+#include 
 #include "soundbus.h"
 
 MODULE_AUTHOR("Johannes Berg ");
diff --git a/sound/aoa/soundbus/i2sbus/control.c 
b/sound/aoa/soundbus/i2sbus/control.c
index 7d3abb8b2416..a003ef06de63 100644
--- a/sound/aoa/soundbus/i2sbus/control.c
+++ b/sound/aoa/soundbus/i2sbus/control.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c
index 51ed2f34b276..3f49a9e28bfc 100644
--- a/sound/aoa/soundbus/i2sbus/core.c
+++ b/sound/aoa/soundbus/i2sbus/core.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/sound/aoa/soundbus/i2sbus/i2sbus.h 
b/sound/aoa/soundbus/i2sbus/i2sbus.h
index e86fdbb3b4c5..7a3cae0d6c26 100644
--- a/sound/aoa/soundbus/i2sbus/i2sbus.h
+++ b/sound/aoa/soundbus/i2sbus/i2sbus.h
@@ -13,7 +13,6 @@
 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/sound/aoa/soundbus/soundbus.h b/sound/aoa/soundbus/soundbus.h
index db40f9d042b4..877cbad93f12 100644
--- a/sound/aoa/soundbus/soundbus.h
+++ b/sound/aoa/soundbus/soundbus.h
@@ -7,7 +7,7 @@
 #ifndef __SOUNDBUS_H
 #define __SOUNDBUS_H
 
-#include 
+#include 
 #include 
 #include 
 
-- 
2.40.1



Re: [PATCH] docs: move powerpc under arch

2023-10-03 Thread Jonathan Corbet
Costa Shulyupin  writes:

> and fix all in-tree references.
>
> Architecture-specific documentation is being moved into Documentation/arch/
> as a way of cleaning up the top-level documentation directory and making
> the docs hierarchy more closely match the source hierarchy.
>
> Signed-off-by: Costa Shulyupin 

So this patch appears to have not been picked up, and to have received
no comments.  I'll happily carry it in docs-next, but it would be nice
to have an ack from the powerpc folks...?

Thanks,

jon


Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes

2023-10-03 Thread Sean Christopherson
On Tue, Oct 03, 2023, Fuad Tabba wrote:
> Hi,
> 
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index d2d913acf0df..f8642ff2eb9d 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -1227,6 +1227,7 @@ struct kvm_ppc_resize_hpt {
> >  #define KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE 228
> >  #define KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES 229
> >  #define KVM_CAP_USER_MEMORY2 230
> > +#define KVM_CAP_MEMORY_ATTRIBUTES 231
> >
> >  #ifdef KVM_CAP_IRQ_ROUTING
> >
> > @@ -2293,4 +2294,17 @@ struct kvm_s390_zpci_op {
> >  /* flags for kvm_s390_zpci_op->u.reg_aen.flags */
> >  #define KVM_S390_ZPCIOP_REGAEN_HOST(1 << 0)
> >
> > +/* Available with KVM_CAP_MEMORY_ATTRIBUTES */
> > +#define KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES_IOR(KVMIO,  0xd2, __u64)
> > +#define KVM_SET_MEMORY_ATTRIBUTES  _IOW(KVMIO,  0xd3, struct 
> > kvm_memory_attributes)
> > +
> > +struct kvm_memory_attributes {
> > +   __u64 address;
> > +   __u64 size;
> > +   __u64 attributes;
> > +   __u64 flags;
> > +};
> > +
> > +#define KVM_MEMORY_ATTRIBUTE_PRIVATE   (1ULL << 3)
> > +
> 
> In pKVM, we don't want to allow setting (or clearing) of PRIVATE/SHARED
> attributes from userspace.

Why not?  The whole thing falls apart if userspace doesn't *know* the state of a
page, and the only way for userspace to know the state of a page at a given 
moment
in time is if userspace controls the attributes.  E.g. even if KVM were to 
provide
a way for userspace to query attributes, the attributes exposed to usrspace 
would
become stale the instant KVM drops slots_lock (or whatever lock protects the 
attributes)
since userspace couldn't prevent future changes.

Why does pKVM need to prevent userspace from stating *its* view of attributes?

If the goal is to reduce memory overhead, that can be solved by using an 
internal,
non-ABI attributes flag to track pKVM's view of SHARED vs. PRIVATE.  If the 
guest
attempts to access memory where pKVM and userspace don't agree on the state,
generate an exit to userspace.  Or kill the guest.  Or do something else 
entirely.

> However, we'd like to use the attributes xarray to track the sharing state of
> guest pages at the host kernel.
> 
> Moreover, we'd rather the default guest page state be PRIVATE, and
> only specify which pages are shared. All pKVM guest pages start off as
> private, and the majority will remain so.

I would rather optimize kvm_vm_set_mem_attributes() to generate range-based
xarray entries, at which point it shouldn't matter all that much whether PRIVATE
or SHARED is the default "empty" state.  We opted not to do that for the initial
merge purely to keep the code as simple as possible (which is obviously still 
not
exactly simple).

With range-based xarray entries, the cost of tagging huge chunks of memory as
PRIVATE should be a non-issue.  And if that's not enough for whatever reason, I
would rather define the polarity of PRIVATE on a per-VM basis, but only for 
internal
storage.
 
> I'm not sure if this is the best way to do this: One idea would be to move
> the definition of KVM_MEMORY_ATTRIBUTE_PRIVATE to
> arch/*/include/asm/kvm_host.h, which is where kvm_arch_supported_attributes()
> lives as well. This would allow different architectures to specify their own
> attributes (i.e., instead we'd have a KVM_MEMORY_ATTRIBUTE_SHARED for pKVM).
> This wouldn't help in terms of preventing userspace from clearing attributes
> (i.e., setting a 0 attribute) though.
> 
> The other thing, which we need for pKVM anyway, is to make
> kvm_vm_set_mem_attributes() global, so that it can be called from outside of
> kvm_main.c (already have a local patch for this that declares it in
> kvm_host.h),

That's no problem, but I am definitely opposed to KVM modifying attributes that
are owned by userspace.

> and not gate this function by KVM_GENERIC_MEMORY_ATTRIBUTES.

As above, I am opposed to pKVM having a completely different ABI for managing
PRIVATE vs. SHARED.  I have no objection to pKVM using unclaimed flags in the
attributes to store extra metadata, but if KVM_SET_MEMORY_ATTRIBUTES doesn't 
work
for pKVM, then we've failed miserably and should revist the uAPI.


Re: [PATCH] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries

2023-10-03 Thread Adhemerval Zanella Netto



On 02/10/23 18:19, Peter Bergner wrote:
> Hi Adhemerval, sorry for the delay in replying, I was a little under the
> weather last week.
> 
> 
> On 9/27/23 11:03 AM, Adhemerval Zanella Netto wrote:
>> On 26/09/23 19:02, Peter Bergner wrote:
>>> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for 
>>> fast
>>> access by our __builtin_cpu_supports built-in function.  The TCB space for
>>> the HWCAP entries - which are created in pairs - is an ABI extension, so
>>> waiting to create the space for HWCAP3 and HWCAP4 until we need them is
>>> problematical, given distro unwillingness to apply ABI modifying patches
>>> to distro point releases.  Define AT_HWCAP3 and AT_HWCAP4 in the generic
>>> uapi header so they can be used in GLIBC to reserve space in the powerpc
>>> TCB for their future use.
>>
>> This is different than previously exported auxv, where each AT_* constant
>> would have a auxv entry. On glibc it would require changing _dl_parse_auxv
>> to iterate over the auxv_values to find AT_HWCAP3/AT_HWCAP4 (not ideal, 
>> but doable).
> 
> When you say different, do you mean because all AUXVs exported by the kernel
> *will* have an AT_HWCAP and AT_HWCAP2 entry and AT_HWCAP3/AT_HWCAP4 won't?
> I don't think that's a problem for either kernel or glibc side of things.
> I'm not even sure there is a guarantee that every AT_* value *must* be
> present in the exported AUXV.
> 
> The new AT_HWCAP3/AT_HWCAP4 defines are less than AT_MINSIGSTKSZ, so they
> don't affect the size of _dl_parse_auxv's auxv_values array size and the
> AT_HWCAP3 and AT_HWCAP4 entries in auxv_values[] are already initialized
> to zero today.  Additionally, the loop in _dl_parse_auxv already parses
> the entire AUXV, so there is no extra work for it to do, unless and until
> AT_HWCAP3 and AT_HWCAP4 start being exported by the kernel.  Really, the
> only extra work _dl_parse_auxv would need to do, is add two new stores:
> 
>   GLRO(dl_hwcap3) = auxv_values[AT_HWCAP3];
>   GLRO(dl_hwcap4) = auxv_values[AT_HWCAP4];
> 

Indeed you are right, I wrong assumed that the AT_HWCAP3/AT_HWCAP4 would
be higher than AT_MINSIGSTKSZ. 

> 
> 
>> Wouldn't be better to always export it on fs/binfmt_elf.c, along with all 
>> the machinery to setup it (ELF_HWCAP3, etc), along with proper documentation?
> 
> You mean modify the kernel now to export AT_HWCAP3 and AT_HWCAP4 as zero
> masks?  Is that really necessary since we don't need or have any features
> defined in them yet?  GLIBC's _dl_parse_auxv doesn't really need them to
> be exported either, since in the absence of the entries, it will just end
> up using zero masks for dl_hwcap3 and dl_hwcap4, so everything is copacetic
> even without any kernel changes.
> 
> As I mentioned, our real problem is the lead time for getting changes that
> affect the user ABI into a distro release, and ppc's copy/cache of the HWCAP
> masks is an ABI change.  If we wait to add this support until when we
> actually have a need for HWCAP3, then we won't have any support until
> the next major distro release.  However, if we can add this support now,
> which I don't think is an onerous change on glibc's part, then we can
> start using it immediately when Linux starts exporting them.

What it is not clear to me is what kind of ABI boundary you are trying to
preemptively add support here. The TCB ABI for __builtin_cpu_supports is
userland only, so if your intention is just to allow gcc to work on older
glibcs, it should be a matter to just reserve the space on tcbhead_t.  Once
kernel actually provides AT_HWCAP3/AT_HWCAP4, backporting should be
straightforward.

If your intention is to also add support on glibc, it makes more sense to
already reserve it.  For __builtin_cpu_supports it should work, although
for glibc itself some backporting would be required (to correctly showing
the bits with LD_SHOW_AUXV).




Re: [PATCH 3/3] PCI: Use PCI_HEADER_TYPE_* instead of literals

2023-10-03 Thread Wolfram Sang
On Tue, Oct 03, 2023 at 03:53:00PM +0300, Ilpo Järvinen wrote:
> Replace literals under drivers/pci/ with PCI_HEADER_TYPE_MASK,
> PCI_HEADER_TYPE_NORMAL, and PCI_HEADER_TYPE_MFD.
> 
> While at it, replace !! boolean conversion with FIELD_GET().
> 
> Signed-off-by: Ilpo Järvinen 

Reviewed-by: Wolfram Sang  # for Renesas R-Car



signature.asc
Description: PGP signature


[PATCH 3/3] PCI: Use PCI_HEADER_TYPE_* instead of literals

2023-10-03 Thread Ilpo Järvinen
Replace literals under drivers/pci/ with PCI_HEADER_TYPE_MASK,
PCI_HEADER_TYPE_NORMAL, and PCI_HEADER_TYPE_MFD.

While at it, replace !! boolean conversion with FIELD_GET().

Signed-off-by: Ilpo Järvinen 
---
 drivers/pci/controller/dwc/pci-layerscape.c   |  2 +-
 .../controller/mobiveil/pcie-mobiveil-host.c  |  2 +-
 drivers/pci/controller/pcie-iproc.c   |  2 +-
 drivers/pci/controller/pcie-rcar-ep.c |  2 +-
 drivers/pci/controller/pcie-rcar-host.c   |  2 +-
 drivers/pci/controller/vmd.c  |  2 +-
 drivers/pci/hotplug/cpqphp_ctrl.c |  6 ++---
 drivers/pci/hotplug/cpqphp_pci.c  | 22 +--
 drivers/pci/hotplug/ibmphp.h  |  5 +++--
 drivers/pci/hotplug/ibmphp_pci.c  |  2 +-
 drivers/pci/pci.c |  2 +-
 drivers/pci/quirks.c  |  6 ++---
 12 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c 
b/drivers/pci/controller/dwc/pci-layerscape.c
index ed5fb492fe08..69a4aa5cfc20 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -41,7 +41,7 @@ static bool ls_pcie_is_bridge(struct ls_pcie *pcie)
u32 header_type;
 
header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
-   header_type &= 0x7f;
+   header_type &= PCI_HEADER_TYPE_MASK;
 
return header_type == PCI_HEADER_TYPE_BRIDGE;
 }
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c 
b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
index 45b97a4b14db..32951f7d6d6d 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
@@ -539,7 +539,7 @@ static bool mobiveil_pcie_is_bridge(struct mobiveil_pcie 
*pcie)
u32 header_type;
 
header_type = mobiveil_csr_readb(pcie, PCI_HEADER_TYPE);
-   header_type &= 0x7f;
+   header_type &= PCI_HEADER_TYPE_MASK;
 
return header_type == PCI_HEADER_TYPE_BRIDGE;
 }
diff --git a/drivers/pci/controller/pcie-iproc.c 
b/drivers/pci/controller/pcie-iproc.c
index bd1c98b68851..97f739a2c9f8 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -783,7 +783,7 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
 
/* make sure we are not in EP mode */
iproc_pci_raw_config_read32(pcie, 0, PCI_HEADER_TYPE, 1, _type);
-   if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE) {
+   if ((hdr_type & PCI_HEADER_TYPE_MASK) != PCI_HEADER_TYPE_BRIDGE) {
dev_err(dev, "in EP mode, hdr=%#02x\n", hdr_type);
return -EFAULT;
}
diff --git a/drivers/pci/controller/pcie-rcar-ep.c 
b/drivers/pci/controller/pcie-rcar-ep.c
index f9682df1da61..7034c0ff23d0 100644
--- a/drivers/pci/controller/pcie-rcar-ep.c
+++ b/drivers/pci/controller/pcie-rcar-ep.c
@@ -43,7 +43,7 @@ static void rcar_pcie_ep_hw_init(struct rcar_pcie *pcie)
rcar_rmw32(pcie, REXPCAP(0), 0xff, PCI_CAP_ID_EXP);
rcar_rmw32(pcie, REXPCAP(PCI_EXP_FLAGS),
   PCI_EXP_FLAGS_TYPE, PCI_EXP_TYPE_ENDPOINT << 4);
-   rcar_rmw32(pcie, RCONF(PCI_HEADER_TYPE), 0x7f,
+   rcar_rmw32(pcie, RCONF(PCI_HEADER_TYPE), PCI_HEADER_TYPE_MASK,
   PCI_HEADER_TYPE_NORMAL);
 
/* Write out the physical slot number = 0 */
diff --git a/drivers/pci/controller/pcie-rcar-host.c 
b/drivers/pci/controller/pcie-rcar-host.c
index 88975e40ee2f..bf7cc0b6a695 100644
--- a/drivers/pci/controller/pcie-rcar-host.c
+++ b/drivers/pci/controller/pcie-rcar-host.c
@@ -460,7 +460,7 @@ static int rcar_pcie_hw_init(struct rcar_pcie *pcie)
rcar_rmw32(pcie, REXPCAP(0), 0xff, PCI_CAP_ID_EXP);
rcar_rmw32(pcie, REXPCAP(PCI_EXP_FLAGS),
PCI_EXP_FLAGS_TYPE, PCI_EXP_TYPE_ROOT_PORT << 4);
-   rcar_rmw32(pcie, RCONF(PCI_HEADER_TYPE), 0x7f,
+   rcar_rmw32(pcie, RCONF(PCI_HEADER_TYPE), PCI_HEADER_TYPE_MASK,
PCI_HEADER_TYPE_BRIDGE);
 
/* Enable data link layer active state reporting */
diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index d5b97a6aae56..cc2422963a34 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -527,7 +527,7 @@ static void vmd_domain_reset(struct vmd_dev *vmd)
 
hdr_type = readb(base + PCI_HEADER_TYPE);
 
-   functions = (hdr_type & 0x80) ? 8 : 1;
+   functions = (hdr_type & PCI_HEADER_TYPE_MFD) ? 8 : 1;
for (fn = 0; fn < functions; fn++) {
base = vmd->cfgbar + PCIE_ECAM_OFFSET(bus,
PCI_DEVFN(dev, fn), 0);
diff --git a/drivers/pci/hotplug/cpqphp_ctrl.c 
b/drivers/pci/hotplug/cpqphp_ctrl.c
index e429ecddc8fe..c01968ef0bd7 100644
--- a/drivers/pci/hotplug/cpqphp_ctrl.c
+++ 

[PATCH 2/3] PCI: Add PCI_HEADER_TYPE_MFD pci_regs.h

2023-10-03 Thread Ilpo Järvinen
Add PCI_HEADER_TYPE_MFD into pci_regs.h to be able to replace
literals in the code.

Signed-off-by: Ilpo Järvinen 
---
 include/uapi/linux/pci_regs.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index e5f558d96493..06df65f11c39 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -80,6 +80,7 @@
 #define  PCI_HEADER_TYPE_NORMAL0
 #define  PCI_HEADER_TYPE_BRIDGE1
 #define  PCI_HEADER_TYPE_CARDBUS   2
+#define  PCI_HEADER_TYPE_MFD   0x80/* Multi-Function Device 
(possible) */
 
 #define PCI_BIST   0x0f/* 8 bits */
 #define  PCI_BIST_CODE_MASK0x0f/* Return result */
-- 
2.30.2



[PATCH 1/3] PCI: vmd: Correct PCI Header Type Register's MFD bit check

2023-10-03 Thread Ilpo Järvinen
vmd_domain_reset() attempts to find whether the device may contain
multiple functions by checking 0x80 (Multi-Function Device), however,
the hdr_type variable has already been masked with PCI_HEADER_TYPE_MASK
so the check can never true.

To fix the issue, don't mask the read with PCI_HEADER_TYPE_MASK.

Fixes: 6aab5622296b ("PCI: vmd: Clean up domain before enumeration")
Signed-off-by: Ilpo Järvinen 
Cc: Nirmal Patel 
---
 drivers/pci/controller/vmd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index e718a816d481..d5b97a6aae56 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -525,8 +525,7 @@ static void vmd_domain_reset(struct vmd_dev *vmd)
base = vmd->cfgbar + PCIE_ECAM_OFFSET(bus,
PCI_DEVFN(dev, 0), 0);
 
-   hdr_type = readb(base + PCI_HEADER_TYPE) &
-PCI_HEADER_TYPE_MASK;
+   hdr_type = readb(base + PCI_HEADER_TYPE);
 
functions = (hdr_type & 0x80) ? 8 : 1;
for (fn = 0; fn < functions; fn++) {
-- 
2.30.2



[PATCH 0/3] PCI: PCI_HEADER_TYPE bugfix & cleanups

2023-10-03 Thread Ilpo Järvinen
One bugfix and cleanups for PCI_HEADER_TYPE_* literals.

This series only covers what's within drivers/pci/. I'd have patches
for other subsystems too but I decided to wait with them until
PCI_HEADER_TYPE_MFD is in Linus' tree (to keep the series receipient
count reasonable, the rest can IMO go through the subsystem specific
trees once the define is there).

Ilpo Järvinen (3):
  PCI: vmd: Correct PCI Header Type Register's MFD bit check
  PCI: Add PCI_HEADER_TYPE_MFD pci_regs.h
  PCI: Use PCI_HEADER_TYPE_* instead of literals

 drivers/pci/controller/dwc/pci-layerscape.c   |  2 +-
 .../controller/mobiveil/pcie-mobiveil-host.c  |  2 +-
 drivers/pci/controller/pcie-iproc.c   |  2 +-
 drivers/pci/controller/pcie-rcar-ep.c |  2 +-
 drivers/pci/controller/pcie-rcar-host.c   |  2 +-
 drivers/pci/controller/vmd.c  |  5 ++---
 drivers/pci/hotplug/cpqphp_ctrl.c |  6 ++---
 drivers/pci/hotplug/cpqphp_pci.c  | 22 +--
 drivers/pci/hotplug/ibmphp.h  |  5 +++--
 drivers/pci/hotplug/ibmphp_pci.c  |  2 +-
 drivers/pci/pci.c |  2 +-
 drivers/pci/quirks.c  |  6 ++---
 include/uapi/linux/pci_regs.h |  1 +
 13 files changed, 30 insertions(+), 29 deletions(-)

-- 
2.30.2



Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes

2023-10-03 Thread Fuad Tabba
Hi,

> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index d2d913acf0df..f8642ff2eb9d 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1227,6 +1227,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE 228
>  #define KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES 229
>  #define KVM_CAP_USER_MEMORY2 230
> +#define KVM_CAP_MEMORY_ATTRIBUTES 231
>
>  #ifdef KVM_CAP_IRQ_ROUTING
>
> @@ -2293,4 +2294,17 @@ struct kvm_s390_zpci_op {
>  /* flags for kvm_s390_zpci_op->u.reg_aen.flags */
>  #define KVM_S390_ZPCIOP_REGAEN_HOST(1 << 0)
>
> +/* Available with KVM_CAP_MEMORY_ATTRIBUTES */
> +#define KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES_IOR(KVMIO,  0xd2, __u64)
> +#define KVM_SET_MEMORY_ATTRIBUTES  _IOW(KVMIO,  0xd3, struct 
> kvm_memory_attributes)
> +
> +struct kvm_memory_attributes {
> +   __u64 address;
> +   __u64 size;
> +   __u64 attributes;
> +   __u64 flags;
> +};
> +
> +#define KVM_MEMORY_ATTRIBUTE_PRIVATE   (1ULL << 3)
> +

In pKVM, we don't want to allow setting (or clearing) of
PRIVATE/SHARED attributes from userspace. However, we'd like to use
the attributes xarray to track the sharing state of guest pages at the
host kernel.

Moreover, we'd rather the default guest page state be PRIVATE, and
only specify which pages are shared. All pKVM guest pages start off as
private, and the majority will remain so.

I'm not sure if this is the best way to do this: One idea would be to
move the definition of KVM_MEMORY_ATTRIBUTE_PRIVATE to
arch/*/include/asm/kvm_host.h, which is where
kvm_arch_supported_attributes() lives as well. This would allow
different architectures to specify their own attributes (i.e., instead
we'd have a KVM_MEMORY_ATTRIBUTE_SHARED for pKVM). This wouldn't help
in terms of preventing userspace from clearing attributes (i.e.,
setting a 0 attribute) though.

The other thing, which we need for pKVM anyway, is to make
kvm_vm_set_mem_attributes() global, so that it can be called from
outside of kvm_main.c (already have a local patch for this that
declares it in kvm_host.h), and not gate this function by
KVM_GENERIC_MEMORY_ATTRIBUTES. This would let pKVM select only
KVM_PRIVATE_MEM (as opposed to KVM_GENERIC_PRIVATE_MEM, which selects
KVM_GENERIC_MEMORY_ATTRIBUTES), preventing userspace from setting
these attributes, while allowing pKVM to call
kvm_vm_set_mem_attributes().

What do you think?

Thanks,
/fuad


Re: [PATCH v2 00/15] sysctl: Remove sentinel elements from drivers

2023-10-03 Thread Joel Granados
On Mon, Oct 02, 2023 at 12:27:18PM +, Christophe Leroy wrote:
> 
> 
> Le 02/10/2023 à 10:55, Joel Granados via B4 Relay a écrit :
> > From: Joel Granados 
> > 
<--- snip --->
> >  - The "yesall" config saves 2432 bytes [4]
> >  - The "tiny" config saves 64 bytes [5]
> >  * memory usage:
> >  In this case there were no bytes saved because I do not have any
> >  of the drivers in the patch. To measure it comment the printk in
> >  `new_dir` and uncomment the if conditional in `new_links` [3].
> > 
> > ---
> > Changes in v2:
> > - Left the dangling comma in the ctl_table arrays.
> > - Link to v1: 
> > https://lore.kernel.org/r/20230928-jag-sysctl_remove_empty_elem_drivers-v1-0-e59120fca...@samsung.com
> > 
> > Comments/feedback greatly appreciated
> 
> Same problem on powerpc CI tests, all boot target failed, most of them 
> with similar OOPS, see 
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20231002-jag-sysctl_remove_empty_elem_drivers-v2-15-02dd0d46f...@samsung.com/
I found the culprit!. Here you are rebasing on top of v6.5.0-rc6 "INFO:
Looking for kernel version: 6.5.0-rc6-gbf2ac4d7d596". The error makes
sense becuase in that version we have not introduced the stopping
criteria based on the ctl_table array size, so the loop continues
looking for an empty sentinel past valid memory (and does not find it).
The ctl_table check catches it but then fails to do a proper error
because we have already tried to access invalid memory. The solution
here is to make sure to rebase in on top of the latest rc in v6.6.

> 
> What is strange is that I pushed your series into my github account, and 
> got no failure, see https://github.com/chleroy/linux/actions/runs/6378951278
And here it works because you use the latest rc : "INFO: Looking for
kernel version: 6.6.0-rc3-g23d4b5db743c"

> 
> Christophe
> 
> > 
> > Best
> > 
> > Joel
> > 
> > [1]
> > We are able to remove a sentinel table without behavioral change by
> > introducing a table_size argument in the same place where procname is
> > checked for NULL. The idea is for it to keep stopping when it hits
> > ->procname == NULL, while the sentinel is still present. And when the
> > sentinel is removed, it will stop on the table_size. You can go to
> > (https://lore.kernel.org/all/20230809105006.1198165-1-j.grana...@samsung.com/)
> > for more information.
> > 
> > [2]
> > Links Related to the ctl_table sentinel removal:
> > * Good summary from Luis sent with the "pull request" for the
> >preparation patches.
> >https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/
> > * Another very good summary from Luis.
> >https://lore.kernel.org/all/zmfizkfkvxuft...@bombadil.infradead.org/
> > * This is a patch set that replaces register_sysctl_table with 
> > register_sysctl
> >https://lore.kernel.org/all/20230302204612.782387-1-mcg...@kernel.org/
> > * Patch set to deprecate register_sysctl_paths()
> >https://lore.kernel.org/all/20230302202826.776286-1-mcg...@kernel.org/
> > * Here there is an explicit expectation for the removal of the sentinel 
> > element.
> >https://lore.kernel.org/all/20230321130908.6972-1-frank...@vivo.com
> > * The "ARRAY_SIZE" approach was mentioned (proposed?) in this thread
> >https://lore.kernel.org/all/20220220060626.15885-1-tangm...@uniontech.com
> > 
> > [3]
> > To measure the in memory savings apply this on top of this patchset.
> > 
> > "
> > diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
> > index c88854df0b62..e0073a627bac 100644
> > --- a/fs/proc/proc_sysctl.c
> > +++ b/fs/proc/proc_sysctl.c
> > @@ -976,6 +976,8 @@ static struct ctl_dir *new_dir(struct ctl_table_set 
> > *set,
> >  table[0].procname = new_name;
> >  table[0].mode = S_IFDIR|S_IRUGO|S_IXUGO;
> >  init_header(>header, set->dir.header.root, set, node, table, 
> > 1);
> > +   // Counts additional sentinel used for each new dir.
> > +   printk("%ld sysctl saved mem kzalloc \n", sizeof(struct ctl_table));
> > 
> >  return new;
> >   }
> > @@ -1199,6 +1201,9 @@ static struct ctl_table_header *new_links(struct 
> > ctl_dir *dir, struct ctl_table_
> >  link_name += len;
> >  link++;
> >  }
> > +   // Counts additional sentinel used for each new registration
> > +   //if ((head->ctl_table + head->ctl_table_size)->procname)
> > +   printk("%ld sysctl saved mem kzalloc \n", sizeof(struct 
> > ctl_table));
> >  init_header(links, dir->header.root, dir->header.set, node, 
> > link_table,
> >  head->ctl_table_size);
> >  links->nreg = nr_entries;
> > "
> > and then run the following bash script in the kernel:
> > 
> > accum=0
> > for n in $(dmesg | grep kzalloc | awk '{print $3}') ; do
> >  echo $n
> >  accum=$(calc "$accum + $n")
> > done
> > echo $accum
> > 
> > [4]
> > add/remove: 0/0 grow/shrink: 0/21 up/down: 0/-2432 (-2432)
> > 

Re: [PATCH v8 20/24] iommu: Require a default_domain for all iommu drivers

2023-10-03 Thread Dmitry Baryshkov
On Tue, 3 Oct 2023 at 02:00, Jason Gunthorpe  wrote:
>
> On Tue, Oct 03, 2023 at 12:21:59AM +0300, Dmitry Baryshkov wrote:
> > On Wed, 13 Sept 2023 at 16:45, Jason Gunthorpe  wrote:
> > >
> > > At this point every iommu driver will cause a default_domain to be
> > > selected, so we can finally remove this gap from the core code.
> > >
> > > The following table explains what each driver supports and what the
> > > resulting default_domain will be:
> > >
> > > ops->defaut_domain
> > > IDENTITY   DMA  PLATFORMv  ARM32  
> > > dma-iommu  ARCH
> > > amd/iommu.c Y   Y   N/A 
> > > either
> > > apple-dart.cY   Y   N/A 
> > > either
> > > arm-smmu.c  Y   Y   IDENTITY
> > > either
> > > qcom_iommu.cG   Y   IDENTITY
> > > either
> > > arm-smmu-v3.c   Y   Y   N/A 
> > > either
> > > exynos-iommu.c  G   Y   IDENTITY
> > > either
> > > fsl_pamu_domain.c   Y   Y   N/A 
> > > N/A PLATFORM
> > > intel/iommu.c   Y   Y   N/A 
> > > either
> > > ipmmu-vmsa.cG   Y   IDENTITY
> > > either
> > > msm_iommu.c G   IDENTITY
> > > N/A
> >
> > Unfortunately this patch breaks msm_iommu platforms. This driver
> > doesn't select ARM_DMA_USE_IOMMU, so iommu_get_default_domain_type()
> > returns 0, bus_iommu_probe() fails with -ENODEV.
> > If I make MSM_IOMMU select ARM_DMA_USE_IOMMU, then GPU probing fails
> > with -EBUSY.
>
> Oh, OK.
>
> Does this fix it?

It indeed fixes the issue, so could you please post it, adding:
Tested-by: Dmitry Baryshkov 

> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index cdc7b730192a35..f7ef081c33dcb2 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -685,10 +685,16 @@ irqreturn_t msm_iommu_fault_handler(int irq, void 
> *dev_id)
> return 0;
>  }
>
> +static int msm_iommu_def_domain_type(struct device *dev)
> +{
> +   return IOMMU_DOMAIN_IDENTITY;
> +}
> +
>  static struct iommu_ops msm_iommu_ops = {
> .identity_domain = _iommu_identity_domain,
> .domain_alloc_paging = msm_iommu_domain_alloc_paging,
> .probe_device = msm_iommu_probe_device,
> +   .def_domain_type = msm_iommu_def_domain_type,
> .device_group = generic_device_group,
> .pgsize_bitmap = MSM_IOMMU_PGSIZES,
> .of_xlate = qcom_iommu_of_xlate,

-- 
With best wishes
Dmitry


Re: [PATCH 0/3] Fix for shellcheck issues with latest scripts in tests/shell

2023-10-03 Thread kajoljain
Patchset looks fine to me.

Reviewed-by: Kajol Jain 

thanks,
Kajol Jain

On 9/29/23 09:41, Athira Rajeev wrote:
> shellcheck was run on perf tool shell scripts as a pre-requisite
> to include a build option for shellcheck discussed here:
> https://www.spinics.net/lists/linux-perf-users/msg25553.html
> 
> And fixes were added for the coding/formatting issues in
> two patchsets:
> https://lore.kernel.org/linux-perf-users/20230613164145.50488-1-atraj...@linux.vnet.ibm.com/
> https://lore.kernel.org/linux-perf-users/20230709182800.53002-1-atraj...@linux.vnet.ibm.com/
> 
> Three additional issues were observed and fixes are part of:
> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/?h=perf-tools-next
> 
> With recent commits in perf, other three issues are observed.
> shellcheck version: 0.6.0
> 
> With this patchset:
> 
> for F in $(find tests/shell/ -perm -o=x -name '*.sh'); do shellcheck -S 
> warning $F; done
> echo $?
> 0
> 
> The changes are with recent commits ( which is mentioned in each patch)
> for ock_contention, record_sideband and test_arm_coresight testcases.
> The changes are made on top of:
> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/?h=perf-tools-next
> 
> Athira Rajeev (3):
>   perf tests test_arm_coresight: Fix the shellcheck warning in latest
> test_arm_coresight.sh
>   tools/perf/tests Ignore the shellcheck SC2046 warning in
> lock_contentio
>   tools/perf/tests: Fix shellcheck warning in record_sideband.sh test
> 
>  tools/perf/tests/shell/lock_contention.sh| 1 +
>  tools/perf/tests/shell/record_sideband.sh| 2 +-
>  tools/perf/tests/shell/test_arm_coresight.sh | 4 ++--
>  3 files changed, 4 insertions(+), 3 deletions(-)
> 


Re: [PATCH V5 1/3] tools/perf: Add text_end to "struct dso" to save .text section size

2023-10-03 Thread Athira Rajeev



> On 03-Oct-2023, at 9:58 AM, Namhyung Kim  wrote:
> 
> Hello,
> 
> On Thu, Sep 28, 2023 at 12:52 AM Athira Rajeev
>  wrote:
>> 
>> Update "struct dso" to include new member "text_end".
>> This new field will represent the offset for end of text
>> section for a dso. For elf, this value is derived as:
>> sh_size (Size of section in byes) + sh_offset (Section file
>> offst) of the elf header for text.
>> 
>> For bfd, this value is derived as:
>> 1. For PE file,
>> section->size + ( section->vma - dso->text_offset)
>> 2. Other cases:
>> section->filepos (file position) + section->size (size of
>> section)
>> 
>> To resolve the address from a sample, perf looks at the
>> DSO maps. In case of address from a kernel module, there
>> were some address found to be not resolved. This was
>> observed while running perf test for "Object code reading".
>> Though the ip falls beteen the start address of the loaded
>> module (perf map->start ) and end address ( perf map->end),
>> it was unresolved.
>> 
>> Example:
>> 
>>Reading object code for memory address: 0xc00807f0142c
>>File is: /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
>>On file address is: 0x1114cc
>>Objdump command is: objdump -z -d --start-address=0x11142c 
>> --stop-address=0x1114ac /lib/modules/6.5.0-rc3+/kernel/fs/xfs/xfs.ko
>>objdump read too few bytes: 128
>>test child finished with -1
>> 
>> Here, module is loaded at:
>># cat /proc/modules | grep xfs
>>xfs 2228224 3 - Live 0xc00807d0
>> 
>> From objdump for xfs module, text section is:
>>text 0010f7bc    00a0 2**4
>> 
>> Here the offset for 0xc00807f0142c ie  0x112074 falls out
>> .text section which is up to 0x10f7bc.
>> 
>> In this case for module, the address 0xc00807e11fd4 is pointing
>> to stub instructions. This address range represents the module stubs
>> which is allocated on module load and hence is not part of DSO offset.
>> 
>> To identify such  address, which falls out of text
>> section and within module end, added the new field "text_end" to
>> "struct dso".
>> 
>> Reported-by: Disha Goel 
>> Signed-off-by: Athira Rajeev 
>> Reviewed-by: Adrian Hunter 
>> Reviewed-by: Kajol Jain 
> 
> For the series,
> Acked-by: Namhyung Kim 
> 
> Thanks,
> Namhyung

Thanks for checking Namhyung,

Athira
> 
> 
>> ---
>> Changelog:
>> v2 -> v3:
>> Added Reviewed-by from Adrian
>> 
>> v1 -> v2:
>> Added text_end for bfd also by updating dso__load_bfd_symbols
>> as suggested by Adrian.
>> 
>> tools/perf/util/dso.h| 1 +
>> tools/perf/util/symbol-elf.c | 4 +++-
>> tools/perf/util/symbol.c | 2 ++
>> 3 files changed, 6 insertions(+), 1 deletion(-)
>> 
>> diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
>> index b41c9782c754..70fe0fe69bef 100644
>> --- a/tools/perf/util/dso.h
>> +++ b/tools/perf/util/dso.h
>> @@ -181,6 +181,7 @@ struct dso {
>>u8   rel;
>>struct build_id  bid;
>>u64  text_offset;
>> +   u64  text_end;
>>const char   *short_name;
>>const char   *long_name;
>>u16  long_name_len;
>> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
>> index 95e99c332d7e..9e7eeaf616b8 100644
>> --- a/tools/perf/util/symbol-elf.c
>> +++ b/tools/perf/util/symbol-elf.c
>> @@ -1514,8 +1514,10 @@ dso__load_sym_internal(struct dso *dso, struct map 
>> *map, struct symsrc *syms_ss,
>>}
>> 
>>if (elf_section_by_name(runtime_ss->elf, _ss->ehdr, ,
>> -   ".text", NULL))
>> +   ".text", NULL)) {
>>dso->text_offset = tshdr.sh_addr - tshdr.sh_offset;
>> +   dso->text_end = tshdr.sh_offset + tshdr.sh_size;
>> +   }
>> 
>>if (runtime_ss->opdsec)
>>opddata = elf_rawdata(runtime_ss->opdsec, NULL);
>> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
>> index 3f36675b7c8f..f25e4e62cf25 100644
>> --- a/tools/perf/util/symbol.c
>> +++ b/tools/perf/util/symbol.c
>> @@ -1733,8 +1733,10 @@ int dso__load_bfd_symbols(struct dso *dso, const char 
>> *debugfile)
>>/* PE symbols can only have 4 bytes, so use .text 
>> high bits */
>>dso->text_offset = section->vma - (u32)section->vma;
>>dso->text_offset += 
>> (u32)bfd_asymbol_value(symbols[i]);
>> +   dso->text_end = (section->vma - dso->text_offset) + 
>> section->size;
>>} else {
>>dso->text_offset = section->vma - section->filepos;
>> +   dso->text_end = section->filepos + section->size;
>>}
>>}
>> 
>> --
>> 2.31.1




Re: [net-next PATCH 2/4] netdev: make napi_schedule return bool on NAPI successful schedule

2023-10-03 Thread Eric Dumazet
On Mon, Oct 2, 2023 at 5:10 PM Christian Marangi  wrote:
>
> Change napi_schedule to return a bool on NAPI successful schedule. This
> might be useful for some driver to do additional step after a NAPI ahs

This might be useful for some drivers to do additional steps after a
NAPI has been scheduled.

> been scheduled.
>
> Signed-off-by: Christian Marangi 

Yeah, I guess you forgot to mention I suggested this patch ...

Reviewed-by: Eric Dumazet