Re: [RFC PATCH v12 02/33] KVM: Use gfn instead of hva for mmu_notifier_retry
On 2023-09-13 at 18:55:00 -0700, Sean Christopherson wrote:
> From: Chao Peng
>
> Currently in mmu_notifier invalidate path, hva range is recorded and
> then checked against by mmu_notifier_retry_hva() in the page fault
^
Now it is mmu_invalidate_retry_hva().
> handling path. However, for the to be introduced private memory, a page
> fault may not have a hva associated, checking gfn(gpa) makes more sense.
>
> For existing hva based shared memory, gfn is expected to also work. The
> only downside is when aliasing multiple gfns to a single hva, the
> current algorithm of checking multiple ranges could result in a much
> larger range being rejected. Such aliasing should be uncommon, so the
> impact is expected small.
>
> Suggested-by: Sean Christopherson
> Signed-off-by: Chao Peng
> Reviewed-by: Fuad Tabba
> Tested-by: Fuad Tabba
> [sean: convert vmx_set_apic_access_page_addr() to gfn-based API]
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/kvm/mmu/mmu.c | 10 ++
> arch/x86/kvm/vmx/vmx.c | 11 +--
> include/linux/kvm_host.h | 33 +
> virt/kvm/kvm_main.c | 40 +++-
> 4 files changed, 63 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index e1d011c67cc6..0f0231d2b74f 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -3056,7 +3056,7 @@ static void direct_pte_prefetch(struct kvm_vcpu *vcpu,
> u64 *sptep)
> *
> * There are several ways to safely use this helper:
> *
> - * - Check mmu_invalidate_retry_hva() after grabbing the mapping level,
> before
> + * - Check mmu_invalidate_retry_gfn() after grabbing the mapping level,
> before
> * consuming it. In this case, mmu_lock doesn't need to be held during the
> * lookup, but it does need to be held while checking the MMU notifier.
> *
> @@ -4358,7 +4358,7 @@ static bool is_page_fault_stale(struct kvm_vcpu *vcpu,
> return true;
>
> return fault->slot &&
> -mmu_invalidate_retry_hva(vcpu->kvm, fault->mmu_seq, fault->hva);
> +mmu_invalidate_retry_gfn(vcpu->kvm, fault->mmu_seq, fault->gfn);
> }
>
> static int direct_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault
> *fault)
> @@ -6253,7 +6253,9 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t
> gfn_start, gfn_t gfn_end)
>
> write_lock(&kvm->mmu_lock);
>
> - kvm_mmu_invalidate_begin(kvm, 0, -1ul);
> + kvm_mmu_invalidate_begin(kvm);
> +
> + kvm_mmu_invalidate_range_add(kvm, gfn_start, gfn_end);
>
> flush = kvm_rmap_zap_gfn_range(kvm, gfn_start, gfn_end);
>
> @@ -6266,7 +6268,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t
> gfn_start, gfn_t gfn_end)
> if (flush)
> kvm_flush_remote_tlbs_range(kvm, gfn_start, gfn_end -
> gfn_start);
>
> - kvm_mmu_invalidate_end(kvm, 0, -1ul);
> + kvm_mmu_invalidate_end(kvm);
>
> write_unlock(&kvm->mmu_lock);
> }
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 72e3943f3693..6e502ba93141 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6757,10 +6757,10 @@ static void vmx_set_apic_access_page_addr(struct
> kvm_vcpu *vcpu)
> return;
>
> /*
> - * Grab the memslot so that the hva lookup for the mmu_notifier retry
> - * is guaranteed to use the same memslot as the pfn lookup, i.e. rely
> - * on the pfn lookup's validation of the memslot to ensure a valid hva
> - * is used for the retry check.
> + * Explicitly grab the memslot using KVM's internal slot ID to ensure
> + * KVM doesn't unintentionally grab a userspace memslot. It _should_
> + * be impossible for userspace to create a memslot for the APIC when
> + * APICv is enabled, but paranoia won't hurt in this case.
>*/
> slot = id_to_memslot(slots, APIC_ACCESS_PAGE_PRIVATE_MEMSLOT);
> if (!slot || slot->flags & KVM_MEMSLOT_INVALID)
> @@ -6785,8 +6785,7 @@ static void vmx_set_apic_access_page_addr(struct
> kvm_vcpu *vcpu)
> return;
>
> read_lock(&vcpu->kvm->mmu_lock);
> - if (mmu_invalidate_retry_hva(kvm, mmu_seq,
> - gfn_to_hva_memslot(slot, gfn))) {
> + if (mmu_invalidate_retry_gfn(kvm, mmu_seq, gfn)) {
> kvm_make_request(KVM_REQ_APIC_PAGE_RELOAD, vcpu);
> read_unlock(&vcpu->kvm->mmu_lock);
> goto out;
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index fb6c6109fdca..11d091688346 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -787,8 +787,8 @@ struct kvm {
> struct mmu_notifier mmu_notifier;
> unsigned long mmu_invalidate_seq;
> long mmu_invalidate_in_progress;
> - unsigned long mmu_invalidate_range_start;
> - unsigned long mmu_invalidate_range_end;
> + gfn_t mmu_invalid
[PATCH 00/59] dma: Convert to platform remove callback returning void
Hello,
this series convert nearly all platform drivers below drivers/dma to use
.remove_new(). The motivation is to get rid of an integer return code
that is (mostly) ignored by the platform driver core and error prone on
the driver side.
See commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value") for an extended explanation and the eventual goal.
There are 4 drivers I didn't convert in this series:
drivers/dma/milbeaut-hdmac.c
drivers/dma/milbeaut-xdmac.c
drivers/dma/uniphier-mdmac.c
drivers/dma/uniphier-xdmac.c
These all might return early in .remove() if dmaengine_terminate_sync()
fails. I only looked deeper into the first one, and this shows exactly
the error that is easy to make with .remove() returning an int: When
returning early from .remove(), some cleanup (here:
dma_async_device_unregister()) is skipped. So the dma device stays
known, but the device is still unregistered and the devm allocated stuff
(here e.g. *mdev) is freed. So it can probably easily happen, that
something tries to use the dma device and this will likely result in an
oops.
I don't know enough about the dma framework to address this properly,
maybe someone else knows what to do?
There are no interdependencies between the patches. As there are still
quite a few drivers to convert, I'm happy about every patch that makes
it in. So even if there is a merge conflict with one patch until you
apply or I picked a wrong subject prefix, please apply the remainder of
this series anyhow.
Best regards
Uwe
Uwe Kleine-König (59):
dma: altera-msgdma: Convert to platform remove callback returning void
dma: apple-admac: Convert to platform remove callback returning void
dma: at_hdmac: Convert to platform remove callback returning void
dma: at_xdmac: Convert to platform remove callback returning void
dma: bcm-sba-raid: Convert to platform remove callback returning void
dma: bcm2835-dma: Convert to platform remove callback returning void
dma: bestcomm: bestcomm: Convert to platform remove callback returning
void
dma: dma-axi-dmac: Convert to platform remove callback returning void
dma: dma-jz4780: Convert to platform remove callback returning void
dma: dw-axi-dmac: dw-axi-dmac-platform: Convert to platform remove
callback returning void
dma: dw: platform: Convert to platform remove callback returning void
dma: fsl-edma-main: Convert to platform remove callback returning void
dma: fsl-qdma: Convert to platform remove callback returning void
dma: fsl_raid: Convert to platform remove callback returning void
dma: fsldma: Convert to platform remove callback returning void
dma: idma64: Convert to platform remove callback returning void
dma: img-mdc-dma: Convert to platform remove callback returning void
dma: imx-dma: Convert to platform remove callback returning void
dma: imx-sdma: Convert to platform remove callback returning void
dma: k3dma: Convert to platform remove callback returning void
dma: mcf-edma-main: Convert to platform remove callback returning void
dma: mediatek: mtk-cqdma: Convert to platform remove callback
returning void
dma: mediatek: mtk-hsdma: Convert to platform remove callback
returning void
dma: mediatek: mtk-uart-apdma: Convert to platform remove callback
returning void
dma: mmp_pdma: Convert to platform remove callback returning void
dma: mmp_tdma: Convert to platform remove callback returning void
dma: moxart-dma: Convert to platform remove callback returning void
dma: mpc512x_dma: Convert to platform remove callback returning void
dma: mv_xor_v2: Convert to platform remove callback returning void
dma: nbpfaxi: Convert to platform remove callback returning void
dma: owl-dma: Convert to platform remove callback returning void
dma: ppc4xx: adma: Convert to platform remove callback returning void
dma: pxa_dma: Convert to platform remove callback returning void
dma: qcom: bam_dma: Convert to platform remove callback returning void
dma: qcom: hidma: Convert to platform remove callback returning void
dma: qcom: qcom_adm: Convert to platform remove callback returning
void
dma: sa11x0-dma: Convert to platform remove callback returning void
dma: sf-pdma: sf-pdma: Convert to platform remove callback returning
void
dma: sh: rcar-dmac: Convert to platform remove callback returning void
dma: sh: rz-dmac: Convert to platform remove callback returning void
dma: sh: shdmac: Convert to platform remove callback returning void
dma: sh: usb-dmac: Convert to platform remove callback returning void
dma: sprd-dma: Convert to platform remove callback returning void
dma: st_fdma: Convert to platform remove callback returning void
dma: sun4i-dma: Convert to platform remove callback returning void
dma: sun6i-dma: Convert to platform remove callback returning void
dma: tegra186-gpc-dma: Convert to platform remove callback returning
void
dma: tegra20-apb-dma: Conv
Re: [PATCH v10 13/15] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler
Hi Dan, On 8/31/23 15:35, Dan Williams wrote: > Terry Bowman wrote: >> From: Robert Richter >> >> In Restricted CXL Device (RCD) mode a CXL device is exposed as an >> RCiEP, but CXL downstream and upstream ports are not enumerated and >> not visible in the PCIe hierarchy. [1] Protocol and link errors from >> these non-enumerated ports are signaled as internal AER errors, either >> Uncorrectable Internal Error (UIE) or Corrected Internal Errors (CIE) >> via an RCEC. >> >> Restricted CXL host (RCH) downstream port-detected errors have the >> Requester ID of the RCEC set in the RCEC's AER Error Source ID >> register. A CXL handler must then inspect the error status in various >> CXL registers residing in the dport's component register space (CXL >> RAS capability) or the dport's RCRB (PCIe AER extended >> capability). [2] >> >> Errors showing up in the RCEC's error handler must be handled and >> connected to the CXL subsystem. Implement this by forwarding the error >> to all CXL devices below the RCEC. Since the entire CXL device is >> controlled only using PCIe Configuration Space of device 0, function >> 0, only pass it there [3]. The error handling is limited to currently >> supported devices with the Memory Device class code set (CXL Type 3 >> Device, PCI_CLASS_MEMORY_CXL, 502h), handle downstream port errors in >> the device's cxl_pci driver. Support for other CXL Device Types >> (e.g. a CXL.cache Device) can be added later. >> >> To handle downstream port errors in addition to errors directed to the >> CXL endpoint device, a handler must also inspect the CXL RAS and PCIe >> AER capabilities of the CXL downstream port the device is connected >> to. >> >> Since CXL downstream port errors are signaled using internal errors, >> the handler requires those errors to be unmasked. This is subject of a >> follow-on patch. >> >> The reason for choosing this implementation is that the AER service >> driver claims the RCEC device, but does not allow it to register a >> custom specific handler to support CXL. Connecting the RCEC hard-wired >> with a CXL handler does not work, as the CXL subsystem might not be >> present all the time. The alternative to add an implementation to the >> portdrv to allow the registration of a custom RCEC error handler isn't >> worth doing it as CXL would be its only user. Instead, just check for >> an CXL RCEC and pass it down to the connected CXL device's error >> handler. With this approach the code can entirely be implemented in >> the PCIe AER driver and is independent of the CXL subsystem. The CXL >> driver only provides the handler. >> >> [1] CXL 3.0 spec: 9.11.8 CXL Devices Attached to an RCH >> [2] CXL 3.0 spec, 12.2.1.1 RCH Downstream Port-detected Errors >> [3] CXL 3.0 spec, 8.1.3 PCIe DVSEC for CXL Devices >> >> Co-developed-by: Terry Bowman >> Signed-off-by: Terry Bowman >> Signed-off-by: Robert Richter >> Cc: "Oliver O'Halloran" >> Cc: Bjorn Helgaas >> Cc: linuxppc-dev@lists.ozlabs.org >> Cc: linux-...@vger.kernel.org >> Acked-by: Bjorn Helgaas >> Reviewed-by: Jonathan Cameron >> Reviewed-by: Dave Jiang >> --- >> drivers/pci/pcie/Kconfig | 12 + >> drivers/pci/pcie/aer.c | 96 +++- >> 2 files changed, 106 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig >> index 228652a59f27..4f0e70fafe2d 100644 >> --- a/drivers/pci/pcie/Kconfig >> +++ b/drivers/pci/pcie/Kconfig >> @@ -49,6 +49,18 @@ config PCIEAER_INJECT >>gotten from: >> >> https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/ >> >> +config PCIEAER_CXL >> +bool "PCI Express CXL RAS support for Restricted Hosts (RCH)" > > Why the "for Restricted Hosts (RCH)" clarification? I am seeing nothing > that prevents this from working with RCECs on VH topologies. > The same option can be used in VH mode. Will remove the RCH reference. > >> +default y > > Minor, but I think "default PCIEAER" makes it slightly clearer that CXL > error handling comes along for the ride with PCIE AER. > We found Kconfig entries do not typically list a dependancy and the default to be the same. We prefer to leave as 'default y'. If you want we can make your requested change. >> +depends on PCIEAER && CXL_PCI >> +help >> + Enables error handling of downstream ports of a CXL host >> + that is operating in RCD mode (Restricted CXL Host, RCH). >> + The downstream port reports AER errors to a given RCEC. >> + Errors are handled by the CXL memory device driver. >> + >> + If unsure, say Y. >> + >> # >> # PCI Express ECRC >> # >> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c >> index d3344fcf1f79..c354ca5e8f2b 100644 >> --- a/drivers/pci/pcie/aer.c >> +++ b/drivers/pci/pcie/aer.c >> @@ -946,14 +946,100 @@ static bool find_source_device(struct pci_dev *parent, >> return true; >> } >> >> +#ifdef CONFIG_PCIEAER_CXL >> + >> +static bool is_cxl_mem_
Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
Hi Geert,
On Tue, Sep 19, 2023 at 12:02, Geert Uytterhoeven wrote:
>
> Hi Peter,
>
> On Tue, Sep 19, 2023 at 5:58 PM Peter Lafreniere pe...@n8pjl.ca wrote:
>
> > 2) Stops building an obsolete and largely-unused filesystem unnecessarily.
> > Some hobbyist targets like m68k and alpha may prefer to keep all filesystems
> > available until total removal, but others like arm and UML have no need for
> > ReiserFS to be built unless specifically configured.
>
>
> As UML is used a lot for testing, isn't it actually counter-productive
> to remove ReiserFS from the UML defconfig? The less testing it
> receives, the higher the chance of introducing regressions.
UML is used for testing, but in my view that makes the inclusion of
ReiserFS in its defconfig even worse. Users of UML are trying to test a
particular function, and so tend to use ext[2-4], as those are included in
the defconfig and are well tested and stable. So there is no extra testing
being done on ReiserFS due to its inclusion in the defconfig.
Keeping UML's defconfig as slim as possible improves build times, which is
particularly important for kernel testing and development.
>
> Gr{oetje,eeting}s,
>
> Geert
>
Cheers,
Peter Lafreniere
Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
Hi Peter,
On Tue, Sep 19, 2023 at 5:58 PM Peter Lafreniere wrote:
> 2) Stops building an obsolete and largely-unused filesystem unnecessarily.
> Some hobbyist targets like m68k and alpha may prefer to keep all
> filesystems
> available until total removal, but others like arm and UML have no need
> for
> ReiserFS to be built unless specifically configured.
As UML is used a lot for testing, isn't it actually counter-productive
to remove ReiserFS from the UML defconfig? The less testing it
receives, the higher the chance of introducing regressions.
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 0/7] arch/*: config: Remove ReiserFS from defconfig
On Tue, Sep 19, 2023 at 11:16, Segher Boessenkool wrote:
>
> On Tue, Sep 19, 2023 at 12:00:34AM +, Peter Lafreniere wrote:
>
> > On Monday, September 18th, 2023 at 19:41, Segher Boessenkool
> > seg...@kernel.crashing.org wrote:
> >
> > > On Mon, Sep 18, 2023 at 05:56:09PM +, Peter Lafreniere wrote:
> > >
> > > > ReiserFS has been considered deprecated for 19 months since commit
> > > > eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are
> > > > several architectures that still build it into their defconfig kernels.
> > > >
> > > > As ReiserFS will be removed in 2025, delete all ReiserFS-related options
> > > > from defconfig files before the filesystem's removal.
> > >
> > > This is essentially equivalent to deleting the filesystem now. Why do
> > > this? Is there such a hurry?
> >
> > This is not equivalent to deleting the filesystem. The filesystem can still
> > be configured into kernels, and few distros use a defconfig kernel anyway.
>
>
> Most people who compile kernels use defconfigs though. Distros are a
> tiny minority if you look at builds.
>
> Again: why do you want this?
>
Because the filesystem is deprecated and rarely used. Those who do use ReiserFS
should migrate away from it or get ready to stop upgrading their kernels soon.
This removal from defconfig:
1) Serves as a reminder to those that use the fs that they should take the
above actions, but with the filesystem staying available should they need
it.
2) Stops building an obsolete and largely-unused filesystem unnecessarily.
Some hobbyist targets like m68k and alpha may prefer to keep all filesystems
available until total removal, but others like arm and UML have no need for
ReiserFS to be built unless specifically configured.
3) Arguably simplifies the removal of the filesystem when that takes place.
This point is admittedly quite weak.
4) Has to happen someday, unless someone steps up and volunteers to maintain
the fs. I don't find it worthwhile, but you can if you'd like. Perhaps work
towards removal will cause a user to step forward and keep their beloved
filesystem around?
5) Doesn't actually remove support for the filesystem whatsoever. I can't
emphasize this enough: users who build their own kernel and maintain a
niche filesystem like ReiserFS should know how to flip a Kconfig switch.
>
> Segher
Cheers,
Peter
Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
On Tue, Sep 19, 2023 at 12:00:34AM +, Peter Lafreniere wrote:
> On Monday, September 18th, 2023 at 19:41, Segher Boessenkool
> wrote:
> > On Mon, Sep 18, 2023 at 05:56:09PM +, Peter Lafreniere wrote:
> >
> > > ReiserFS has been considered deprecated for 19 months since commit
> > > eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are
> > > several architectures that still build it into their defconfig kernels.
> > >
> > > As ReiserFS will be removed in 2025, delete all ReiserFS-related options
> > > from defconfig files before the filesystem's removal.
> >
> >
> > This is essentially equivalent to deleting the filesystem now. Why do
> > this? Is there such a hurry?
>
> This is not equivalent to deleting the filesystem. The filesystem can still
> be configured into kernels, and few distros use a defconfig kernel anyway.
Most people who compile kernels use defconfigs though. Distros are a
tiny minority if you look at builds.
Again: why do you want this?
Segher
[PATCH v5] drivers/net: process the result of hdlc_open() and add call of hdlc_close() in uhdlc_close()
Process the result of hdlc_open() and call uhdlc_close()
in case of an error. It is necessary to pass the error
code up the control flow, similar to a possible
error in request_irq().
Also add a hdlc_close() call to the uhdlc_close()
because the comment to hdlc_close() says it must be called
by the hardware driver when the HDLC device is being closed
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
Signed-off-by: Alexandra Diupina
---
v5: do some refactoring as Paolo Abeni and
Christophe Leroy suggested
v4: undo all the things done prior to hdlc_open() as
Jakub Kicinski suggested,
add hdlc_close() call to the uhdlc_close() to match the function comment,
add uhdlc_close() declaration to the top of the file not to put the
uhdlc_close() function definition before uhdlc_open()
v3: Fix the commits tree
v2: Remove the 'rc' variable (stores the return value of the
hdlc_open()) as Christophe Leroy suggested
drivers/net/wan/fsl_ucc_hdlc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 47c2ad7a3e42..fd50bb313b92 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -34,6 +34,8 @@
#define TDM_PPPOHT_SLIC_MAXIN
#define RX_BD_ERRORS (R_CD_S | R_OV_S | R_CR_S | R_AB_S | R_NO_S | R_LG_S)
+static int uhdlc_close(struct net_device *dev);
+
static struct ucc_tdm_info utdm_primary_info = {
.uf_info = {
.tsa = 0,
@@ -708,6 +710,7 @@ static int uhdlc_open(struct net_device *dev)
hdlc_device *hdlc = dev_to_hdlc(dev);
struct ucc_hdlc_private *priv = hdlc->priv;
struct ucc_tdm *utdm = priv->utdm;
+ int rc = 0;
if (priv->hdlc_busy != 1) {
if (request_irq(priv->ut_info->uf_info.irq,
@@ -731,10 +734,13 @@ static int uhdlc_open(struct net_device *dev)
napi_enable(&priv->napi);
netdev_reset_queue(dev);
netif_start_queue(dev);
- hdlc_open(dev);
+
+ rc = hdlc_open(dev);
+ if (rc)
+ uhdlc_close(dev);
}
- return 0;
+ return rc;
}
static void uhdlc_memclean(struct ucc_hdlc_private *priv)
@@ -824,6 +830,8 @@ static int uhdlc_close(struct net_device *dev)
netdev_reset_queue(dev);
priv->hdlc_busy = 0;
+ hdlc_close(dev);
+
return 0;
}
--
2.30.2
[PATCH 15/59] dma: fsldma: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/dma/fsldma.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index ddcf736d283d..18a6c4bf6275 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1306,7 +1306,7 @@ static int fsldma_of_probe(struct platform_device *op)
return err;
}
-static int fsldma_of_remove(struct platform_device *op)
+static void fsldma_of_remove(struct platform_device *op)
{
struct fsldma_device *fdev;
unsigned int i;
@@ -1324,8 +1324,6 @@ static int fsldma_of_remove(struct platform_device *op)
iounmap(fdev->regs);
kfree(fdev);
-
- return 0;
}
#ifdef CONFIG_PM
@@ -1406,7 +1404,7 @@ static struct platform_driver fsldma_of_driver = {
#endif
},
.probe = fsldma_of_probe,
- .remove = fsldma_of_remove,
+ .remove_new = fsldma_of_remove,
};
/**/
--
2.40.1
Re: [RFC PATCH v3 6/9] media: v4l2: Add audio capture and output support
Hi Shengjiu,
On Tue, Sep 19, 2023 at 06:31:09PM +0800, Shengjiu Wang wrote:
...
> > > +*
> > > +V4L2_AUDIO_FMT_LPCM ('LPCM')
> > > +*
Something to fix here, too...?
> > > +
> > > +Linear Pulse-Code Modulation (LPCM)
> > > +
> > > +
> > > +Description
> > > +===
> > > +
> > > +This describes audio format used by the audio memory to memory driver.
> > > +
> > > +It contains the following fields:
> > > +
> > > +.. flat-table::
> > > +:widths: 1 4
> > > +:header-rows: 1
> > > +:stub-columns: 0
> > > +
> > > +* - Field
> > > + - Description
> > > +* - u32 samplerate;
> > > + - which is the number of times per second that samples are taken.
> > > +* - u32 sampleformat;
> > > + - which determines the number of possible digital values that can
> > > be used to represent each sample
> >
> > 80 characters (or less) per line, please.
>
> Ok, will change it.
>
> >
> > Which values could this field have and what do they signify?
>
> The values are SNDRV_PCM_FORMAT_S8, SNDRV_PCM_FORMAT_U8...
> which are the PCM format, defined in ALSA.
I suppose this is documented in ALSA documentation. Could you refer to
that?
>
> >
> > > +* - u32 channels;
> > > + - channel number for each sample.
> >
> > I suppose the rest of the buffer would be samples? This should be
> > documented. I think there are also different ways the data could be
> > arrangeed and this needs to be documented, too.
>
> All data in the buffer are the samples, the 'samplerate', 'sampleformat'
> 'channels' I list here is try to describe the samples.
> I was confused how to write this document, so I list the characters.
The layout of this data in memory needs to be documented. I think a
reference to ALSA documentation would be the best.
--
Regards,
Sakari Ailus
Re: [PATCH v8 23/24] iommu: Convert simple drivers with DOMAIN_DMA to domain_alloc_paging()
On Wed, 2023-09-13 at 10:43 -0300, Jason Gunthorpe wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > These drivers are all trivially converted since the function is only > called if the domain type is going to be > IOMMU_DOMAIN_UNMANAGED/DMA. > > Tested-by: Heiko Stuebner > Tested-by: Steven Price > Tested-by: Marek Szyprowski > Tested-by: Nicolin Chen > Reviewed-by: Lu Baolu > Reviewed-by: Jerry Snitselaar > Signed-off-by: Jason Gunthorpe > --- > drivers/iommu/arm/arm-smmu/qcom_iommu.c | 6 ++ > drivers/iommu/exynos-iommu.c| 7 ++- > drivers/iommu/ipmmu-vmsa.c | 7 ++- > drivers/iommu/mtk_iommu.c | 7 ++- > drivers/iommu/rockchip-iommu.c | 7 ++- > drivers/iommu/sprd-iommu.c | 7 ++- > drivers/iommu/sun50i-iommu.c| 9 +++-- > drivers/iommu/tegra-smmu.c | 7 ++- > 8 files changed, 17 insertions(+), 40 deletions(-) > Tested-by: Yong Wu #For mtk_iommu.c Thanks.
Re: [PATCH v2] hwmon: (ibmpowernv) refactor deprecated strncpy
Justin Stitt writes:
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
>
> A suitable replacement is `memcpy` as we've already precisely calculated
> the number of bytes to copy while `buf` has been explicitly
> zero-initialized:
> | char buf[8] = { 0 };
>
> Link:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> [1]
> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
> [2]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kernel.org
> Signed-off-by: Justin Stitt
> ---
> Changes in v2:
> - prefer memcpy to strscpy (thanks Kees)
> - Link to v1:
> https://lore.kernel.org/r/20230914-strncpy-drivers-hwmon-ibmpowernv-c-v1-1-ba6b7f42c...@google.com
> ---
> drivers/hwmon/ibmpowernv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Tested-by: Michael Ellerman
Acked-by: Michael Ellerman (powerpc)
cheers
Re: [RFC PATCH v3 6/9] media: v4l2: Add audio capture and output support
On Thu, Sep 14, 2023 at 6:17 PM Sakari Ailus wrote: > > Hi Shenjiu, > > Thanks for the update. > > On Thu, Sep 14, 2023 at 01:54:02PM +0800, Shengjiu Wang wrote: > > Audio signal processing has the requirement for memory to > > memory similar as Video. > > > > This patch is to add this support in v4l2 framework, defined > > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and > > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format > > for audio case usage. > > > > Defined V4L2_AUDIO_FMT_LPCM format type for audio. > > This would be nicer as a separate patch. Also see the related comments > below. OK, will separate it. > > > > > Defined V4L2_CAP_AUDIO_M2M capability type for audio memory > > to memory case. > > > > The created audio device is named "/dev/v4l-audioX". > > > > Signed-off-by: Shengjiu Wang > > --- > > .../userspace-api/media/v4l/audio-formats.rst | 15 + > > .../userspace-api/media/v4l/buffer.rst| 6 ++ > > .../userspace-api/media/v4l/dev-audio.rst | 63 +++ > > .../userspace-api/media/v4l/devices.rst | 1 + > > .../media/v4l/pixfmt-aud-lpcm.rst | 31 + > > .../userspace-api/media/v4l/pixfmt.rst| 1 + > > .../media/v4l/vidioc-enum-fmt.rst | 2 + > > .../userspace-api/media/v4l/vidioc-g-fmt.rst | 4 ++ > > .../media/v4l/vidioc-querycap.rst | 3 + > > .../media/videodev2.h.rst.exceptions | 2 + > > .../media/common/videobuf2/videobuf2-v4l2.c | 4 ++ > > drivers/media/v4l2-core/v4l2-dev.c| 17 + > > drivers/media/v4l2-core/v4l2-ioctl.c | 53 > > include/media/v4l2-dev.h | 2 + > > include/media/v4l2-ioctl.h| 34 ++ > > include/uapi/linux/videodev2.h| 25 > > 16 files changed, 263 insertions(+) > > create mode 100644 Documentation/userspace-api/media/v4l/audio-formats.rst > > create mode 100644 Documentation/userspace-api/media/v4l/dev-audio.rst > > create mode 100644 > > Documentation/userspace-api/media/v4l/pixfmt-aud-lpcm.rst > > > > diff --git a/Documentation/userspace-api/media/v4l/audio-formats.rst > > b/Documentation/userspace-api/media/v4l/audio-formats.rst > > new file mode 100644 > > index ..bc52712d20d3 > > --- /dev/null > > +++ b/Documentation/userspace-api/media/v4l/audio-formats.rst > > @@ -0,0 +1,15 @@ > > +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later > > + > > +.. _audio-formats: > > + > > +* > > +Audio Formats > > +* > > + > > +These formats are used for :ref:`audio` interface only. > > + > > + > > +.. toctree:: > > +:maxdepth: 1 > > + > > +pixfmt-aud-lpcm > > diff --git a/Documentation/userspace-api/media/v4l/buffer.rst > > b/Documentation/userspace-api/media/v4l/buffer.rst > > index 04dec3e570ed..80cf2cb20dfe 100644 > > --- a/Documentation/userspace-api/media/v4l/buffer.rst > > +++ b/Documentation/userspace-api/media/v4l/buffer.rst > > @@ -438,6 +438,12 @@ enum v4l2_buf_type > > * - ``V4L2_BUF_TYPE_META_OUTPUT`` > >- 14 > >- Buffer for metadata output, see :ref:`metadata`. > > +* - ``V4L2_BUF_TYPE_AUDIO_CAPTURE`` > > + - 15 > > + - Buffer for audio capture, see :ref:`audio`. > > +* - ``V4L2_BUF_TYPE_AUDIO_OUTPUT`` > > + - 16 > > + - Buffer for audio output, see :ref:`audio`. > > > > > > .. _buffer-flags: > > diff --git a/Documentation/userspace-api/media/v4l/dev-audio.rst > > b/Documentation/userspace-api/media/v4l/dev-audio.rst > > new file mode 100644 > > index ..f9bcf0c7b056 > > --- /dev/null > > +++ b/Documentation/userspace-api/media/v4l/dev-audio.rst > > @@ -0,0 +1,63 @@ > > +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later > > + > > +.. _audiodev: > > + > > +** > > +audio Interface > > Capital "A"? OK, will modify it. > > > +** > > Too many asterisks (same a few lines above, too). ok, will update it. > > > + > > +The audio interface is implemented on audio device nodes. The audio device > > +which uses application software for modulation or demodulation. This > > +interface is intended for controlling and data streaming of such devices > > + > > +Audio devices are accessed through character device special files named > > +``/dev/v4l-audio`` > > + > > +Querying Capabilities > > += > > + > > +Device nodes supporting the audio capture and output interface set the > > +``V4L2_CAP_AUDIO_M2M`` flag in the ``device_caps`` field of the > > +:c:type:`v4l2_capability` structure returned by the > > :c:func:`VIDIOC_QUERYCAP` > > +ioctl. > > + > > +At least one of the read/write or streaming I/O methods must be supported. > > + > > + > > +Data Format Negotiation > > +=== > > + > > +The audio device uses the :ref:`format` ioctls to select the capture > > format. > > +The audio buffer content format is bound to that selected format. In
[PATCH] ASoC: fsl_sai: Don't disable bitclock for i.MX8MP
On i.MX8MP, the BCE and TERE bit are binding with mclk
enablement, if BCE and TERE are cleared the MCLK also be
disabled on output pin, that cause the external codec (wm8960)
in wrong state.
Codec (wm8960) is using the mclk to generate PLL clock,
if mclk is disabled before disabling PLL, the codec (wm8960)
won't generate bclk and frameclk when sysclk switch to
MCLK source in next test case.
The test case:
$aplay -r44100 test1.wav (PLL source)
$aplay -r48000 test2.wav (MCLK source)
aplay: pcm_write:2127: write error: Input/output error
Fixes: 269f399dc19f ("ASoC: fsl_sai: Disable bit clock with transmitter")
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_sai.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 1e4020fae05a..8a9a30dd31e2 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -710,10 +710,15 @@ static void fsl_sai_config_disable(struct fsl_sai *sai,
int dir)
{
unsigned int ofs = sai->soc_data->reg_offset;
bool tx = dir == TX;
- u32 xcsr, count = 100;
+ u32 xcsr, count = 100, mask;
+
+ if (sai->soc_data->mclk_with_tere && sai->mclk_direction_output)
+ mask = FSL_SAI_CSR_TERE;
+ else
+ mask = FSL_SAI_CSR_TERE | FSL_SAI_CSR_BCE;
regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx, ofs),
- FSL_SAI_CSR_TERE | FSL_SAI_CSR_BCE, 0);
+ mask, 0);
/* TERE will remain set till the end of current frame */
do {
--
2.34.1
Re: [PATCH] powerpc: add `cur_cpu_spec` symbol to vmcoreinfo
Aditya Gupta writes: > On Thu, Sep 14, 2023 at 11:22:01PM +1000, Michael Ellerman wrote: >> Aditya Gupta writes: >> > Presently, while reading a vmcore, makedumpfile uses >> > `cur_cpu_spec.mmu_features` to decide whether the crashed system had >> > RADIX MMU or not. >> > >> > Currently, makedumpfile fails to get the `cur_cpu_spec` symbol (unless >> > a vmlinux is passed with the `-x` flag to makedumpfile), and hence >> > assigns offsets and shifts (such as pgd_offset_l4) incorrecly considering >> > MMU to be hash MMU. >> > >> > Add `cur_cpu_spec` symbol and offset of `mmu_features` in the >> > `cpu_spec` struct, to VMCOREINFO, so that the symbol address and offset >> > is accessible to makedumpfile, without needing the vmlinux file >> >> This looks fine. >> >> Seems like cpu_features would be needed or at least pretty useful too? >> >> cheers > > Sure, that can be added too, to the vmcoreinfo. Not sure if it's used now, but > sure it can help to identify features in makedumpfile. > > Will add it, in next version. Please do it in a separate commit to the mmu_features :) cheers
Re: [PATCH v2 2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX
Geert Uytterhoeven writes: > Hi Michael, > > On Tue, Sep 19, 2023 at 4:13 AM Michael Ellerman wrote: >> Geert Uytterhoeven writes: >> > Upstream Linux never had a "README.legal" file, but it was present >> > in early source releases of Linux/m68k. It contained a simple copyright >> > notice and a link to a version of the "COPYING" file that predated the >> > addition of the "only valid GPL version is v2" clause. >> > >> > Get rid of the references to non-existent files by replacing the >> > boilerplate with SPDX license identifiers. >> > >> > Signed-off-by: Geert Uytterhoeven >> >> LGTM. >> >> Acked-by: Michael Ellerman (powerpc) > > Can you please take it through the PPC tree? Sure thing. cheers
Re: [PATCH] powerpc: add `cur_cpu_spec` symbol to vmcoreinfo
On Thu, Sep 14, 2023 at 11:22:01PM +1000, Michael Ellerman wrote: > Aditya Gupta writes: > > Presently, while reading a vmcore, makedumpfile uses > > `cur_cpu_spec.mmu_features` to decide whether the crashed system had > > RADIX MMU or not. > > > > Currently, makedumpfile fails to get the `cur_cpu_spec` symbol (unless > > a vmlinux is passed with the `-x` flag to makedumpfile), and hence > > assigns offsets and shifts (such as pgd_offset_l4) incorrecly considering > > MMU to be hash MMU. > > > > Add `cur_cpu_spec` symbol and offset of `mmu_features` in the > > `cpu_spec` struct, to VMCOREINFO, so that the symbol address and offset > > is accessible to makedumpfile, without needing the vmlinux file > > This looks fine. > > Seems like cpu_features would be needed or at least pretty useful too? > > cheers Sure, that can be added too, to the vmcoreinfo. Not sure if it's used now, but sure it can help to identify features in makedumpfile. Will add it, in next version. Thanks - Aditya Gupta
Re: [PATCH] powerpc: add `cur_cpu_spec` symbol to vmcoreinfo
Hello mpe, On Fri, Sep 15, 2023 at 11:16:08AM +1000, Michael Ellerman wrote: > Sachin Sant writes: > >> On 14-Sep-2023, at 6:52 PM, Michael Ellerman wrote: > >> > >> Sachin Sant writes: > On 11-Sep-2023, at 2:44 PM, Aditya Gupta wrote: > > Presently, while reading a vmcore, makedumpfile uses > `cur_cpu_spec.mmu_features` to decide whether the crashed system had > RADIX MMU or not. > > Currently, makedumpfile fails to get the `cur_cpu_spec` symbol (unless > a vmlinux is passed with the `-x` flag to makedumpfile), and hence > assigns offsets and shifts (such as pgd_offset_l4) incorrecly considering > MMU to be hash MMU. > > Add `cur_cpu_spec` symbol and offset of `mmu_features` in the > `cpu_spec` struct, to VMCOREINFO, so that the symbol address and offset > is accessible to makedumpfile, without needing the vmlinux file > > Signed-off-by: Aditya Gupta > --- > >>> > >>> Thanks for the patch. With this patch applied (along with makedumpfile > >>> changes) > >>> I am able to capture vmcore against a kernel which contains commit > >>> 8dc9a0ad0c3e > >> > >> I can't find that commit? Was just wondering if it should be referenced > >> in the commit message. > >> > > > > My bad, I copied that commit id from the email when I first reported this > > issue > > against linux-next. > > > > The commit should be > > 368a0590d954: (powerpc/book3s64/vmemmap: switch radix to use a > > different vmemmap handling function) > > OK thanks. > > Aditya, can you please rephrase the commit message to mention how that > commit broke the previous behaviour. Offsets were being wrongly assigned, in makedumpfile, in Radix MMU case (unless -x vmlinux was passed to makedumpfile, which generally isn't the case) That was happening even before the '368a0590d954' commit mentioned, it's just that we hit the issue now, since with above commit, we needed to use those offsets for page traversal, in makedumpfile. And those offsets were incorrecly assigned, and hence page traversal failed. For the offsets/shifts to be correctly assigned in makedumpfile, `cur_cpu_spec.mmu_features` needs to be exported in VMCOREINFO by kernel. > > Also I don't know what pgd_offset_l4 is? Sure, I will try to explain with more context in commit description in next version, or directly mention the particular shifts that was wrong. In makedumpfile, it is the offset of pgdir from the kernel pgd, for a given virtual address It is same as what the `pgd_index` function returns, in the powerpc kernel source. > > cheers Thanks
Re: [RFC PATCH v12 14/33] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory
On 9/14/2023 9:55 AM, Sean Christopherson wrote:
[...]
+
+static void kvm_gmem_invalidate_begin(struct kvm_gmem *gmem, pgoff_t start,
+ pgoff_t end)
+{
+ struct kvm_memory_slot *slot;
+ struct kvm *kvm = gmem->kvm;
+ unsigned long index;
+ bool flush = false;
+
+ KVM_MMU_LOCK(kvm);
+
+ kvm_mmu_invalidate_begin(kvm);
+
+ xa_for_each_range(&gmem->bindings, index, slot, start, end - 1) {
+ pgoff_t pgoff = slot->gmem.pgoff;
+
+ struct kvm_gfn_range gfn_range = {
+ .start = slot->base_gfn + max(pgoff, start) - pgoff,
+ .end = slot->base_gfn + min(pgoff + slot->npages, end)
- pgoff,
+ .slot = slot,
+ .may_block = true,
+ };
+
+ flush |= kvm_mmu_unmap_gfn_range(kvm, &gfn_range);
+ }
+
+ if (flush)
+ kvm_flush_remote_tlbs(kvm);
+
+ KVM_MMU_UNLOCK(kvm);
+}
+
+static void kvm_gmem_invalidate_end(struct kvm_gmem *gmem, pgoff_t start,
+ pgoff_t end)
+{
+ struct kvm *kvm = gmem->kvm;
+
+ KVM_MMU_LOCK(kvm);
+ if (xa_find(&gmem->bindings, &start, end - 1, XA_PRESENT))
+ kvm_mmu_invalidate_end(kvm);
kvm_mmu_invalidate_begin() is called unconditionally in
kvm_gmem_invalidate_begin(),
but kvm_mmu_invalidate_end() is not here.
This makes the kvm_gmem_invalidate_{begin, end}() calls asymmetric.
+ KVM_MMU_UNLOCK(kvm);
+}
+
+static long kvm_gmem_punch_hole(struct inode *inode, loff_t offset, loff_t len)
+{
+ struct list_head *gmem_list = &inode->i_mapping->private_list;
+ pgoff_t start = offset >> PAGE_SHIFT;
+ pgoff_t end = (offset + len) >> PAGE_SHIFT;
+ struct kvm_gmem *gmem;
+
+ /*
+* Bindings must stable across invalidation to ensure the start+end
+* are balanced.
+*/
+ filemap_invalidate_lock(inode->i_mapping);
+
+ list_for_each_entry(gmem, gmem_list, entry) {
+ kvm_gmem_invalidate_begin(gmem, start, end);
+ kvm_gmem_invalidate_end(gmem, start, end);
+ }
Why to loop for each gmem in gmem_list here?
IIUIC, offset is the offset according to the inode, it is only
meaningful to the
inode passed in, i.e, it is only meaningful to the gmem binding with the
inode,
not others.
+
+ filemap_invalidate_unlock(inode->i_mapping);
+
+ return 0;
+}
+
[...]
