* [PATCH v14 02/12] dmaengine: qcom: bam_dma: convert tasklet to a BH workqueue
From: Bartosz Golaszewski @ 2026-03-23 15:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski,
Dmitry Baryshkov
In-Reply-To: <20260323-qcom-qce-cmd-descr-v14-0-f323af411274@oss.qualcomm.com>
BH workqueues are a modern mechanism, aiming to replace legacy tasklets.
Let's convert the BAM DMA driver to using the high-priority variant of
the BH workqueue.
[Vinod: suggested using the BG workqueue instead of the regular one
running in process context]
Suggested-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/dma/qcom/bam_dma.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 19116295f8325767a0d97a7848077885b118241c..c8601bac555edf1bb4384fd39cb3449ec6e86334 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -42,6 +42,7 @@
#include <linux/pm_runtime.h>
#include <linux/scatterlist.h>
#include <linux/slab.h>
+#include <linux/workqueue.h>
#include "../dmaengine.h"
#include "../virt-dma.h"
@@ -397,8 +398,8 @@ struct bam_device {
struct clk *bamclk;
int irq;
- /* dma start transaction tasklet */
- struct tasklet_struct task;
+ /* dma start transaction workqueue */
+ struct work_struct work;
};
/**
@@ -863,7 +864,7 @@ static u32 process_channel_irqs(struct bam_device *bdev)
/*
* if complete, process cookie. Otherwise
* push back to front of desc_issued so that
- * it gets restarted by the tasklet
+ * it gets restarted by the work queue.
*/
if (!async_desc->num_desc) {
vchan_cookie_complete(&async_desc->vd);
@@ -893,9 +894,9 @@ static irqreturn_t bam_dma_irq(int irq, void *data)
srcs |= process_channel_irqs(bdev);
- /* kick off tasklet to start next dma transfer */
+ /* kick off the work queue to start next dma transfer */
if (srcs & P_IRQ)
- tasklet_schedule(&bdev->task);
+ queue_work(system_bh_highpri_wq, &bdev->work);
ret = pm_runtime_get_sync(bdev->dev);
if (ret < 0)
@@ -1091,14 +1092,14 @@ static void bam_start_dma(struct bam_chan *bchan)
}
/**
- * dma_tasklet - DMA IRQ tasklet
- * @t: tasklet argument (bam controller structure)
+ * bam_dma_work() - DMA interrupt work queue callback
+ * @work: work queue struct embedded in the BAM controller device struct
*
* Sets up next DMA operation and then processes all completed transactions
*/
-static void dma_tasklet(struct tasklet_struct *t)
+static void bam_dma_work(struct work_struct *work)
{
- struct bam_device *bdev = from_tasklet(bdev, t, task);
+ struct bam_device *bdev = from_work(bdev, work, work);
struct bam_chan *bchan;
unsigned int i;
@@ -1111,14 +1112,13 @@ static void dma_tasklet(struct tasklet_struct *t)
if (!list_empty(&bchan->vc.desc_issued) && !IS_BUSY(bchan))
bam_start_dma(bchan);
}
-
}
/**
* bam_issue_pending - starts pending transactions
* @chan: dma channel
*
- * Calls tasklet directly which in turn starts any pending transactions
+ * Calls work queue directly which in turn starts any pending transactions
*/
static void bam_issue_pending(struct dma_chan *chan)
{
@@ -1286,14 +1286,14 @@ static int bam_dma_probe(struct platform_device *pdev)
if (ret)
goto err_disable_clk;
- tasklet_setup(&bdev->task, dma_tasklet);
+ INIT_WORK(&bdev->work, bam_dma_work);
bdev->channels = devm_kcalloc(bdev->dev, bdev->num_channels,
sizeof(*bdev->channels), GFP_KERNEL);
if (!bdev->channels) {
ret = -ENOMEM;
- goto err_tasklet_kill;
+ goto err_workqueue_cancel;
}
/* allocate and initialize channels */
@@ -1358,8 +1358,8 @@ static int bam_dma_probe(struct platform_device *pdev)
err_bam_channel_exit:
for (i = 0; i < bdev->num_channels; i++)
tasklet_kill(&bdev->channels[i].vc.task);
-err_tasklet_kill:
- tasklet_kill(&bdev->task);
+err_workqueue_cancel:
+ cancel_work_sync(&bdev->work);
err_disable_clk:
clk_disable_unprepare(bdev->bamclk);
@@ -1393,7 +1393,7 @@ static void bam_dma_remove(struct platform_device *pdev)
bdev->channels[i].fifo_phys);
}
- tasklet_kill(&bdev->task);
+ cancel_work_sync(&bdev->work);
clk_disable_unprepare(bdev->bamclk);
}
--
2.47.3
^ permalink raw reply related
* [PATCH v14 01/12] dmaengine: constify struct dma_descriptor_metadata_ops
From: Bartosz Golaszewski @ 2026-03-23 15:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260323-qcom-qce-cmd-descr-v14-0-f323af411274@oss.qualcomm.com>
There's no reason for the instances of this struct to be modifiable.
Constify the pointer in struct dma_async_tx_descriptor and all drivers
currently using it.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/dma/ti/k3-udma.c | 2 +-
drivers/dma/xilinx/xilinx_dma.c | 2 +-
include/linux/dmaengine.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index c964ebfcf3b68d86e4bbc9b62bad2212f0ce3ee9..8a2f235b669aaf084a6f7b3e6b23d06b04768608 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -3408,7 +3408,7 @@ static int udma_set_metadata_len(struct dma_async_tx_descriptor *desc,
return 0;
}
-static struct dma_descriptor_metadata_ops metadata_ops = {
+static const struct dma_descriptor_metadata_ops metadata_ops = {
.attach = udma_attach_metadata,
.get_ptr = udma_get_metadata_ptr,
.set_len = udma_set_metadata_len,
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index b53292e02448fe528f1ae9ba33b4bcf408f89fd6..97b934ca54101ea699e3ab28d419bed1b45dee4a 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -653,7 +653,7 @@ static void *xilinx_dma_get_metadata_ptr(struct dma_async_tx_descriptor *tx,
return seg->hw.app;
}
-static struct dma_descriptor_metadata_ops xilinx_dma_metadata_ops = {
+static const struct dma_descriptor_metadata_ops xilinx_dma_metadata_ops = {
.get_ptr = xilinx_dma_get_metadata_ptr,
};
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 99efe2b9b4ea9844ca6161208362ef18ef111d96..92566c4c100e98f48750de21249ae3b5de06c763 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -623,7 +623,7 @@ struct dma_async_tx_descriptor {
void *callback_param;
struct dmaengine_unmap_data *unmap;
enum dma_desc_metadata_mode desc_metadata_mode;
- struct dma_descriptor_metadata_ops *metadata_ops;
+ const struct dma_descriptor_metadata_ops *metadata_ops;
#ifdef CONFIG_ASYNC_TX_ENABLE_CHANNEL_SWITCH
struct dma_async_tx_descriptor *next;
struct dma_async_tx_descriptor *parent;
--
2.47.3
^ permalink raw reply related
* [PATCH v14 00/12] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
From: Bartosz Golaszewski @ 2026-03-23 15:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski,
Dmitry Baryshkov, Konrad Dybcio
This iteration is quite similar to v12 but uses the BAM's NWD bit on
data descriptors as suggested by Stephan. To that end, there are some
more changes like reversing the order of command and data descriptors
queuedy by the QCE driver.
Currently the QCE crypto driver accesses the crypto engine registers
directly via CPU. Trust Zone may perform crypto operations simultaneously
resulting in a race condition. To remedy that, let's introduce support
for BAM locking/unlocking to the driver. The BAM driver will now wrap
any existing issued descriptor chains with additional descriptors
performing the locking when the client starts the transaction
(dmaengine_issue_pending()). The client wanting to profit from locking
needs to switch to performing register I/O over DMA and communicate the
address to which to perform the dummy writes via a call to
dmaengine_desc_attach_metadata().
In the specific case of the BAM DMA this translates to sending command
descriptors performing dummy writes with the relevant flags set. The BAM
will then lock all other pipes not related to the current pipe group, and
keep handling the current pipe only until it sees the the unlock bit.
In order for the locking to work correctly, we also need to switch to
using DMA for all register I/O.
On top of this, the series contains some additional tweaks and
refactoring.
The goal of this is not to improve the performance but to prepare the
driver for supporting decryption into secure buffers in the future.
Tested with tcrypt.ko, kcapi and cryptsetup.
Shout out to Daniel and Udit from Qualcomm for helping me out with some
DMA issues we encountered.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v14:
- Don't return an error to a client which wants to use locking on BAM
that doesn't support it
- Add a comment describing the DMA descriptor metadata structure
- Fix memory leaks
- Remove leftovers from previous iterations
- Propagate errors from dma_cookie_assign() when setting up lock
descriptors
- Link to v13: https://patch.msgid.link/20260317-qcom-qce-cmd-descr-v13-0-0968eb4f8c40@oss.qualcomm.com
Changes in v13:
- As part of the DMA changes in the QCE driver: reverse the order of
queueing the descriptors in the QCE driver: queue command descriptors
with all the register writes first, followed by all the data descriptors,
this is in line with the recommandations from the BAM HPG
- Set the NWD (notify-when-done) bit (DMA_PREP_FENCE in dmaengine
parlance) on the data descriptors to ensure that the UNLOCK descriptor
will not be processed until after they have been processed by the
engine. While technically the NWD bit is only needed on the final data
descriptor, it's hard to tell which one *will* be the last from the
driver's point-of-view and both the downstream driver as well as
the Qualcomm TZ against which we want to synchronize sets NWD on every
data descriptor,
- Revert to creating the LOCK/UNLOCK command descriptor pair in one
place now that the NWD bit is in place,
- Link to v12: https://patch.msgid.link/20260310-qcom-qce-cmd-descr-v12-0-398f37f26ef0@oss.qualcomm.com
Changes in v12:
- Wait until the transaction is done before queueing the UNLOCK command
descriptor
- Use descriptor metadata for communicating the scratchpad address to
the BAM driver
- To that end: reverse the order of the series (first BAM, then QCE) to
maintain bisectability
- Unmap buffers used for dummy writes after the transaction
- Link to v11: https://patch.msgid.link/20260302-qcom-qce-cmd-descr-v11-0-4bf1f5db4802@oss.qualcomm.com
Changes in v11:
- Use new approach, not requiring the client to be involved in locking.
- Add a patch constifying dma_descriptor_metadata_ops
- Rebase on top of v7.0-rc1
- Link to v10: https://lore.kernel.org/r/20251219-qcom-qce-cmd-descr-v10-0-ff7e4bf7dad4@oss.qualcomm.com
Changes in v10:
- Move DESC_FLAG_(UN)LOCK BIT definitions from patch 2 to 3
- Add a patch constifying the dma engine metadata as the first in the
series
- Use the VERSION register for dummy lock/unlock writes
- Link to v9: https://lore.kernel.org/r/20251128-qcom-qce-cmd-descr-v9-0-9a5f72b89722@linaro.org
Changes in v9:
- Drop the global, generic LOCK/UNLOCK flags and instead use DMA
descriptor metadata ops to pass BAM-specific information from the QCE
to the DMA engine
- Link to v8: https://lore.kernel.org/r/20251106-qcom-qce-cmd-descr-v8-0-ecddca23ca26@linaro.org
Changes in v8:
- Rework the command descriptor logic and drop a lot of unneeded code
- Use the physical address for BAM command descriptor access, not the
mapped DMA address
- Fix the problems with iommu faults on newer platforms
- Generalize the LOCK/UNLOCK flags in dmaengine and reword the docs and
commit messages
- Make the BAM locking logic stricter in the DMA engine driver
- Add some additional minor QCE driver refactoring changes to the series
- Lots of small reworks and tweaks to rebase on current mainline and fix
previous issues
- Link to v7: https://lore.kernel.org/all/20250311-qce-cmd-descr-v7-0-db613f5d9c9f@linaro.org/
Changes in v7:
- remove unused code: writing to multiple registers was not used in v6,
neither were the functions for reading registers over BAM DMA-
- remove
- don't read the SW_VERSION register needlessly in the BAM driver,
instead: encode the information on whether the IP supports BAM locking
in device match data
- shrink code where possible with logic modifications (for instance:
change the implementation of qce_write() instead of replacing it
everywhere with a new symbol)
- remove duplicated error messages
- rework commit messages
- a lot of shuffling code around for easier review and a more
streamlined series
- Link to v6: https://lore.kernel.org/all/20250115103004.3350561-1-quic_mdalam@quicinc.com/
Changes in v6:
- change "BAM" to "DMA"
- Ensured this series is compilable with the current Linux-next tip of
the tree (TOT).
Changes in v5:
- Added DMA_PREP_LOCK and DMA_PREP_UNLOCK flag support in separate patch
- Removed DMA_PREP_LOCK & DMA_PREP_UNLOCK flag
- Added FIELD_GET and GENMASK macro to extract major and minor version
Changes in v4:
- Added feature description and test hardware
with test command
- Fixed patch version numbering
- Dropped dt-binding patch
- Dropped device tree changes
- Added BAM_SW_VERSION register read
- Handled the error path for the api dma_map_resource()
in probe
- updated the commit messages for batter redability
- Squash the change where qce_bam_acquire_lock() and
qce_bam_release_lock() api got introduce to the change where
the lock/unlock flag get introced
- changed cover letter subject heading to
"dmaengine: qcom: bam_dma: add cmd descriptor support"
- Added the very initial post for BAM lock/unlock patch link
as v1 to track this feature
Changes in v3:
- https://lore.kernel.org/lkml/183d4f5e-e00a-8ef6-a589-f5704bc83d4a@quicinc.com/
- Addressed all the comments from v2
- Added the dt-binding
- Fix alignment issue
- Removed type casting from qce_write_reg_dma()
and qce_read_reg_dma()
- Removed qce_bam_txn = dma->qce_bam_txn; line from
qce_alloc_bam_txn() api and directly returning
dma->qce_bam_txn
Changes in v2:
- https://lore.kernel.org/lkml/20231214114239.2635325-1-quic_mdalam@quicinc.com/
- Initial set of patches for cmd descriptor support
- Add client driver to use BAM lock/unlock feature
- Added register read/write via BAM in QCE Crypto driver
to use BAM lock/unlock feature
---
Bartosz Golaszewski (12):
dmaengine: constify struct dma_descriptor_metadata_ops
dmaengine: qcom: bam_dma: convert tasklet to a BH workqueue
dmaengine: qcom: bam_dma: Extend the driver's device match data
dmaengine: qcom: bam_dma: Add pipe_lock_supported flag support
dmaengine: qcom: bam_dma: add support for BAM locking
crypto: qce - Include algapi.h in the core.h header
crypto: qce - Remove unused ignore_buf
crypto: qce - Simplify arguments of devm_qce_dma_request()
crypto: qce - Use existing devres APIs in devm_qce_dma_request()
crypto: qce - Map crypto memory for DMA
crypto: qce - Add BAM DMA support for crypto register I/O
crypto: qce - Communicate the base physical address to the dmaengine
drivers/crypto/qce/aead.c | 8 +-
drivers/crypto/qce/common.c | 20 ++--
drivers/crypto/qce/core.c | 28 ++++-
drivers/crypto/qce/core.h | 11 ++
drivers/crypto/qce/dma.c | 163 +++++++++++++++++++++++-----
drivers/crypto/qce/dma.h | 11 +-
drivers/crypto/qce/sha.c | 8 +-
drivers/crypto/qce/skcipher.c | 8 +-
drivers/dma/qcom/bam_dma.c | 228 ++++++++++++++++++++++++++++++++++-----
drivers/dma/ti/k3-udma.c | 2 +-
drivers/dma/xilinx/xilinx_dma.c | 2 +-
include/linux/dma/qcom_bam_dma.h | 10 ++
include/linux/dmaengine.h | 2 +-
13 files changed, 413 insertions(+), 88 deletions(-)
---
base-commit: 38fb1b38c3086065ace8fd72471c452cfdb61d36
change-id: 20251103-qcom-qce-cmd-descr-c5e9b11fe609
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: hwmon: Document the LTC4283 Swap Controller
From: Nuno Sá @ 2026-03-23 15:17 UTC (permalink / raw)
To: Guenter Roeck, nuno.sa
Cc: linux-gpio, linux-hwmon, devicetree, linux-doc, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <453dbd6c-c68d-4977-8418-a898008b0fe7@roeck-us.net>
On Mon, 2026-03-23 at 07:33 -0700, Guenter Roeck wrote:
> [ ...]
> > > > + adi,pgio1-func:
> > > > + description: Configures the function of the PGIO1 pin.
> > > > + $ref: /schemas/types.yaml#/definitions/string
> > > > + enum: [inverted_power_good, power_good, gpio]
> > > > + default: inverted_power_good
> > > > +
> > > > + adi,pgio2-func:
> > > > + description: Configures the function of the PGIO2 pin.
> > > > + $ref: /schemas/types.yaml#/definitions/string
> > > > + enum: [inverted_power_good, power_good, gpio, active_current_limiting]
> > > > + default: inverted_power_good
> > > > +
> > > > + adi,pgio3-func:
> > > > + description: Configures the function of the PGIO3 pin.
> > > > + $ref: /schemas/types.yaml#/definitions/string
> > > > + enum: [inverted_power_good_input, power_good_input, gpio]
> > > > + default: inverted_power_good_input
> > > > +
> > > > + adi,pgio4-func:
> > > > + description: Configures the function of the PGIO4 pin.
> > > > + $ref: /schemas/types.yaml#/definitions/string
> > > > + enum: [inverted_external_fault, external_fault, gpio]
> > > > + default: inverted_external_fault
> > > > +
> > > > + adi,gpio-on-adio1:
> > > > + description: If set, the ADIO1 pin is used as a GPIO.
> > > > + type: boolean
> > > > +
> > > > + adi,gpio-on-adio2:
> > > > + description: If set, the ADIO2 pin is used as a GPIO.
> > > > + type: boolean
> > > > +
> > > > + adi,gpio-on-adio3:
> > > > + description: If set, the ADIO3 pin is used as a GPIO.
> > > > + type: boolean
> > > > +
> > > > + adi,gpio-on-adio4:
> > > > + description: If set, the ADIO4 pin is used as a GPIO.
> > > > + type: boolean
> > >
> > > Does this dependency block force a redundant specification of adi,pgio4-func?
> > > The default for adi,pgio4-func is inverted_external_fault, which means the
> > > default hardware state already supports external fault features.
> > > If a device tree legitimately omits adi,pgio4-func to rely on that default,
> > > will it fail schema validation here since the dependencies keyword strictly
> > > checks for the literal presence of properties without injecting defaults?
> >
> > Fair point. I guess it will fail but the alternative is to not have any constrain at all so
> > maybe worth it to be explicit in here?
> >
>
> I don't claim to understand how to define devicetree properties, but
>
> adi,pgio4-func = <"gpio">
>
> and
>
> adi,gpio-on-adio4;
>
> seem to be equivalent to me, and omitting the first property (because
Not exactly. ADIO4 and PGIO4 are different pins and can be both configured
as GPIOs. ADIO is a boolean because they are either monitored by the ADC (default)
or configured as GPIOs. PGIOs can have additional configurations and hence the
enum.
- Nuno Sá
> it defaults to inverted_external_fault) would cause the second to fail.
> So either both would be necessary or none. If that is correct, what is
> the point of having the adi,gpio-on-adio4 property in the first place ?
>
> In other words, what is the difference between
> adi,pgio4-func = <"gpio">;
> adi,gpio-on-adio4;
>
> and
> adi,pgio4-func = <"gpio">;
> (with no boolean property) ?
>
> Thanks,
> Guenter
^ permalink raw reply
* [PATCH v3] docs: allow inline literals in paragraphs to wrap to prevent overflow
From: Rito Rhymes @ 2026-03-23 15:14 UTC (permalink / raw)
To: Jonathan Corbet, linux-doc; +Cc: Shuah Khan, linux-kernel, rdunlap, Rito Rhymes
In-Reply-To: <20260321141118.23828-1-rito@ritovision.com>
Some documentation pages contain long inline literals in paragraph
text that can force page-wide horizontal scroll overflow and break
layout on smaller screens.
Override the default `span.pre` white-space behavior for inline
literals and use `overflow-wrap: anywhere` so they can wrap when
needed. For code used as part of a paragraph, wrapping is appropriate
because it is stylistically part of the surrounding text. Code blocks,
by contrast, are meant to preserve formatting fidelity and are better
served by contained horizontal scrolling.
Examples:
https://docs.kernel.org/6.15/userspace-api/futex2.html
https://docs.kernel.org/6.15/security/IMA-templates.html
Signed-off-by: Rito Rhymes <rito@ritovision.com>
Assisted-by: Codex:GPT-5.4
---
v3: add latest public versioned URL examples to the patchlog
Documentation/sphinx-static/custom.css | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css
index db24f4344..dd69df2a7 100644
--- a/Documentation/sphinx-static/custom.css
+++ b/Documentation/sphinx-static/custom.css
@@ -149,6 +149,15 @@ div.language-selection ul li:hover {
background: #dddddd;
}
+/*
+ * Let long inline literals in paragraph text wrap as needed to prevent
+ * overflow.
+ */
+code.docutils.literal span.pre {
+ white-space: normal;
+ overflow-wrap: anywhere;
+}
+
/* Make xrefs more universally visible */
a.reference, a.reference:hover {
border-bottom: none;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v3 0/2] hwmon: Add support for MPS mp2985
From: Guenter Roeck @ 2026-03-23 15:08 UTC (permalink / raw)
To: wenswang, robh, krzk+dt, conor+dt, skhan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc
In-Reply-To: <20260323061901.827025-1-wenswang@yeah.net>
On 3/22/26 23:19, wenswang@yeah.net wrote:
> From: Wensheng Wang <wenswang@yeah.net>
>
> Add mp2985 driver in hwmon and add dt-bindings for it.
>
AI feedback is here:
https://sashiko.dev/#/patchset/20260323062104.827263-1-wenswang%40yeah.net
Couple of comments:
- If the mantissa overflow can not happen, please add a comment into the code
explaining the reason.
- EINVAL returns need to be explained. They should only be used
if the chip can not handle reading unsupported registers, and a comment
in the code needs to explain that.
- Ignore the concern about the chip being left on page 2 after an error
reading MFR_VR_MULTI_CONFIG_R[12] for now. It makes me wonder if
pmbus_init_common() should explicitly select page 0 for multi-page
chips.
- The alignment of
+ ret = i2c_smbus_read_word_data(client, page == 0 ?
+ MFR_VR_MULTI_CONFIG_R1 :
+ MFR_VR_MULTI_CONFIG_R2);
still seems odd. Why the large indentation ?
Thanks,
Guenter
^ permalink raw reply
* [RFC PATCH v2 1/1] mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action
From: gutierrez.asier @ 2026-03-23 14:56 UTC (permalink / raw)
To: gutierrez.asier, artem.kuzin, stepanov.anatoly, wangkefeng.wang,
yanquanmin1, zuoze1, damon, sj, akpm, ljs, Liam.Howlett, vbabka,
rppt, surenb, mhocko, corbet, skhan, linux-doc, linux-mm,
linux-kernel
In-Reply-To: <20260323145646.4165053-1-gutierrez.asier@huawei-partners.com>
From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
This patch set introces a new action: DAMOS_COLLAPSE.
For DAMOS_HUGEPAGE and DAMOS_NOHUGEPAGE to work, khugepaged should be
working, since it relies on hugepage_madvise to add a new slot. This
slot should be picked up by khugepaged and eventually collapse (or
not, if we are using DAMOS_NOHUGEPAGE) the pages. If THP is not
enabled, khugepaged will not be working, and therefore no collapse
will happen.
DAMOS_COLLAPSE eventually calls madvise_collapse, which will collapse
the address range synchronously.
This new action may be required to support autotuning with hugepage as
a goal[1].
[1]: https://lore.kernel.org/damon/20260313000816.79933-1-sj@kernel.org/
---------
Benchmarks:
T n: THP never
T m: THP madvise
D h: DAMON action hugepage
D c: DAMON action collapse
+------------------+----------+----------+----------+
| | T n, D h | T m, D h | T n, D c |
+------------------+----------+----------+----------+
| Total memory use | 2.07 | 2.09 | 2.07 |
| Huge pages | 0 | 1.3 | 1.25 |
+------------------+----------+----------+----------+
Changes
---------
v1 -> v2:
Added benchmarks
Added damos_filter_type documentation for new action to fix kernel-doc
Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
---
Documentation/mm/damon/design.rst | 4 ++++
include/linux/damon.h | 2 ++
mm/damon/sysfs-schemes.c | 4 ++++
mm/damon/vaddr.c | 3 +++
tools/testing/selftests/damon/sysfs.py | 11 ++++++-----
5 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 838b14d22519..405142641e55 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -467,6 +467,10 @@ that supports each action are as below.
Supported by ``vaddr`` and ``fvaddr`` operations set. When
TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
fail.
+ - ``collapse``: Call ``madvise()`` for the region with ``MADV_COLLAPSE``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set. When
+ TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
+ fail.
- ``lru_prio``: Prioritize the region on its LRU lists.
Supported by ``paddr`` operations set.
- ``lru_deprio``: Deprioritize the region on its LRU lists.
diff --git a/include/linux/damon.h b/include/linux/damon.h
index d9a3babbafc1..6941113968ec 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -121,6 +121,7 @@ struct damon_target {
* @DAMOS_PAGEOUT: Reclaim the region.
* @DAMOS_HUGEPAGE: Call ``madvise()`` for the region with MADV_HUGEPAGE.
* @DAMOS_NOHUGEPAGE: Call ``madvise()`` for the region with MADV_NOHUGEPAGE.
+ * @DAMOS_COLLAPSE: Call ``madvise()`` for the region with MADV_COLLAPSE.
* @DAMOS_LRU_PRIO: Prioritize the region on its LRU lists.
* @DAMOS_LRU_DEPRIO: Deprioritize the region on its LRU lists.
* @DAMOS_MIGRATE_HOT: Migrate the regions prioritizing warmer regions.
@@ -140,6 +141,7 @@ enum damos_action {
DAMOS_PAGEOUT,
DAMOS_HUGEPAGE,
DAMOS_NOHUGEPAGE,
+ DAMOS_COLLAPSE,
DAMOS_LRU_PRIO,
DAMOS_LRU_DEPRIO,
DAMOS_MIGRATE_HOT,
diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 5186966dafb3..aa08a8f885fb 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -2041,6 +2041,10 @@ static struct damos_sysfs_action_name damos_sysfs_action_names[] = {
.action = DAMOS_NOHUGEPAGE,
.name = "nohugepage",
},
+ {
+ .action = DAMOS_COLLAPSE,
+ .name = "collapse",
+ },
{
.action = DAMOS_LRU_PRIO,
.name = "lru_prio",
diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
index b069dbc7e3d2..dd5f2d7027ac 100644
--- a/mm/damon/vaddr.c
+++ b/mm/damon/vaddr.c
@@ -903,6 +903,9 @@ static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx,
case DAMOS_NOHUGEPAGE:
madv_action = MADV_NOHUGEPAGE;
break;
+ case DAMOS_COLLAPSE:
+ madv_action = MADV_COLLAPSE;
+ break;
case DAMOS_MIGRATE_HOT:
case DAMOS_MIGRATE_COLD:
return damos_va_migrate(t, r, scheme, sz_filter_passed);
diff --git a/tools/testing/selftests/damon/sysfs.py b/tools/testing/selftests/damon/sysfs.py
index 3aa5c91548a5..c6476e63f4fb 100755
--- a/tools/testing/selftests/damon/sysfs.py
+++ b/tools/testing/selftests/damon/sysfs.py
@@ -123,11 +123,12 @@ def assert_scheme_committed(scheme, dump):
'pageout': 2,
'hugepage': 3,
'nohugeapge': 4,
- 'lru_prio': 5,
- 'lru_deprio': 6,
- 'migrate_hot': 7,
- 'migrate_cold': 8,
- 'stat': 9,
+ 'collapse': 5
+ 'lru_prio': 6,
+ 'lru_deprio': 7,
+ 'migrate_hot': 8,
+ 'migrate_cold': 9,
+ 'stat': 10,
}
assert_true(dump['action'] == action_val[scheme.action], 'action', dump)
assert_true(dump['apply_interval_us'] == scheme. apply_interval_us,
--
2.43.0
^ permalink raw reply related
* [RFC PATCH v1 1/1] This patch set introces a new action: DAMOS_COLLAPSE.
From: gutierrez.asier @ 2026-03-23 14:56 UTC (permalink / raw)
To: gutierrez.asier, artem.kuzin, stepanov.anatoly, wangkefeng.wang,
yanquanmin1, zuoze1, damon, sj, akpm, ljs, Liam.Howlett, vbabka,
rppt, surenb, mhocko, corbet, skhan, linux-doc, linux-mm,
linux-kernel
From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
For DAMOS_HUGEPAGE and DAMOS_NOHUGEPAGE to work, khugepaged should be
working, since it relies on hugepage_madvise to add a new slot. This
slot should be picked up by khugepaged and eventually collapse (or
not, if we are using DAMOS_NOHUGEPAGE) the pages. If THP is not
enabled, khugepaged will not be working, and therefore no collapse
will happen.
DAMOS_COLLAPSE eventually calls madvise_collapse, which will collapse
the address range synchronously.
This new action may be required to support autotuning with hugepage as
a goal[1].
[1]: https://lore.kernel.org/damon/20260313000816.79933-1-sj@kernel.org/
---------
Benchmarks:
T n: THP never
T m: THP madvise
D h: DAMON action hugepage
D c: DAMON action collapse
+------------------+----------+----------+----------+
| | T n, D h | T m, D h | T n, D c |
+------------------+----------+----------+----------+
| Total memory use | 2.07 | 2.09 | 2.07 |
| Huge pages | 0 | 1.3 | 1.25 |
+------------------+----------+----------+----------+
Changes
---------
v1-v2:
Added benchmarks
Added damos_filter_type documentation for new action to fix kernel-doc
Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
---
Documentation/mm/damon/design.rst | 4 ++++
include/linux/damon.h | 2 ++
mm/damon/sysfs-schemes.c | 4 ++++
mm/damon/vaddr.c | 3 +++
tools/testing/selftests/damon/sysfs.py | 11 ++++++-----
5 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 838b14d22519..405142641e55 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -467,6 +467,10 @@ that supports each action are as below.
Supported by ``vaddr`` and ``fvaddr`` operations set. When
TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
fail.
+ - ``collapse``: Call ``madvise()`` for the region with ``MADV_COLLAPSE``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set. When
+ TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
+ fail.
- ``lru_prio``: Prioritize the region on its LRU lists.
Supported by ``paddr`` operations set.
- ``lru_deprio``: Deprioritize the region on its LRU lists.
diff --git a/include/linux/damon.h b/include/linux/damon.h
index d9a3babbafc1..6941113968ec 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -121,6 +121,7 @@ struct damon_target {
* @DAMOS_PAGEOUT: Reclaim the region.
* @DAMOS_HUGEPAGE: Call ``madvise()`` for the region with MADV_HUGEPAGE.
* @DAMOS_NOHUGEPAGE: Call ``madvise()`` for the region with MADV_NOHUGEPAGE.
+ * @DAMOS_COLLAPSE: Call ``madvise()`` for the region with MADV_COLLAPSE.
* @DAMOS_LRU_PRIO: Prioritize the region on its LRU lists.
* @DAMOS_LRU_DEPRIO: Deprioritize the region on its LRU lists.
* @DAMOS_MIGRATE_HOT: Migrate the regions prioritizing warmer regions.
@@ -140,6 +141,7 @@ enum damos_action {
DAMOS_PAGEOUT,
DAMOS_HUGEPAGE,
DAMOS_NOHUGEPAGE,
+ DAMOS_COLLAPSE,
DAMOS_LRU_PRIO,
DAMOS_LRU_DEPRIO,
DAMOS_MIGRATE_HOT,
diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 5186966dafb3..aa08a8f885fb 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -2041,6 +2041,10 @@ static struct damos_sysfs_action_name damos_sysfs_action_names[] = {
.action = DAMOS_NOHUGEPAGE,
.name = "nohugepage",
},
+ {
+ .action = DAMOS_COLLAPSE,
+ .name = "collapse",
+ },
{
.action = DAMOS_LRU_PRIO,
.name = "lru_prio",
diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
index b069dbc7e3d2..dd5f2d7027ac 100644
--- a/mm/damon/vaddr.c
+++ b/mm/damon/vaddr.c
@@ -903,6 +903,9 @@ static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx,
case DAMOS_NOHUGEPAGE:
madv_action = MADV_NOHUGEPAGE;
break;
+ case DAMOS_COLLAPSE:
+ madv_action = MADV_COLLAPSE;
+ break;
case DAMOS_MIGRATE_HOT:
case DAMOS_MIGRATE_COLD:
return damos_va_migrate(t, r, scheme, sz_filter_passed);
diff --git a/tools/testing/selftests/damon/sysfs.py b/tools/testing/selftests/damon/sysfs.py
index 3aa5c91548a5..c6476e63f4fb 100755
--- a/tools/testing/selftests/damon/sysfs.py
+++ b/tools/testing/selftests/damon/sysfs.py
@@ -123,11 +123,12 @@ def assert_scheme_committed(scheme, dump):
'pageout': 2,
'hugepage': 3,
'nohugeapge': 4,
- 'lru_prio': 5,
- 'lru_deprio': 6,
- 'migrate_hot': 7,
- 'migrate_cold': 8,
- 'stat': 9,
+ 'collapse': 5
+ 'lru_prio': 6,
+ 'lru_deprio': 7,
+ 'migrate_hot': 8,
+ 'migrate_cold': 9,
+ 'stat': 10,
}
assert_true(dump['action'] == action_val[scheme.action], 'action', dump)
assert_true(dump['apply_interval_us'] == scheme. apply_interval_us,
--
2.43.0
^ permalink raw reply related
* Re: (subset) [PATCH v8 0/2] Add support for sound profile switching and leverage for OnePlus slider
From: Bjorn Andersson @ 2026-03-23 14:50 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Jiri Kosina, Benjamin Tissoires,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Casey Connolly, Guido Günther, David Heidelberg
Cc: linux-input, linux-doc, linux-kernel, linux-arm-msm, devicetree,
phone-devel, Gergo Koteles, Casey Connolly
In-Reply-To: <20251113-op6-tri-state-v8-0-54073f3874bc@ixit.cz>
On Thu, 13 Nov 2025 17:02:57 +0100, David Heidelberg wrote:
> This series add initial support for OnePlus 6 and 6T, but other OnePlus
> phones contains same mechanism to switch sound profiles.
>
> This code was tested for two years within the downstream Snapdragon 845 tree.
> It is now perfectly integrated with feedbackd in the Phosh environment.
>
> The series is also available (until merged) at
> https://gitlab.com/sdm845/sdm845-next/-/commits/b4/op6-tri-state
>
> [...]
Applied, thanks!
[2/2] arm64: dts: qcom: sdm845-oneplus: Add alert-slider
commit: ca5adb26c5927f28016c6b1778622dee9ada5ca0
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: watchdog: Drop SMARC-sAM67 support
From: Guenter Roeck @ 2026-03-23 14:45 UTC (permalink / raw)
To: Michael Walle, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Srinivas Kandagatla, Wim Van Sebroeck, Jonathan Corbet,
Shuah Khan
Cc: linux-arm-kernel, devicetree, linux-kernel, linux-hwmon,
linux-watchdog, linux-doc, Conor Dooley
In-Reply-To: <DHA13HM1GIJW.1E7XCMY349JX7@kernel.org>
On 3/23/26 01:45, Michael Walle wrote:
> Hi,
>
> On Mon Mar 2, 2026 at 4:01 PM CET, Guenter Roeck wrote:
>> On 3/2/26 04:24, Michael Walle wrote:
>>> I was just informed that this product is discontinued (without being
>>> ever released to the market). Pull the plug and let's not waste any more
>>> maintainers time and revert commit 354f31e9d2a3 ("dt-bindings: watchdog:
>>> Add SMARC-sAM67 support").
>>>
>>> Acked-by: Conor Dooley <conor.dooley@microchip.com>
>>> Signed-off-by: Michael Walle <mwalle@kernel.org>
>>
>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
> Everything expect this patch was picked up. Guenter, do you want to
> take it, or should it go through the TI SoC queue?
>
> Thanks,
> -michael
I am fine with either approach. Wim handles all watchdog subsystem pull requests,
so we'll need his feedback.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v7 03/10] x86/bhi: Rename clear_bhb_loop() to clear_bhb_loop_nofence()
From: Nikolay Borisov @ 2026-03-23 14:44 UTC (permalink / raw)
To: Pawan Gupta, x86, H. Peter Anvin, Josh Poimboeuf, David Kaplan,
Sean Christopherson, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet
Cc: linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260319-vmscape-bhb-v7-3-b76a777a98af@linux.intel.com>
On 19.03.26 г. 17:40 ч., Pawan Gupta wrote:
> To reflect the recent change that moved LFENCE to the caller side.
>
> Suggested-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Nit: I think having the _nofence in the function name is leaking an
implementation detail into the name/interface. I.e things change and we
decide that the implementation of a particular function must change so
we just do the change and substantiate it in the commit message or in a
comment. Especially that we don't have a "with an lfence" version.
What's more I'd consider this a "private" function, that's called via
the CLEAR_BRANCH_HISTORY macros, the only place it's called directly is
in the bpf jit code, but that's more of an exception.
Still,
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
<snip>
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: hwmon: Document the LTC4283 Swap Controller
From: Guenter Roeck @ 2026-03-23 14:33 UTC (permalink / raw)
To: Nuno Sá, nuno.sa
Cc: linux-gpio, linux-hwmon, devicetree, linux-doc, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <77cd7e879a10df791d9d5eb1f16f1654e9904199.camel@gmail.com>
[ ...]
>>> + adi,pgio1-func:
>>> + description: Configures the function of the PGIO1 pin.
>>> + $ref: /schemas/types.yaml#/definitions/string
>>> + enum: [inverted_power_good, power_good, gpio]
>>> + default: inverted_power_good
>>> +
>>> + adi,pgio2-func:
>>> + description: Configures the function of the PGIO2 pin.
>>> + $ref: /schemas/types.yaml#/definitions/string
>>> + enum: [inverted_power_good, power_good, gpio, active_current_limiting]
>>> + default: inverted_power_good
>>> +
>>> + adi,pgio3-func:
>>> + description: Configures the function of the PGIO3 pin.
>>> + $ref: /schemas/types.yaml#/definitions/string
>>> + enum: [inverted_power_good_input, power_good_input, gpio]
>>> + default: inverted_power_good_input
>>> +
>>> + adi,pgio4-func:
>>> + description: Configures the function of the PGIO4 pin.
>>> + $ref: /schemas/types.yaml#/definitions/string
>>> + enum: [inverted_external_fault, external_fault, gpio]
>>> + default: inverted_external_fault
>>> +
>>> + adi,gpio-on-adio1:
>>> + description: If set, the ADIO1 pin is used as a GPIO.
>>> + type: boolean
>>> +
>>> + adi,gpio-on-adio2:
>>> + description: If set, the ADIO2 pin is used as a GPIO.
>>> + type: boolean
>>> +
>>> + adi,gpio-on-adio3:
>>> + description: If set, the ADIO3 pin is used as a GPIO.
>>> + type: boolean
>>> +
>>> + adi,gpio-on-adio4:
>>> + description: If set, the ADIO4 pin is used as a GPIO.
>>> + type: boolean
>>
>> Does this dependency block force a redundant specification of adi,pgio4-func?
>> The default for adi,pgio4-func is inverted_external_fault, which means the
>> default hardware state already supports external fault features.
>> If a device tree legitimately omits adi,pgio4-func to rely on that default,
>> will it fail schema validation here since the dependencies keyword strictly
>> checks for the literal presence of properties without injecting defaults?
>
> Fair point. I guess it will fail but the alternative is to not have any constrain at all so
> maybe worth it to be explicit in here?
>
I don't claim to understand how to define devicetree properties, but
adi,pgio4-func = <"gpio">
and
adi,gpio-on-adio4;
seem to be equivalent to me, and omitting the first property (because
it defaults to inverted_external_fault) would cause the second to fail.
So either both would be necessary or none. If that is correct, what is
the point of having the adi,gpio-on-adio4 property in the first place ?
In other words, what is the difference between
adi,pgio4-func = <"gpio">;
adi,gpio-on-adio4;
and
adi,pgio4-func = <"gpio">;
(with no boolean property) ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v3 07/10] gpu: nova-core: falcon: introduce `bounded_enum` macro
From: Alexandre Courbot @ 2026-03-23 14:22 UTC (permalink / raw)
To: Gary Guo
Cc: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Miguel Ojeda,
Boqun Feng, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Joel Fernandes,
Timur Tabi, Zhi Wang, Eliot Courtney, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <DHA65RY78M31.20BCCF00R67TH@garyguo.net>
On Mon Mar 23, 2026 at 9:43 PM JST, Gary Guo wrote:
> On Mon Mar 23, 2026 at 11:07 AM GMT, Alexandre Courbot wrote:
>> Introduce a powered-up version of our ad-hoc `impl_from_enum_to_u8`
>> macro that allows the definition of an enum type associated to a
>> `Bounded` of a given width, and provides the `From` and `TryFrom`
>> implementations required to use that enum as a register field member.
>>
>> The next patch will make use of it to convert all falcon registers to
>> the kernel register macro.
>>
>> The macro is unused in this patch: it is introduced ahead-of-time to
>> avoid diff mingling in the next patch that would make it difficult to
>> review.
>>
>> Reviewed-by: Gary Guo <gary@garyguo.net>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> drivers/gpu/nova-core/falcon.rs | 82 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 82 insertions(+)
>>
>> diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
>> index 5a4f7fc85160..5221e4476f90 100644
>> --- a/drivers/gpu/nova-core/falcon.rs
>> +++ b/drivers/gpu/nova-core/falcon.rs
>> @@ -54,6 +54,88 @@ fn from(value: $enum_type) -> Self {
>> };
>> }
>>
>> +/// Creates an enum type associated to a `Bounded`, with a `From` conversion to the associated
>> +/// `Bounded` and either a `TryFrom` or `From` converting from the associated `Bounded`.
>> +// TODO[FPRI]: This is a temporary solution to be replaced with the corresponding derive macros
>> +// once they land.
>> +#[expect(unused)]
>> +macro_rules! bounded_enum {
>> + (
>> + $(#[doc = $enum_doc:expr])*
>> + enum $enum_type:ident with $from_impl:ident<Bounded<$width:ty, $length:literal>> {
>> + $( $(#[doc = $variant_doc:expr])* $variant:ident = $value:expr),* $(,)*
>> + }
>> + ) => {
>> + $(#[doc = $enum_doc])*
>> + #[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]
>> + pub(crate) enum $enum_type {
>> + $(
>> + $(#[doc = $variant_doc])*
>> + $variant = $value
>> + ),*
>> + }
>> +
>> + impl From<$enum_type> for Bounded<$width, $length> {
>> + fn from(value: $enum_type) -> Self {
>> + match value {
>> + $($enum_type::$variant => Bounded::<$width, _>::new::<$value>()),*
>
> Hi Alex,
>
> This looks exactly the same as the last version, without out the {} and MAX..
> change made (which you mentioned in the cover letter).
I'm so sorry. I mistakenly squashed the fixup commit into the next
commit instead of this one. I will resend after hearing back from Danilo
about where the macro should reside.
^ permalink raw reply
* Re: [PATCH v3 01/10] gpu: nova-core: convert PMC registers to kernel register macro
From: Danilo Krummrich @ 2026-03-23 14:21 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Alice Ryhl, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Joel Fernandes,
Timur Tabi, Zhi Wang, Eliot Courtney, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <DHA81784G24U.1446CUTJC271J@nvidia.com>
On 3/23/26 3:11 PM, Alexandre Courbot wrote:
> On Mon Mar 23, 2026 at 8:21 PM JST, Danilo Krummrich wrote:
>> On Mon Mar 23, 2026 at 12:07 PM CET, Alexandre Courbot wrote:
>>> -impl TryFrom<u8> for Architecture {
>>> +impl TryFrom<Bounded<u32, 6>> for Architecture {
>>> type Error = Error;
>>>
>>> - fn try_from(value: u8) -> Result<Self> {
>>> - match value {
>>> + fn try_from(value: Bounded<u32, 6>) -> Result<Self> {
>>> + match u8::from(value) {
>>> 0x16 => Ok(Self::Turing),
>>> 0x17 => Ok(Self::Ampere),
>>> 0x19 => Ok(Self::Ada),
>>> @@ -155,23 +151,26 @@ fn try_from(value: u8) -> Result<Self> {
>>> }
>>> }
>>>
>>> -impl From<Architecture> for u8 {
>>> +impl From<Architecture> for Bounded<u32, 6> {
>>> fn from(value: Architecture) -> Self {
>>> - // CAST: `Architecture` is `repr(u8)`, so this cast is always lossless.
>>> - value as u8
>>> + match value {
>>> + Architecture::Turing => Bounded::<u32, _>::new::<0x16>(),
>>> + Architecture::Ampere => Bounded::<u32, _>::new::<0x17>(),
>>> + Architecture::Ada => Bounded::<u32, _>::new::<0x19>(),
>>> + }
>>> }
>>> }
>>
>> Can this use bounded_enum!()?
>
> If we move it outside of `falcon.rs`, yes. I didn't want to make too
> permanent a solution with the `TryFrom` macro being developed, but if
> you prefer that way that's doable. I guess `bounded_enum` would need to
> be in the root module though to be accessible by both `falcon` and
> `gpu`.
Since we are going to have it as an intermediate solution, let's be consistent
about it. Maybe num.rs is a good place?
^ permalink raw reply
* Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc
From: Guenter Roeck @ 2026-03-23 14:15 UTC (permalink / raw)
To: Akshay Gupta, linux-kernel
Cc: corbet, skhan, arnd, gregkh, Prathima.Lk, naveenkrishna.chatradhi,
Anand.Umarji, linux-doc, linux-hwmon, kunyi
In-Reply-To: <20260323110811.2898997-2-Akshay.Gupta@amd.com>
On 3/23/26 04:08, Akshay Gupta wrote:
> From: Prathima <Prathima.Lk@amd.com>
>
> Move SBTSI core functionality out of the hwmon-only path and into
> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
>
> This split prepares the driver for additional interfaces while keeping
> hwmon support as an optional layer on top of common SBTSI core logic.
>
This moves the driver out of hwmon space into misc/amd-sbi which,
in my opinion, is completely unnecessary to accomplish the stated goals.
I assume this is to be able to make changes which do not follow
the hwmon ABI and/or to bypass hwmon subsystem review, similar
to what has been done by others.
Obviously, I think this is a bad idea. I won't give it a NACK,
but I won't approve (nor review) it either.
Guenter
^ permalink raw reply
* Re: [PATCH v3 01/10] gpu: nova-core: convert PMC registers to kernel register macro
From: Alexandre Courbot @ 2026-03-23 14:11 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Alice Ryhl, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Joel Fernandes,
Timur Tabi, Zhi Wang, Eliot Courtney, dri-devel, linux-kernel,
linux-riscv, linux-doc, rust-for-linux
In-Reply-To: <DHA4EQAOO8QW.3AFGNJZFQX6N7@kernel.org>
On Mon Mar 23, 2026 at 8:21 PM JST, Danilo Krummrich wrote:
> On Mon Mar 23, 2026 at 12:07 PM CET, Alexandre Courbot wrote:
>> -impl TryFrom<u8> for Architecture {
>> +impl TryFrom<Bounded<u32, 6>> for Architecture {
>> type Error = Error;
>>
>> - fn try_from(value: u8) -> Result<Self> {
>> - match value {
>> + fn try_from(value: Bounded<u32, 6>) -> Result<Self> {
>> + match u8::from(value) {
>> 0x16 => Ok(Self::Turing),
>> 0x17 => Ok(Self::Ampere),
>> 0x19 => Ok(Self::Ada),
>> @@ -155,23 +151,26 @@ fn try_from(value: u8) -> Result<Self> {
>> }
>> }
>>
>> -impl From<Architecture> for u8 {
>> +impl From<Architecture> for Bounded<u32, 6> {
>> fn from(value: Architecture) -> Self {
>> - // CAST: `Architecture` is `repr(u8)`, so this cast is always lossless.
>> - value as u8
>> + match value {
>> + Architecture::Turing => Bounded::<u32, _>::new::<0x16>(),
>> + Architecture::Ampere => Bounded::<u32, _>::new::<0x17>(),
>> + Architecture::Ada => Bounded::<u32, _>::new::<0x19>(),
>> + }
>> }
>> }
>
> Can this use bounded_enum!()?
If we move it outside of `falcon.rs`, yes. I didn't want to make too
permanent a solution with the `TryFrom` macro being developed, but if
you prefer that way that's doable. I guess `bounded_enum` would need to
be in the root module though to be accessible by both `falcon` and
`gpu`.
^ permalink raw reply
* Re: [PATCH v4 0/4] kallsyms: embed source file:line info in kernel stack traces
From: Sasha Levin @ 2026-03-23 14:06 UTC (permalink / raw)
To: Andrew Morton
Cc: Masahiro Yamada, Luis Chamberlain, Linus Torvalds,
Richard Weinberger, Juergen Gross, Geert Uytterhoeven,
James Bottomley, Jonathan Corbet, Nathan Chancellor,
Nicolas Schier, Petr Pavlu, Daniel Gomez, Greg KH, Petr Mladek,
Steven Rostedt, Kees Cook, Peter Zijlstra, Thorsten Leemhuis,
Vlastimil Babka, Helge Deller, Randy Dunlap, Laurent Pinchart,
Vivian Wang, linux-kernel, linux-kbuild, linux-modules, linux-doc
In-Reply-To: <20260322093533.c0aab4ed9f5eef9536d14c21@linux-foundation.org>
On Sun, Mar 22, 2026 at 09:35:33AM -0700, Andrew Morton wrote:
>On Sun, 22 Mar 2026 09:15:39 -0400 Sasha Levin <sashal@kernel.org> wrote:
>
>> This series adds CONFIG_KALLSYMS_LINEINFO, which embeds source file:line
>> information directly in the kernel image so that stack traces annotate
>> every frame with the originating source location - no external tools, no
>> debug symbols at runtime, and safe to use in NMI/panic context.
>
>Sashiko review hasn't completed yet, but it has things to say:
> https://sashiko.dev/#/patchset/20260322131543.971079-1-sashal@kernel.org
Nice! I looked at the comments, and I don't think that there are any changes
required as a result of the review. It asked good questions, but the concerns
are mainly false positives.
--
Thanks,
Sasha
^ permalink raw reply
* RE: [PATCH v12 3/5] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shenwei Wang @ 2026-03-23 13:51 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer,
arnaud.pouliquen@foss.st.com
Cc: Shuah Khan, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski, Andrew Lunn
In-Reply-To: <20260313195801.2043306-4-shenwei.wang@nxp.com>
Hi Bjorn,
> -----Original Message-----
> From: Shenwei Wang
> Sent: Friday, March 13, 2026 2:59 PM
> To: Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
> Jonathan Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
> Andersson <andersson@kernel.org>; Mathieu Poirier
> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> <s.hauer@pengutronix.de>; arnaud.pouliquen@foss.st.com
> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Shenwei
> Wang <shenwei.wang@nxp.com>; Peng Fan <peng.fan@nxp.com>;
> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>; Andrew Lunn
> <andrew@lunn.ch>
> Subject: [PATCH v12 3/5] gpio: rpmsg: add generic rpmsg GPIO driver
>
Since I rewrote this version based on your earlier feedback
---
"My expectation is that it will be better to just have two separate
drivers - but reuse all the design-work done in the gpio-virtio."
---
I'd glad to hear what you think about this patch.
Thanks,
Shenwei
> On an AMP platform, the system may include two processors:
> - An MCU running an RTOS
> - An MPU running Linux
>
> These processors communicate via the RPMSG protocol.
> The driver implements the standard GPIO interface, allowing the Linux side to
> control GPIO controllers which reside in the remote processor via RPMSG
> protocol.
>
> Cc: Bartosz Golaszewski <brgl@bgdev.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
> ---
> drivers/gpio/Kconfig | 17 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-rpmsg.c | 596 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 614 insertions(+)
> create mode 100644 drivers/gpio/gpio-rpmsg.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index
> b45fb799e36c..cff0fda8a283 100644
^ permalink raw reply
* Re: [PATCH v2 0/1] docs: examples of pages affected by C API signature overflow
From: Jonathan Corbet @ 2026-03-23 13:42 UTC (permalink / raw)
To: Rito Rhymes, Rito Rhymes, linux-doc; +Cc: Shuah Khan, linux-kernel, rdunlap
In-Reply-To: <DHA2MFSL71FH.1Z930JBKI8AOE@ritovision.com>
"Rito Rhymes" <rito@ritovision.com> writes:
> Thank you for the feedback.
>
> I'll put some examples in the changelogs with versioned URLs and
> reroll them without a cover letter.
>
>> The cover letter tells reviewers what the series as a whole does
>
> Admittedly, I knew including a cover letter for a single patch was
> non-standard. Given the quantity of examples I aimed to include,
> I didn't think it acceptable to include it all in the changelog, but I
> knew having the examples was important for testing, so I repurposed the
> cover letter as the vehicle for including them. I'll lay off that.
If you want to include extra information for reviewers that doesn't
belong in the changelog, you can put it below the "---" line and it will
be stripped out at application time.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v13 05/12] dmaengine: qcom: bam_dma: add support for BAM locking
From: Manivannan Sadhasivam @ 2026-03-23 13:41 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bartosz Golaszewski, Vinod Koul, Jonathan Corbet, Thara Gopinath,
Herbert Xu, David S. Miller, Udit Tiwari, Md Sadre Alam,
Dmitry Baryshkov, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, dmaengine, linux-doc,
linux-kernel, linux-arm-msm, linux-crypto, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <CAMRc=McostnmVjE=uV=2KA7-dqLvQ2BAJYTXzANacFpPGgS+Sw@mail.gmail.com>
On Mon, Mar 23, 2026 at 02:36:59PM +0100, Bartosz Golaszewski wrote:
> On Mon, Mar 23, 2026 at 10:35 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Tue, Mar 17, 2026 at 03:02:12PM +0100, Bartosz Golaszewski wrote:
> > > Add support for BAM pipe locking. To that end: when starting DMA on an RX
> > > channel - prepend the existing queue of issued descriptors with an
> > > additional "dummy" command descriptor with the LOCK bit set. Once the
> > > transaction is done (no more issued descriptors), issue one more dummy
> > > descriptor with the UNLOCK bit.
> >
> > I've left some comments in v12, but looks like you've missed them.
>
> Sorry for that, as I explained in private, this email did not end up
> in my inbox and I didn't see it on lore.
>
> > >
> > > +static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
> > > +{
> > > + struct bam_chan *bchan = to_bam_chan(desc->chan);
> > > + const struct bam_device_data *bdata = bchan->bdev->dev_data;
> > > + struct bam_desc_metadata *metadata = data;
> > > +
> > > + if (!data)
> > > + return -EINVAL;
> > > +
> > > + if (!bdata->pipe_lock_supported)
> > > + return -EOPNOTSUPP;
> >
> > As mentioned in v12, you should return 0 to avoid erroring out the clients if
> > pipe lock is not supported.
> >
>
> If the client attaches the scratchpad register then it probably does
> want to use locking, right? On the other hand, I assume you're
> thinking about a situation where the client wants locking but BAM does
> not support it. It's unlikely but ok, I'll change it.
>
Locking is supported only since v1.4.0. So I was trying to avoid erroring out
the clients wanting to use DMA on older platforms (pre 1.4.0). I'm not sure if
such platforms exist, but could be possible.
- Mani
> > >
> > > +static struct bam_async_desc *
> > > +bam_make_lock_desc(struct bam_chan *bchan, struct scatterlist *sg,
> > > + struct bam_cmd_element *ce, unsigned long flag)
> > > +{
> > > + struct dma_chan *chan = &bchan->vc.chan;
> > > + struct bam_async_desc *async_desc;
> > > + struct bam_desc_hw *desc;
> > > + struct virt_dma_desc *vd;
> > > + struct virt_dma_chan *vc;
> > > + unsigned int mapped;
> > > + dma_cookie_t cookie;
> > > + int ret;
> > > +
> > > + sg_init_table(sg, 1);
> > > +
> > > + async_desc = kzalloc_flex(*async_desc, desc, 1, GFP_NOWAIT);
> > > + if (!async_desc) {
> > > + dev_err(bchan->bdev->dev, "failed to allocate the BAM lock descriptor\n");
> > > + return NULL;
> > > + }
> > > +
> > > + async_desc->num_desc = 1;
> > > + async_desc->curr_desc = async_desc->desc;
> > > + async_desc->dir = DMA_MEM_TO_DEV;
> > > +
> > > + desc = async_desc->desc;
> > > +
> > > + bam_prep_ce_le32(ce, bchan->scratchpad_addr, BAM_WRITE_COMMAND, 0);
> > > + sg_set_buf(sg, ce, sizeof(*ce));
> > > +
> > > + mapped = dma_map_sg_attrs(chan->slave, sg, 1, DMA_TO_DEVICE, DMA_PREP_CMD);
> > > + if (!mapped) {
> > > + kfree(async_desc);
> > > + return NULL;
> > > + }
> > > +
> > > + desc->flags |= cpu_to_le16(DESC_FLAG_CMD | flag);
> > > + desc->addr = sg_dma_address(sg);
> > > + desc->size = sizeof(struct bam_cmd_element);
> > > +
> > > + vc = &bchan->vc;
> > > + vd = &async_desc->vd;
> > > +
> > > + dma_async_tx_descriptor_init(&vd->tx, &vc->chan);
> > > + vd->tx.flags = DMA_PREP_CMD;
> > > + vd->tx.desc_free = vchan_tx_desc_free;
> > > + vd->tx_result.result = DMA_TRANS_NOERROR;
> > > + vd->tx_result.residue = 0;
> > > +
> > > + cookie = dma_cookie_assign(&vd->tx);
> > > + ret = dma_submit_error(cookie);
> > > + if (ret)
> > > + return NULL;
> >
> > You are leaking async_desc here.
> >
>
> Yeah, not only that but also should unmap the sg here too. Thanks.
>
> > > +
> > > + return async_desc;
> > > +}
> > > +
> > > +static int bam_do_setup_pipe_lock(struct bam_chan *bchan, bool lock)
> > > +{
> > > + struct bam_device *bdev = bchan->bdev;
> > > + const struct bam_device_data *bdata = bdev->dev_data;
> > > + struct bam_async_desc *lock_desc;
> > > + struct bam_cmd_element *ce;
> > > + struct scatterlist *sgl;
> > > + unsigned long flag;
> > > +
> > > + lockdep_assert_held(&bchan->vc.lock);
> > > +
> > > + if (!bdata->pipe_lock_supported || !bchan->scratchpad_addr ||
> > > + bchan->slave.direction != DMA_MEM_TO_DEV)
> > > + return 0;
> > > +
> > > + if (lock) {
> > > + sgl = &bchan->lock_sg;
> > > + ce = &bchan->lock_ce;
> > > + flag = DESC_FLAG_LOCK;
> > > + } else {
> > > + sgl = &bchan->unlock_sg;
> > > + ce = &bchan->unlock_ce;
> > > + flag = DESC_FLAG_UNLOCK;
> > > + }
> > > +
> > > + lock_desc = bam_make_lock_desc(bchan, sgl, ce, flag);
> > > + if (!lock_desc)
> > > + return -ENOMEM;
> > > +
> > > + if (lock)
> > > + list_add(&lock_desc->vd.node, &bchan->vc.desc_issued);
> > > + else
> > > + list_add_tail(&lock_desc->vd.node, &bchan->vc.desc_issued);
> > > +
> > > + bchan->locked = lock;
> >
> > What is this flag for?
> >
>
> Just a leftover. I'll drop it, thanks.
>
> > >
> > > +struct bam_desc_metadata {
> > > + phys_addr_t scratchpad_addr;
> >
> > I think it'd be worth adding a comment for this.
> >
>
> Will do.
>
> Bart
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v13 05/12] dmaengine: qcom: bam_dma: add support for BAM locking
From: Bartosz Golaszewski @ 2026-03-23 13:36 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bartosz Golaszewski, Vinod Koul, Jonathan Corbet, Thara Gopinath,
Herbert Xu, David S. Miller, Udit Tiwari, Md Sadre Alam,
Dmitry Baryshkov, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, dmaengine, linux-doc,
linux-kernel, linux-arm-msm, linux-crypto, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <hohx2judes5c6na4svpah254hqbaf4kbeyu7prwkprfv5dy7hj@26nxwlvb76yp>
On Mon, Mar 23, 2026 at 10:35 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Tue, Mar 17, 2026 at 03:02:12PM +0100, Bartosz Golaszewski wrote:
> > Add support for BAM pipe locking. To that end: when starting DMA on an RX
> > channel - prepend the existing queue of issued descriptors with an
> > additional "dummy" command descriptor with the LOCK bit set. Once the
> > transaction is done (no more issued descriptors), issue one more dummy
> > descriptor with the UNLOCK bit.
>
> I've left some comments in v12, but looks like you've missed them.
Sorry for that, as I explained in private, this email did not end up
in my inbox and I didn't see it on lore.
> >
> > +static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
> > +{
> > + struct bam_chan *bchan = to_bam_chan(desc->chan);
> > + const struct bam_device_data *bdata = bchan->bdev->dev_data;
> > + struct bam_desc_metadata *metadata = data;
> > +
> > + if (!data)
> > + return -EINVAL;
> > +
> > + if (!bdata->pipe_lock_supported)
> > + return -EOPNOTSUPP;
>
> As mentioned in v12, you should return 0 to avoid erroring out the clients if
> pipe lock is not supported.
>
If the client attaches the scratchpad register then it probably does
want to use locking, right? On the other hand, I assume you're
thinking about a situation where the client wants locking but BAM does
not support it. It's unlikely but ok, I'll change it.
> >
> > +static struct bam_async_desc *
> > +bam_make_lock_desc(struct bam_chan *bchan, struct scatterlist *sg,
> > + struct bam_cmd_element *ce, unsigned long flag)
> > +{
> > + struct dma_chan *chan = &bchan->vc.chan;
> > + struct bam_async_desc *async_desc;
> > + struct bam_desc_hw *desc;
> > + struct virt_dma_desc *vd;
> > + struct virt_dma_chan *vc;
> > + unsigned int mapped;
> > + dma_cookie_t cookie;
> > + int ret;
> > +
> > + sg_init_table(sg, 1);
> > +
> > + async_desc = kzalloc_flex(*async_desc, desc, 1, GFP_NOWAIT);
> > + if (!async_desc) {
> > + dev_err(bchan->bdev->dev, "failed to allocate the BAM lock descriptor\n");
> > + return NULL;
> > + }
> > +
> > + async_desc->num_desc = 1;
> > + async_desc->curr_desc = async_desc->desc;
> > + async_desc->dir = DMA_MEM_TO_DEV;
> > +
> > + desc = async_desc->desc;
> > +
> > + bam_prep_ce_le32(ce, bchan->scratchpad_addr, BAM_WRITE_COMMAND, 0);
> > + sg_set_buf(sg, ce, sizeof(*ce));
> > +
> > + mapped = dma_map_sg_attrs(chan->slave, sg, 1, DMA_TO_DEVICE, DMA_PREP_CMD);
> > + if (!mapped) {
> > + kfree(async_desc);
> > + return NULL;
> > + }
> > +
> > + desc->flags |= cpu_to_le16(DESC_FLAG_CMD | flag);
> > + desc->addr = sg_dma_address(sg);
> > + desc->size = sizeof(struct bam_cmd_element);
> > +
> > + vc = &bchan->vc;
> > + vd = &async_desc->vd;
> > +
> > + dma_async_tx_descriptor_init(&vd->tx, &vc->chan);
> > + vd->tx.flags = DMA_PREP_CMD;
> > + vd->tx.desc_free = vchan_tx_desc_free;
> > + vd->tx_result.result = DMA_TRANS_NOERROR;
> > + vd->tx_result.residue = 0;
> > +
> > + cookie = dma_cookie_assign(&vd->tx);
> > + ret = dma_submit_error(cookie);
> > + if (ret)
> > + return NULL;
>
> You are leaking async_desc here.
>
Yeah, not only that but also should unmap the sg here too. Thanks.
> > +
> > + return async_desc;
> > +}
> > +
> > +static int bam_do_setup_pipe_lock(struct bam_chan *bchan, bool lock)
> > +{
> > + struct bam_device *bdev = bchan->bdev;
> > + const struct bam_device_data *bdata = bdev->dev_data;
> > + struct bam_async_desc *lock_desc;
> > + struct bam_cmd_element *ce;
> > + struct scatterlist *sgl;
> > + unsigned long flag;
> > +
> > + lockdep_assert_held(&bchan->vc.lock);
> > +
> > + if (!bdata->pipe_lock_supported || !bchan->scratchpad_addr ||
> > + bchan->slave.direction != DMA_MEM_TO_DEV)
> > + return 0;
> > +
> > + if (lock) {
> > + sgl = &bchan->lock_sg;
> > + ce = &bchan->lock_ce;
> > + flag = DESC_FLAG_LOCK;
> > + } else {
> > + sgl = &bchan->unlock_sg;
> > + ce = &bchan->unlock_ce;
> > + flag = DESC_FLAG_UNLOCK;
> > + }
> > +
> > + lock_desc = bam_make_lock_desc(bchan, sgl, ce, flag);
> > + if (!lock_desc)
> > + return -ENOMEM;
> > +
> > + if (lock)
> > + list_add(&lock_desc->vd.node, &bchan->vc.desc_issued);
> > + else
> > + list_add_tail(&lock_desc->vd.node, &bchan->vc.desc_issued);
> > +
> > + bchan->locked = lock;
>
> What is this flag for?
>
Just a leftover. I'll drop it, thanks.
> >
> > +struct bam_desc_metadata {
> > + phys_addr_t scratchpad_addr;
>
> I think it'd be worth adding a comment for this.
>
Will do.
Bart
^ permalink raw reply
* Re: [PATCH v3 07/10] gpu: nova-core: falcon: introduce `bounded_enum` macro
From: Gary Guo @ 2026-03-23 12:43 UTC (permalink / raw)
To: Alexandre Courbot, Danilo Krummrich, Alice Ryhl, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross
Cc: John Hubbard, Alistair Popple, Joel Fernandes, Timur Tabi,
Zhi Wang, Eliot Courtney, dri-devel, linux-kernel, linux-riscv,
linux-doc, rust-for-linux
In-Reply-To: <20260323-b4-nova-register-v3-7-ae2486ecef1b@nvidia.com>
On Mon Mar 23, 2026 at 11:07 AM GMT, Alexandre Courbot wrote:
> Introduce a powered-up version of our ad-hoc `impl_from_enum_to_u8`
> macro that allows the definition of an enum type associated to a
> `Bounded` of a given width, and provides the `From` and `TryFrom`
> implementations required to use that enum as a register field member.
>
> The next patch will make use of it to convert all falcon registers to
> the kernel register macro.
>
> The macro is unused in this patch: it is introduced ahead-of-time to
> avoid diff mingling in the next patch that would make it difficult to
> review.
>
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpu/nova-core/falcon.rs | 82 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
>
> diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
> index 5a4f7fc85160..5221e4476f90 100644
> --- a/drivers/gpu/nova-core/falcon.rs
> +++ b/drivers/gpu/nova-core/falcon.rs
> @@ -54,6 +54,88 @@ fn from(value: $enum_type) -> Self {
> };
> }
>
> +/// Creates an enum type associated to a `Bounded`, with a `From` conversion to the associated
> +/// `Bounded` and either a `TryFrom` or `From` converting from the associated `Bounded`.
> +// TODO[FPRI]: This is a temporary solution to be replaced with the corresponding derive macros
> +// once they land.
> +#[expect(unused)]
> +macro_rules! bounded_enum {
> + (
> + $(#[doc = $enum_doc:expr])*
> + enum $enum_type:ident with $from_impl:ident<Bounded<$width:ty, $length:literal>> {
> + $( $(#[doc = $variant_doc:expr])* $variant:ident = $value:expr),* $(,)*
> + }
> + ) => {
> + $(#[doc = $enum_doc])*
> + #[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]
> + pub(crate) enum $enum_type {
> + $(
> + $(#[doc = $variant_doc])*
> + $variant = $value
> + ),*
> + }
> +
> + impl From<$enum_type> for Bounded<$width, $length> {
> + fn from(value: $enum_type) -> Self {
> + match value {
> + $($enum_type::$variant => Bounded::<$width, _>::new::<$value>()),*
Hi Alex,
This looks exactly the same as the last version, without out the {} and MAX..
change made (which you mentioned in the cover letter).
Best,
Gary
> + }
> + }
> + }
> +
> + bounded_enum!(@impl_from $enum_type with $from_impl<Bounded<$width, $length>> {
> + $($variant = $value),*
> + });
> + };
> +
> + // `TryFrom` implementation from associated `Bounded` to enum type.
> + (@impl_from $enum_type:ident with TryFrom<Bounded<$width:ty, $length:literal>> {
> + $($variant:ident = $value:expr),* $(,)*
> + }) => {
> + impl TryFrom<Bounded<$width, $length>> for $enum_type {
> + type Error = Error;
> +
> + fn try_from(value: Bounded<$width, $length>) -> Result<Self> {
> + match value.get() {
> + $(
> + $value => Ok($enum_type::$variant),
> + )*
> + _ => Err(EINVAL),
> + }
> + }
> + }
> + };
> +
> + // `From` implementation from associated `Bounded` to enum type. Triggers a `build_error` if
> + // all possible values of the `Bounded` are not covered by the enum type.
> + (@impl_from $enum_type:ident with From<Bounded<$width:ty, $length:literal>> {
> + $($variant:ident = $value:expr),* $(,)*
> + }) => {
> + impl From<Bounded<$width, $length>> for $enum_type {
> + fn from(value: Bounded<$width, $length>) -> Self {
> + $(
> + // Ensure all enum values fit into the `Bounded` type.
> + const { assert!(
> + $value < (1 << $length),
> + "Enum variant doesn't fit into assigned `Bounded` type."
> + ); }
> + )*
> +
> + // Makes the compiler optimizer aware of the possible range of values.
> + let value = value.get() & ((1 << $length) - 1);
> + match value {
> + $(
> + $value => $enum_type::$variant,
> + )*
> + // We land here if the match didn't cover all possible values for the
> + // `Bounded`.
> + _ => build_error!("Enum doesn't cover all values of the `Bounded` type."),
> + }
> + }
> + }
> + }
> +}
> +
> /// Revision number of a falcon core, used in the [`crate::regs::NV_PFALCON_FALCON_HWCFG1`]
> /// register.
> #[repr(u8)]
^ permalink raw reply
* Re: [PATCH V8 3/8] dax: add fsdev.c driver for fs-dax on character dax
From: Jonathan Cameron @ 2026-03-23 12:12 UTC (permalink / raw)
To: John Groves
Cc: Miklos Szeredi, Dan Williams, Bernd Schubert, Alison Schofield,
John Groves, Jonathan Corbet, Shuah Khan, Vishal Verma,
Dave Jiang, Matthew Wilcox, Jan Kara, Alexander Viro,
David Hildenbrand, Christian Brauner, Darrick J . Wong,
Randy Dunlap, Jeff Layton, Amir Goldstein, Stefan Hajnoczi,
Joanne Koong, Josef Bacik, Bagas Sanjaya, Chen Linxuan,
James Morse, Fuad Tabba, Sean Christopherson, Shivank Garg,
Ackerley Tng, Gregory Price, Aravind Ramesh, Ajay Joshi,
venkataravis, linux-doc, linux-kernel, nvdimm, linux-cxl,
linux-fsdevel
In-Reply-To: <ab3nFoKxirEgoS_v@groves.net>
> > > diff --git a/drivers/dax/Makefile b/drivers/dax/Makefile
> > > index 5ed5c39857c8..3bae252fd1bf 100644
> > > --- a/drivers/dax/Makefile
> > > +++ b/drivers/dax/Makefile
> > > @@ -5,10 +5,16 @@ obj-$(CONFIG_DEV_DAX_KMEM) += kmem.o
> > > obj-$(CONFIG_DEV_DAX_PMEM) += dax_pmem.o
> > > obj-$(CONFIG_DEV_DAX_CXL) += dax_cxl.o
> > >
> > > +# fsdev_dax: fs-dax compatible devdax driver (needs DEV_DAX and FS_DAX)
> > > +ifeq ($(CONFIG_FS_DAX),y)
> > > +obj-$(CONFIG_DEV_DAX) += fsdev_dax.o
> > > +endif
> >
> > Why not throw in a new CONFIG_FSDAX_DEV and handle the dependencies
> > in Kconfig?
>
> At one point I had another config parameter, but I'm trying not to
> gratuitously add them. The fsdev driver is pretty small, and including it
> whenever FS_DAX is enabled felt reasonable to me. I'm willing to change it
> if there's a consensus that way.
You can make the build do exactly the same thing with a separate Kconfig
option. Just moves where the dependency tracking is. I'd prefer Kconfig
because that's generally where I'd look for something like this.
Jonathan
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net-next v2 03/13] net: introduce ndo_set_rx_mode_async and dev_rx_mode_work
From: Loktionov, Aleksandr @ 2026-03-23 12:09 UTC (permalink / raw)
To: Stanislav Fomichev, netdev@vger.kernel.org
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, corbet@lwn.net,
skhan@linuxfoundation.org, andrew+netdev@lunn.ch,
michael.chan@broadcom.com, pavan.chebbi@broadcom.com,
Nguyen, Anthony L, Kitszel, Przemyslaw, saeedm@nvidia.com,
tariqt@nvidia.com, mbloch@nvidia.com, alexanderduyck@fb.com,
kernel-team@meta.com, johannes@sipsolutions.net,
sd@queasysnail.net, jianbol@nvidia.com, dtatulea@nvidia.com,
mohsin.bashr@gmail.com, Keller, Jacob E, willemb@google.com,
skhawaja@google.com, bestswngs@gmail.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, linux-rdma@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kselftest@vger.kernel.org,
leon@kernel.org
In-Reply-To: <20260318150305.123900-4-sdf@fomichev.me>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Stanislav Fomichev
> Sent: Wednesday, March 18, 2026 4:03 PM
> To: netdev@vger.kernel.org
> Cc: davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; horms@kernel.org; corbet@lwn.net;
> skhan@linuxfoundation.org; andrew+netdev@lunn.ch;
> michael.chan@broadcom.com; pavan.chebbi@broadcom.com; Nguyen, Anthony
> L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; saeedm@nvidia.com; tariqt@nvidia.com;
> mbloch@nvidia.com; alexanderduyck@fb.com; kernel-team@meta.com;
> johannes@sipsolutions.net; sd@queasysnail.net; jianbol@nvidia.com;
> dtatulea@nvidia.com; sdf@fomichev.me; mohsin.bashr@gmail.com; Keller,
> Jacob E <jacob.e.keller@intel.com>; willemb@google.com;
> skhawaja@google.com; bestswngs@gmail.com; linux-doc@vger.kernel.org;
> linux-kernel@vger.kernel.org; intel-wired-lan@lists.osuosl.org; linux-
> rdma@vger.kernel.org; linux-wireless@vger.kernel.org; linux-
> kselftest@vger.kernel.org; leon@kernel.org
> Subject: [Intel-wired-lan] [PATCH net-next v2 03/13] net: introduce
> ndo_set_rx_mode_async and dev_rx_mode_work
>
> Add ndo_set_rx_mode_async callback that drivers can implement instead
> of the legacy ndo_set_rx_mode. The legacy callback runs under the
> netif_addr_lock spinlock with BHs disabled, preventing drivers from
> sleeping. The async variant runs from a work queue with rtnl_lock and
> netdev_lock_ops held, in fully sleepable context.
>
> When __dev_set_rx_mode() sees ndo_set_rx_mode_async, it schedules
> dev_rx_mode_work instead of calling the driver inline. The work
> function takes two snapshots of each address list (uc/mc) under the
> addr_lock, then drops the lock and calls the driver with the work
> copies. After the driver returns, it reconciles the snapshots back to
> the real lists under the lock.
>
> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
> ---
> Documentation/networking/netdevices.rst | 8 +++
> include/linux/netdevice.h | 20 ++++++
> net/core/dev.c | 94 +++++++++++++++++++++++-
> -
> 3 files changed, 115 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/networking/netdevices.rst
> b/Documentation/networking/netdevices.rst
> index 35704d115312..dc83d78d3b27 100644
> --- a/Documentation/networking/netdevices.rst
> +++ b/Documentation/networking/netdevices.rst
> @@ -289,6 +289,14 @@ struct net_device synchronization rules
> ndo_set_rx_mode:
> Synchronization: netif_addr_lock spinlock.
> Context: BHs disabled
...
>
> -/*
> - * Upload unicast and multicast address lists to device and
> - * configure RX filtering. When the device doesn't support unicast
> - * filtering it is put in promiscuous mode while unicast addresses
> - * are present.
> +static void dev_rx_mode_work(struct work_struct *work) {
> + struct net_device *dev = container_of(work, struct net_device,
> + rx_mode_work);
> + struct netdev_hw_addr_list uc_snap, mc_snap, uc_ref, mc_ref;
> + const struct net_device_ops *ops = dev->netdev_ops;
> + int err;
> +
> + __hw_addr_init(&uc_snap);
> + __hw_addr_init(&mc_snap);
> + __hw_addr_init(&uc_ref);
> + __hw_addr_init(&mc_ref);
> +
> + rtnl_lock();
> + netdev_lock_ops(dev);
> +
> + if (!netif_up_and_present(dev))
> + goto out;
> +
> + if (ops->ndo_set_rx_mode_async) {
> + netif_addr_lock_bh(dev);
> +
> + err = __hw_addr_list_snapshot(&uc_snap, &dev->uc,
> + dev->addr_len);
> + if (!err)
> + err = __hw_addr_list_snapshot(&uc_ref, &dev->uc,
> + dev->addr_len);
> + if (!err)
> + err = __hw_addr_list_snapshot(&mc_snap, &dev->mc,
> + dev->addr_len);
> + if (!err)
> + err = __hw_addr_list_snapshot(&mc_ref, &dev->mc,
> + dev->addr_len);
> + netif_addr_unlock_bh(dev);
> +
> + if (err) {
> + __hw_addr_flush(&uc_snap);
> + __hw_addr_flush(&uc_ref);
> + __hw_addr_flush(&mc_snap);
Shouldn't here go cleanup for symmetry?
__hw_addr_flush(&mc_ref);
> + goto out;
> + }
> +
> + ops->ndo_set_rx_mode_async(dev, &uc_snap, &mc_snap);
> +
> + netif_addr_lock_bh(dev);
> + __hw_addr_list_reconcile(&dev->uc, &uc_snap,
> + &uc_ref, dev->addr_len);
> + __hw_addr_list_reconcile(&dev->mc, &mc_snap,
> + &mc_ref, dev->addr_len);
> + netif_addr_unlock_bh(dev);
> + }
> +
> +out:
> + netdev_unlock_ops(dev);
> + rtnl_unlock();
> +}
...
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH RFC v2 9/9] docs: iio: add documentation for ad9910 driver
From: Rodrigo Alencar @ 2026-03-23 11:58 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan
In-Reply-To: <20260322173434.23d2ee0d@jic23-huawei>
On 26/03/22 05:34PM, Jonathan Cameron wrote:
> On Wed, 18 Mar 2026 17:56:09 +0000
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
>
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > Add documentation for the AD9910 DDS IIO driver, which describes channels,
> > DDS modes, attributes and ABI usage examples.
> >
> > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
...
> > +Channel hierarchy
> > +=================
> > +
> > +The driver exposes the following IIO output channels, each identified by a
> > +unique channel number and a human-readable label:
> > +
> > +* ``out_altvoltage100``: ``phy``: Physical output: system clock and profile control
> > +
> > + * ``out_altvoltage110``: ``single_tone``: Single tone mode: per-profile
> > + frequency, phase, amplitude
> > +
> > + * ``out_altvoltage120``: ``parallel_port``: Parallel port modulation: enable
> > + and offset/scale parameters
> > +
> > + * ``out_altvoltage130``: ``digital_ramp_generator``: DRG control: enable,
> > + destination, operating mode
> > +
> > + * ``out_altvoltage131``: ``digital_ramp_up``: DRG ramp-up parameters:
> > + limits, step sizes, ramp rate
> > + * ``out_altvoltage132``: ``digital_ramp_down``: DRG ramp-down parameters:
> > + limits, step sizes, ramp rate
> > +
> > + * ``out_altvoltage140``: ``ram_control``: RAM playback: enable, destination,
> > + operating mode, address range
> > +
> > + * ``out_altvoltage150``: ``output_shift_keying``: OSK: enable, amplitude
> > + scale, ramp rate, auto/manual control
> > +
> > +The ``phy`` channel is the root of the hierarchy. Changing its
> > +``sampling_frequency`` reconfigures the system clock (SYSCLK) which affects all
> > +other channels. The ``profile`` attribute on this channel selects the active
> > +hardware profile (0-7) used by the single tone and RAM channels.
> I asked out this profile thing in one of the other patches. Key to me is
> that how we write non active profiles? The most similar thing we've seen
> in the past has been setting other frequencies for FSK or phases for PSK or
> more mundane DC DAC output that are symbol based. (often an external signal)
Yes, not allowing to configure a non-active profile at this point.
Initially was not seeing this as a problem, but would you think different
channels for each profiles should be created? e.g.:
- out_altvoltage111 ... out_altvoltage118 for single tone profiles; and
- out_altvoltage141 .. out_altvoltage148 for RAM profiles
That would not remove the need for something like the profile attribute.
> For those we have added an additional index so we can see which symbol we
> are changing parameters for. Here it might need to be done in the channel
> numbering. I'm not sure.
>
> > +
> > +All mode-specific channels (parallel port, DRG, RAM, OSK) have an ``enable``
> > +attribute. The DRG and RAM channels additionally have ``destination`` and
> > +``operating_mode`` attributes that configure which DDS core parameter is
> > +modulated and how.
>
> I wonder if we flatten things out and have separate channels for each type
> of modulation. Might lead to a more standard looking interfaces. We don't really
> have a standard path to control one type of thing feeding another, whereas
> we do have simple 'enable' interfaces.
...
> > +RAM mode
> > +--------
> > +
> > +The AD9910 contains a 1024 x 32-bit RAM that can be loaded with waveform data
> > +and played back to modulate frequency, phase, amplitude, or polar (phase +
> > +amplitude) parameters.
> > +
> > +RAM control channel attributes
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +.. flat-table::
> > + :header-rows: 1
> > +
> > + * - Attribute
> > + - Unit
> > + - Description
> > +
> > + * - ``out_altvoltage140_en``
> > + - boolean
> > + - Enable/disable RAM playback. Toggling swaps profile registers between
> > + single tone and RAM configurations across all 8 profiles.
...
> > + * - ``out_altvoltage140_address_start``
> Do we need this flexibility to set the start? We needed a length, but
> if we want different effective start can just load a different image.
There is one image being loaded into the entire RAM and each profile may choose
from wich sample it starts and ends its address ramp.
The profiles can have those address ranges to overlap or not, then I suppose
considering different images would just complicate things.
> > + - integer
> > + - Start address for the active profile. Range [0, 1023]. Cannot be
> > + changed while RAM mode is enabled. If set above current end address,
> > + end address is automatically adjusted.
> > +
...
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox