* Re: [PATCH 5/7] arm64: dts: qcom: kaanapali: Add label properties to CoreSight devices
From: Konrad Dybcio @ 2026-04-14 10:15 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-add-label-to-coresight-device-v1-5-d71a6759dbc2@oss.qualcomm.com>
On 4/10/26 5:08 AM, Jie Gan wrote:
> Add label properties to TPDM nodes in the kaanapali device tree to
> provide human-readable identifiers for each CoreSight device. These
> labels allow userspace tools and the CoreSight framework to identify
> devices by name rather than by base address.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 6/7] arm64: dts: qcom: sm8750: Add label properties to CoreSight devices
From: Konrad Dybcio @ 2026-04-14 10:19 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-add-label-to-coresight-device-v1-6-d71a6759dbc2@oss.qualcomm.com>
On 4/10/26 5:08 AM, Jie Gan wrote:
> Add label properties to TPDM and CTI nodes in the sm8750 device tree to
> provide human-readable identifiers for each CoreSight device. These
> labels allow userspace tools and the CoreSight framework to identify
> devices by name rather than by base address.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
[...]
> tpdm-cdsp-llm {
> compatible = "qcom,coresight-static-tpdm";
> + label = "tpdm_cdsp_llm";
> qcom,cmb-element-bits = <32>;
>
> out-ports {
> @@ -6814,6 +6839,7 @@ tpdm_cdsp_llm_out: endpoint {
>
> tpdm-cdsp-llm2 {
> compatible = "qcom,coresight-static-tpdm";
> + label = "tpdm_cdsp_llm2";
> qcom,cmb-element-bits = <32>;
>
> out-ports {
> @@ -6827,6 +6853,7 @@ tpdm_cdsp_llm2_out: endpoint {
>
> tpdm-modem1 {
> compatible = "qcom,coresight-static-tpdm";
> + label = "tpdm_modem_1";
Please fix the extra \t
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] media: i2c: add os02g10 image sensor driver
From: Tarang Raval @ 2026-04-14 10:19 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Elgin Perumbilly, sakari.ailus@linux.intel.com,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hans Verkuil, Hans de Goede, Vladimir Zapolskiy,
Mehdi Djait, Benjamin Mugnier, Sylvain Petinot,
Hardevsinh Palaniya, Jingjing Xiong, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260414095727.GF4061@killaraus.ideasonboard.com>
Hi Laurent,
> On Tue, Apr 14, 2026 at 09:43:32AM +0000, Elgin Perumbilly wrote:
> > Hi Laurent,
> >
> > > I sent a review comment on v1.
> > >
> > > On Tue, Apr 14, 2026 at 02:19:45PM +0530, Elgin Perumbilly wrote:
> > > > Add a v4l2 subdevice driver for the Omnivision os02g10 sensor.
> > > >
> > > > The Omnivision os02g10 is a CMOS image sensor with an active array size of
> > > > 1920 x 1080.
> > > >
> > > > The following features are supported:
> > > > - Manual exposure an gain control support
> > > > - vblank/hblank control support
> > > > - vflip/hflip control support
> > > > - Test pattern control support
> > > > - Supported resolution: 1920 x 1080 @ 30fps (SBGGR10)
> > > >
> > > > Signed-off-by: Elgin Perumbilly <elgin.perumbilly@siliconsignals.io>
> > > > Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io>
> > > > ---
> > > > MAINTAINERS | 1 +
> > > > drivers/media/i2c/Kconfig | 10 +
> > > > drivers/media/i2c/Makefile | 1 +
> > > > drivers/media/i2c/os02g10.c | 1039 +++++++++++++++++++++++++++++++++++
> > > > 4 files changed, 1051 insertions(+)
> > > > create mode 100644 drivers/media/i2c/os02g10.c
> >
> > I have added a new function, os02g10_set_framefmt, which dynamically sets
> > the mode register.
> >
> > Please let me know if I have missed anything or if further changes are
> > needed.
>
> You also need to drop the supported_modes array, and implement support
> for .set_selection().
Are you suggesting that we should drop the array below?
static const struct os02g10_mode supported_modes[] = {
{
.width = 1920,
.height = 1080,
.vts_def = 1246,
.hts_def = 1082,
.exp_def = 1100,
.x_start = 2,
.y_start = 6,
},
};
If we remove this, how would we provide mode-specific parameters such as VTS?
Best Regards,
Tarang
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos850: Add SRAM node
From: Tudor Ambarus @ 2026-04-14 10:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alexey Klimov, Sam Protsenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Juan Yescas, Peter Griffin, André Draszik
In-Reply-To: <4c6a92e0-15a1-4f82-afc9-542f5ad9d2df@kernel.org>
Hi!
On 4/14/26 12:08 PM, Krzysztof Kozlowski wrote:
> On 14/04/2026 11:00, Alexey Klimov wrote:
>> On Mon Apr 13, 2026 at 4:23 PM BST, Krzysztof Kozlowski wrote:
>>> On 13/04/2026 16:52, Alexey Klimov wrote:
>>>> SRAM is used by the ACPM protocol to retrieve the ACPM channels
>>>> information and configuration data. Add the SRAM node.
>>>>
>>>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>>>> ---
>>>> arch/arm64/boot/dts/exynos/exynos850.dtsi | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
>>>> index cb55015c8dce..cf4a6168846c 100644
>>>> --- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
>>>> +++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
>>>> @@ -910,6 +910,14 @@ spi_2: spi@11d20000 {
>>>> };
>>>> };
>>>> };
>>>> +
>>>> + apm_sram: sram@2039000 {
>>>> + compatible = "mmio-sram";
>>>> + reg = <0x0 0x2039000 0x40000>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + ranges = <0x0 0x0 0x2039000 0x40000>;
>>>
>>> You miss here children.
>>
>> Thank you! I guess I should convert it to smth like this:
>>
>> apm_sram: sram@2039000 {
>> compatible = "mmio-sram";
>> reg = <0x0 0x2039000 0x40000>;
>> ranges = <0x0 0x0 0x2039000 0x40000>;
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> acpm_sram_region: sram-section@0 {
>> reg = <0x0 0x40000>;
>
> This covers entire block, so feels pointless. Maybe requirement of
> children should be dropped. What's the point of having children? Why
> does the driver need them?
>
>> };
>> };
>>
>> And then later reference shmem = &acpm_sram_region from acpm node.
>>
>>> Also, 'ranges' should be after 'reg'.
>>
>> Thanks, will fix this.
>>
>> FWIW this commit is a copy of commit 48e7821b26904
>> https://lore.kernel.org/r/20250207-gs101-acpm-dt-v4-1-230ba8663a2d@linaro.org
>
>
> Huh, we should fix that one as well.
>
On gs101, likely on e850 too, ACPM parses the SRAM and discovers at runtime where
the TX/RX queue offsets are in SRAM. So we can't define static partitions in DT.
I remember that I thought about extending the SRAM driver to add dynamic
partitions (clients to request the mmio-sram driver to create partitions at
runtime), but it was just ACPM that's using SRAM, so I didn't need it.
Cheers,
ta
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: hamoa: Add label properties to CoreSight devices
From: Konrad Dybcio @ 2026-04-14 10:22 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-add-label-to-coresight-device-v1-7-d71a6759dbc2@oss.qualcomm.com>
On 4/10/26 5:08 AM, Jie Gan wrote:
> Add label properties to TPDM and CTI nodes in the hamoa device tree to
> provide human-readable identifiers for each CoreSight device. These
> labels allow userspace tools and the CoreSight framework to identify
> devices by name rather than by base address.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v11 2/4] crypto: spacc - Add SPAcc ahash support
From: Pavitrakumar Managutte @ 2026-04-14 10:28 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto, linux-kernel, devicetree, robh, conor+dt,
Ruud.Derwig, manjunath.hadli, adityak, navami.telsang, bhoomikak
In-Reply-To: <CALxtO0nFEG2Lm18Fnb=YVQfy4-Qjb5+WtOxsHNOwYTy2Kzyb4g@mail.gmail.com>
Hi Herbert,
If the above snip looks good, I can push that and some more code
clean-ups/improvements as part of V12 patchset. Do let me know.
Below are the code fixes and improvements
1. Multi-device safety handling - All packed up inside priv
2. Minor code polishes
3. memzero_explicit inside setkey, spacc_compute_xcbc_key etc.
4. Algo registration clean-ups
Warm regards,
PK
On Thu, Apr 2, 2026 at 1:30 PM Pavitrakumar Managutte
<pavitrakumarm@vayavyalabs.com> wrote:
>
> Hi Herbert,
> As per your inputs, I've replaced the do_shash switch to use
> lib/crypto single-shot calls for SHA-1, SHA-224, SHA-256, SHA-384,
> SHA-512, and MD5.
>
> However, SM3 does not have a single-shot library API in lib/crypto yet
> — include/crypto/sm3.h exposes sm3_init() and sm3_block_generic(),
> with no sm3()/sm3_update()/sm3_final() equivalents.
>
> For now, I've retained do_shash only for the SM3 case. Would this be
> acceptable, or would you prefer a different approach?
>
>
> Code snippet below for your reference
> ============== snip start ================
>
> switch (salg->mode->id) {
> case CRYPTO_MODE_HMAC_SHA224:
> sha224(key, keylen, tctx->ipad);
> break;
>
> case CRYPTO_MODE_HMAC_SHA256:
> sha256(key, keylen, tctx->ipad);
> break;
>
> case CRYPTO_MODE_HMAC_SHA384:
> sha384(key, keylen, tctx->ipad);
> break;
>
> case CRYPTO_MODE_HMAC_SHA512:
> sha512(key, keylen, tctx->ipad);
> break;
>
> case CRYPTO_MODE_HMAC_MD5:
> md5(key, keylen, tctx->ipad);
> break;
>
> case CRYPTO_MODE_HMAC_SHA1:
> sha1(key, keylen, tctx->ipad);
> break;
>
> case CRYPTO_MODE_HMAC_SM3:
> rc = do_shash(salg->dev, "sm3", tctx->ipad, key,
> keylen);
> if (rc < 0) {
> dev_err(salg->dev,
> "ERR: %d computing shash for sm3\n", rc);
> return -EIO;
> }
> break;
>
> default:
> return -EINVAL;
> }
>
> ============== snip end ================
>
> Warm Regards,
> PK
>
>
>
> On Fri, Mar 27, 2026 at 2:50 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >
> > On Wed, Mar 18, 2026 at 12:48:06PM +0530, Pavitrakumar Managutte wrote:
> > >
> > > + switch (salg->mode->id) {
> > > + case CRYPTO_MODE_HMAC_SHA224:
> > > + rc = do_shash(salg->dev, "sha224", tctx->ipad, key,
> > > + keylen);
> > > + break;
> >
> > Since you're doing a giant switch statement anyway, please convert
> > this to use lib/crypto instead of shash.
> >
> > Thanks,
> > --
> > Email: Herbert Xu <herbert@gondor.apana.org.au>
> > Home Page: http://gondor.apana.org.au/~herbert/
> > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Chen-Yu Tsai @ 2026-04-14 10:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Manivannan Sadhasivam, Manivannan Sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski
In-Reply-To: <ad36pIu-0dutL7Nk@ashevche-desk.local>
On Tue, Apr 14, 2026 at 4:28 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Apr 14, 2026 at 01:03:19PM +0800, Chen-Yu Tsai wrote:
> > On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > > > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
>
> ...
>
> > > > > - Given that this connector actually represents two devices, how do I
> > > > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > > > Does wakeup-source even work at this point?
> > > >
> > > > You can't use the DT property since the devices are not described in DT
> > > > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > > > wakeup.
> >
> > I see. I think not being able to specify generic properties for the devices
> > on the connector is going to be a bit problematic.
>
> This is nature of the open-connectors, especially on the busses that are
> hotpluggable, like PCIe. We never know what is connected there _ahead_.
I believe what you mean by "hotpluggable" is "user replaceable".
> In other words you can't describe in DT something that may not exist.
But this is actually doable with the PCIe slot representation. The
properties are put in the device node for the slot. If no card is
actually inserted in the slot, then no device is created, and the
device node is left as not associated with anything.
It's just that for this new M.2 E-key connector, there aren't separate
nodes for each interface. And the system doesn't associate the device
node with the device, because it's no longer a child node of the
controller or hierarchy, but connected over the OF graph.
Moving over to the E-key connector representation seems like one step
forward and one step backward in descriptive ability. We gain proper
power sequencing, but lose generic properties.
The latter part is solvable, but we likely need child nodes under the
connector for the different interfaces. Properties that make sense for
one type might not make sense for another.
Thanks
ChenYu
P.S. We could also just add child device nodes under the controller to
put the generic properties, but that's splitting the description into
multiple parts. Let's not go there if at all possible.
^ permalink raw reply
* RE: [PATCH v7 4/6] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-14 10:28 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <1170956f-da05-4280-990f-64306ca905c2@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Saturday, April 11, 2026 12:01 AM
...
> >
> > static const struct ad4691_chip_info ad4694_chip_info = {
> > .name = "ad4694",
> > .max_rate = 1 * HZ_PER_MHZ,
> > .sw_info = &ad4693_sw_info,
> > + .offload_info = &ad4693_offload_info,
> > +};
> > +
> > +struct ad4691_offload_state {
> > + struct spi_offload *spi;
>
> I would call this "offload" or "instance". "spi" is usally the SPI
> device handle.
I thought about this too, will implement it as offload then.
>
> > + struct spi_offload_trigger *trigger;
> > + u64 trigger_hz;
> > + u8 tx_cmd[17][2];
> > + u8 tx_reset[4];
> > };
> >
>
> ...
>
> > +
> > +static int ad4691_cnv_burst_offload_buffer_predisable(struct iio_dev
> *indio_dev)
> > +{
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > + struct ad4691_offload_state *offload = st->offload;
> > + int ret;
> > +
> > + spi_offload_trigger_disable(offload->spi, offload->trigger);
> > +
> > + ret = ad4691_sampling_enable(st, false);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_write(st->regmap, AD4691_STD_SEQ_CONFIG,
> > + AD4691_SEQ_ALL_CHANNELS_OFF);
>
> Why this extra step? We don't have it when unwinding in the
> error path of the postenable function.
This is a mistake from my end. Perhaps this could be removed since
the sequencer is over-written upon new buffers/raw readings anyway.
>
> > + if (ret)
> > + return ret;
> > +
> > + spi_unoptimize_message(&st->scan_msg);
> > +
> > + return ad4691_exit_conversion_mode(st);
> > +}
> > +
> > +static const struct iio_buffer_setup_ops
> ad4691_cnv_burst_offload_buffer_setup_ops = {
> > + .postenable = &ad4691_cnv_burst_offload_buffer_postenable,
> > + .predisable = &ad4691_cnv_burst_offload_buffer_predisable,
> > +};
> > +
> > static ssize_t sampling_frequency_show(struct device *dev,
> > struct device_attribute *attr,
> > char *buf)
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: monaco: Add iface clock and power domain for ice sdhc
From: Konrad Dybcio @ 2026-04-14 10:30 UTC (permalink / raw)
To: Kuldeep Singh, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260409-ice_emmc_clock_addition-v2-2-90bbcc057361@oss.qualcomm.com>
On 4/9/26 10:31 AM, Kuldeep Singh wrote:
> Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
> for its own resources. Before accessing ICE hardware during probe, to
> avoid potential unclocked register access issues (when clk_ignore_unused
> is not passed on the kernel command line), in addition to the 'core'
> clock the 'iface' clock should also be turned on by the driver. This can
> only be done if power domain is enabled.
>
> Specify both power domain and the iface clock.
>
> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: kodiak: Add iface clock and power domain for ice sdhc
From: Konrad Dybcio @ 2026-04-14 10:30 UTC (permalink / raw)
To: Kuldeep Singh, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260409-ice_emmc_clock_addition-v2-1-90bbcc057361@oss.qualcomm.com>
On 4/9/26 10:31 AM, Kuldeep Singh wrote:
> Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
> for its own resources. Before accessing ICE hardware during probe, to
> avoid potential unclocked register access issues (when clk_ignore_unused
> is not passed on the kernel command line), in addition to the 'core'
> clock the 'iface' clock should also be turned on by the driver. This can
> only be done if power domain is enabled.
>
> Specify both power domain and the iface clock.
>
> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* RE: [PATCH v7 5/6] iio: adc: ad4691: add oversampling support
From: Sabau, Radu bogdan @ 2026-04-14 10:32 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <742b1821-9103-414e-a860-c2e8d5406e35@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Saturday, April 11, 2026 12:15 AM
...
> >
> > osc_idx = FIELD_GET(AD4691_OSC_FREQ_MASK, reg_val);
> > - /* Wait 2 oscillator periods for the conversion to complete. */
> > - period_us = DIV_ROUND_UP(2UL * USEC_PER_SEC,
> ad4691_osc_freqs_Hz[osc_idx]);
> > + /* Wait osr oscillator periods for all accumulator samples to complete.
> */
>
> Why did we need to way 2 before and only 1 now when OSR == 1?
>
You are right, that extra period should exist when reading raw not dependent
on the OSR. If OSR = 4 then we should wait 5 just to make sure we are reading
a correct result, since the single_shot_read doesn’t use any interrupts as the
buffers do.
^ permalink raw reply
* Re: [PATCH v2 2/2] media: i2c: add os02g10 image sensor driver
From: Laurent Pinchart @ 2026-04-14 10:33 UTC (permalink / raw)
To: Tarang Raval
Cc: Elgin Perumbilly, sakari.ailus@linux.intel.com,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hans Verkuil, Hans de Goede, Vladimir Zapolskiy,
Mehdi Djait, Benjamin Mugnier, Sylvain Petinot,
Hardevsinh Palaniya, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <PN3P287MB1829155B216E557C7DF7B6778B252@PN3P287MB1829.INDP287.PROD.OUTLOOK.COM>
On Tue, Apr 14, 2026 at 10:19:23AM +0000, Tarang Raval wrote:
> > On Tue, Apr 14, 2026 at 09:43:32AM +0000, Elgin Perumbilly wrote:
> > > > On Tue, Apr 14, 2026 at 02:19:45PM +0530, Elgin Perumbilly wrote:
> > > > > Add a v4l2 subdevice driver for the Omnivision os02g10 sensor.
> > > > >
> > > > > The Omnivision os02g10 is a CMOS image sensor with an active array size of
> > > > > 1920 x 1080.
> > > > >
> > > > > The following features are supported:
> > > > > - Manual exposure an gain control support
> > > > > - vblank/hblank control support
> > > > > - vflip/hflip control support
> > > > > - Test pattern control support
> > > > > - Supported resolution: 1920 x 1080 @ 30fps (SBGGR10)
> > > > >
> > > > > Signed-off-by: Elgin Perumbilly <elgin.perumbilly@siliconsignals.io>
> > > > > Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io>
> > > > > ---
> > > > > MAINTAINERS | 1 +
> > > > > drivers/media/i2c/Kconfig | 10 +
> > > > > drivers/media/i2c/Makefile | 1 +
> > > > > drivers/media/i2c/os02g10.c | 1039 +++++++++++++++++++++++++++++++++++
> > > > > 4 files changed, 1051 insertions(+)
> > > > > create mode 100644 drivers/media/i2c/os02g10.c
> > >
> > > I have added a new function, os02g10_set_framefmt, which dynamically sets
> > > the mode register.
> > >
> > > Please let me know if I have missed anything or if further changes are
> > > needed.
> >
> > You also need to drop the supported_modes array, and implement support
> > for .set_selection().
>
> Are you suggesting that we should drop the array below?
Correct.
> static const struct os02g10_mode supported_modes[] = {
> {
> .width = 1920,
> .height = 1080,
> .vts_def = 1246,
> .hts_def = 1082,
> .exp_def = 1100,
> .x_start = 2,
> .y_start = 6,
> },
> };
>
> If we remove this, how would we provide mode-specific parameters such as VTS?
Those should be computed by the driver based on the format and crop
rectangle configured by userspace.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 0/3] Mediatek Genio 510/700-EVK: add CPU power supplies
From: Louis-Alexis Eyraud @ 2026-04-14 10:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: kernel, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Louis-Alexis Eyraud
This series adds for the Mediatek Genio 510-EVK (MT8370) and 700-EVK
(MT8390) boards the CPU power supply definitions in their devicetree
that are missing for all their CPU cores.
On the boards, the big core power is supplied by a MT6319 (sub PMIC)
and little core power by a MT6365 (main PMIC).
Patch 1 adds the MT6319 PMIC support that was not yet enabled for these
boards.
Patch 2 adds the CPU power supplies definitions that are common to both
Genio 510 and 700 EVK boards, and patch 3 adds the Genio 700-EVK
specific ones.
The series has been tested on Genio 510-EVK board with a kernel based
on linux-next (tag: next-20260410).
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
Louis-Alexis Eyraud (3):
arm64: dts: mediatek: mt8390-genio-common: add MT6319 PMIC support
arm64: dts: mediatek: mt8390-genio-common: add CPU power supplies
arm64: dts: mediatek: mt8390-genio-700-evk: add specific CPU power supplies
.../boot/dts/mediatek/mt8390-genio-700-evk.dts | 7 +++
.../boot/dts/mediatek/mt8390-genio-common.dtsi | 68 ++++++++++++++++++++++
2 files changed, 75 insertions(+)
---
base-commit: f244905cd8cff7a7249cd3dac8a366e02d61ad4f
change-id: 20260413-mtk-g510-700-cpu-supplies-41a78a6bf175
Best regards,
--
Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
^ permalink raw reply
* [PATCH 1/3] arm64: dts: mediatek: mt8390-genio-common: add MT6319 PMIC support
From: Louis-Alexis Eyraud @ 2026-04-14 10:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: kernel, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Louis-Alexis Eyraud
In-Reply-To: <20260414-mtk-g510-700-cpu-supplies-v1-0-3b8313e5ca8d@collabora.com>
Mediatek Genio 510 and 700-EVK boards integrate a MT6319 PMIC, powered
by the board system power rail (VSYS) and connected to the SPMI
interface. It provides buck regulators for CPU core power supplies in
particular.
Add the needed nodes in the board common dtsi to enable its support.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
.../boot/dts/mediatek/mt8390-genio-common.dtsi | 44 ++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi b/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi
index 2062506f6cc5..aab474d6c5f8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi
@@ -1364,6 +1364,50 @@ &spi2 {
status = "okay";
};
+&spmi {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ pmic@6 {
+ compatible = "mediatek,mt6319-regulator", "mediatek,mt6315-regulator";
+ reg = <0x6 SPMI_USID>;
+
+ pvdd1-supply = <®_vsys>;
+ pvdd2-supply = <®_vsys>;
+ pvdd3-supply = <®_vsys>;
+ pvdd4-supply = <®_vsys>;
+
+ regulators {
+ mt6319_vbuck1: vbuck1 {
+ regulator-name = "dvdd_proc_b";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1193750>;
+ regulator-enable-ramp-delay = <256>;
+ regulator-allowed-modes = <0 1 2>;
+ regulator-always-on;
+ };
+
+ vbuck3 {
+ regulator-name = "avdd2_emi";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1193750>;
+ regulator-enable-ramp-delay = <256>;
+ regulator-allowed-modes = <0 1 2>;
+ regulator-always-on;
+ };
+
+ vbuck4 {
+ regulator-name = "avddq_emi";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1193750>;
+ regulator-enable-ramp-delay = <256>;
+ regulator-allowed-modes = <0 1 2>;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
&uart0 {
pinctrl-0 = <&uart0_pins>;
pinctrl-names = "default";
--
2.53.0
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: mediatek: mt8390-genio-common: add CPU power supplies
From: Louis-Alexis Eyraud @ 2026-04-14 10:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: kernel, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Louis-Alexis Eyraud
In-Reply-To: <20260414-mtk-g510-700-cpu-supplies-v1-0-3b8313e5ca8d@collabora.com>
Mediatek Genio 510-EVK (MT8370) and 700-EVK (MT8390) devicetrees are
missing power supply definitions for all their CPU cores.
On the boards, the big core power is supplied by a MT6319 (sub PMIC),
and little core power by a MT6365 (main PMIC).
MT8370 and MT8390 SoC have the same core type (little cores are ARM
Cortex A55, big ones are A72), the same big core number (2) but MT8390
SoC has more little cores (6) than MT8370 SoC (only 4).
To handle the little core number difference, add in the board common
dtsi the power supply definitions for the common CPU core nodes (0-3,
6 and 7).
The power supplies for the additional MT8390 CPU core nodes (4 and 5)
will be added for the Genio 700 in a separate commit.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
.../boot/dts/mediatek/mt8390-genio-common.dtsi | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi b/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi
index aab474d6c5f8..9ebb222a877f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi
@@ -285,6 +285,30 @@ &afe {
status = "okay";
};
+&cpu0 {
+ cpu-supply = <&mt6359_vcore_buck_reg>;
+};
+
+&cpu1 {
+ cpu-supply = <&mt6359_vcore_buck_reg>;
+};
+
+&cpu2 {
+ cpu-supply = <&mt6359_vcore_buck_reg>;
+};
+
+&cpu3 {
+ cpu-supply = <&mt6359_vcore_buck_reg>;
+};
+
+&cpu6 {
+ cpu-supply = <&mt6319_vbuck1>;
+};
+
+&cpu7 {
+ cpu-supply = <&mt6319_vbuck1>;
+};
+
&disp_dsi0 {
#address-cells = <1>;
#size-cells = <0>;
--
2.53.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: mediatek: mt8390-genio-700-evk: add specific CPU power supplies
From: Louis-Alexis Eyraud @ 2026-04-14 10:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: kernel, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Louis-Alexis Eyraud
In-Reply-To: <20260414-mtk-g510-700-cpu-supplies-v1-0-3b8313e5ca8d@collabora.com>
Add power supply definitions for the additional little CPU core nodes,
that cannot be factorized in the board common dtsi due to little core
number difference between MT8390 SoC (used by this board) and MT8370
SoC (used by Genio 510-EVK).
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8390-genio-700-evk.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8390-genio-700-evk.dts b/arch/arm64/boot/dts/mediatek/mt8390-genio-700-evk.dts
index 612336713a64..0d5a75efb2ee 100644
--- a/arch/arm64/boot/dts/mediatek/mt8390-genio-700-evk.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8390-genio-700-evk.dts
@@ -21,3 +21,10 @@ memory@40000000 {
};
};
+&cpu4 {
+ cpu-supply = <&mt6359_vcore_buck_reg>;
+};
+
+&cpu5 {
+ cpu-supply = <&mt6359_vcore_buck_reg>;
+};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v11 4/7] media: qcom: camss: Add support to populate sub-devices
From: Konrad Dybcio @ 2026-04-14 10:33 UTC (permalink / raw)
To: Bryan O'Donoghue, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Robert Foss, Todor Tomov, Mauro Carvalho Chehab, Konrad Dybcio,
Vladimir Zapolskiy, Bryan O'Donoghue
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski
In-Reply-To: <20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-4-5b93415be6dd@linaro.org>
On 3/26/26 2:28 AM, Bryan O'Donoghue wrote:
> Use devm_of_platform_populate() to populate subs in the tree.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> drivers/media/platform/qcom/camss/camss.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 00b87fd9afbd8..66ea057291f6d 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -16,6 +16,7 @@
> #include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/of_graph.h>
> +#include <linux/of_platform.h>
> #include <linux/pm_runtime.h>
> #include <linux/pm_domain.h>
> #include <linux/slab.h>
> @@ -4964,6 +4965,8 @@ static int camss_probe(struct platform_device *pdev)
> if (!camss)
> return -ENOMEM;
>
> + devm_of_platform_populate(dev);
If you want the camss probe to fail if any of the PHYs' probe fails,
check the return value
Note that this doesn't necessarily have to be the case and I can see
arguments for both approaches
Konrad
^ permalink raw reply
* Re: [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: Bui Duc Phuc @ 2026-04-14 10:40 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: kuninori.morimoto.gx, broonie, lgirdwood, robh, krzk+dt, conor+dt,
geert+renesas, magnus.damm, perex, tiwai, linux-sound,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260414-funky-sincere-polecat-20b0bf@quoll>
Hi Krzysztof,
Thank you for your detailed review and feedback.
> Flexible is not allowed. Provide reasons for exception.
I understand and will remove this approach and replace it with
explicit valid clock combinations.
> This goes to the "clocks:"
Understood, I will move the description to "clocks".
> > + minItems: 1
> > + items:
> > + - const: own
> > + - &fsi_all_clks
>
> I don't understand this syntax.
Understood, I will drop the YAML anchor and use explicit constraints instead.
I will update it to the following structure:
clocks:
description: |
Clock driving the FSI Controller :
- "own": Main FSI module clock (must be first and always present)
- "spu": SPU bus/bridge clock. On R8A7740, this clock must be
enabled to allow register access as the FSI block is connected
behind the SPU bus.
- "icka" / "ickb": CPG DIV6 functional clocks for FSI port A/B
- "diva"/"divb": Internal FSI dividers for port A/B used for
audio clock generation
- "xcka"/"xckb": External clock inputs for FSI port A/B
provided by the board
minItems: 1
maxItems: 8
clock-names:
minItems: 1
maxItems: 8
allOf:
- $ref: dai-common.yaml#
- if:
properties:
compatible:
contains:
const: renesas,fsi2-r8a7740
then:
properties:
clock-names:
oneOf:
- items:
- const: own
- const: spu
- items:
- const: own
- const: spu
- const: ickb
- const: divb
Best regards,
Phuc
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: reset: imx8mq: Add _N suffix to IMX8MQ_RESET_MIPI_CSI*_RESET
From: Robby Cai @ 2026-04-14 10:46 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: p.zabel, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam,
devicetree, kernel, imx, linux-arm-kernel, linux-kernel,
aisheng.dong
In-Reply-To: <20260401-simple-dragonfly-of-will-fedc8c@quoll>
On Wed, Apr 01, 2026 at 09:41:48AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Mar 31, 2026 at 06:13:30PM +0800, Robby Cai wrote:
> > The assert logic of the MIPI CSI reset signals is active-low on i.MX8MQ,
> > but the existing names do not indicate this explicitly. To improve
> > consistency and clarity, append the _N suffix to all
> > IMX8MQ_RESET_MIPI_CSI*_RESET definitions. The deprecated
> > IMX8MQ_RESET_MIPI_CSI*_RESET versions remain temporarily for DT ABI
> > compatibility and will be removed at an appropriate time in the future.
> >
> > Signed-off-by: Robby Cai <robby.cai@nxp.com>
> > ---
> > include/dt-bindings/reset/imx8mq-reset.h | 18 ++++++++++++------
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/dt-bindings/reset/imx8mq-reset.h b/include/dt-bindings/reset/imx8mq-reset.h
> > index 705870693ec2..83a155dbbd4a 100644
> > --- a/include/dt-bindings/reset/imx8mq-reset.h
> > +++ b/include/dt-bindings/reset/imx8mq-reset.h
> > @@ -46,12 +46,18 @@
> > #define IMX8MQ_RESET_PCIEPHY2_PERST 35 /* i.MX8MM/i.MX8MN does NOT support */
> > #define IMX8MQ_RESET_PCIE2_CTRL_APPS_EN 36 /* i.MX8MM/i.MX8MN does NOT support */
> > #define IMX8MQ_RESET_PCIE2_CTRL_APPS_TURNOFF 37 /* i.MX8MM/i.MX8MN does NOT support */
> > -#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET 38 /* i.MX8MM/i.MX8MN does NOT support */
> > -#define IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET 39 /* i.MX8MM/i.MX8MN does NOT support */
> > -#define IMX8MQ_RESET_MIPI_CSI1_ESC_RESET 40 /* i.MX8MM/i.MX8MN does NOT support */
> > -#define IMX8MQ_RESET_MIPI_CSI2_CORE_RESET 41 /* i.MX8MM/i.MX8MN does NOT support */
> > -#define IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET 42 /* i.MX8MM/i.MX8MN does NOT support */
> > -#define IMX8MQ_RESET_MIPI_CSI2_ESC_RESET 43 /* i.MX8MM/i.MX8MN does NOT support */
> > +#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET 38 /* Deprecated. Use *_RESET_N instead */
> > +#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET_N 38 /* i.MX8MM/i.MX8MN does NOT support */
>
> That's quite a churn for no need. The entire point of these values being
> the binding is that it describes the ABI for SW and DTS, not your
> hardware registers.
>
> Whether signal is active low or high is kind of irrelevant. Linux uses
> it exactly the same way.
>
The original naming was taken from the reference manual at the time.
The upcoming RM revision will clarify that these resets are active-low and
use the _N suffix, consistent with MIPI DSI.
However, I agree that the DT binding and naming need not be changed.
I'll keep the existing binding and naming, and address this in v2 by fixing the
reset logic in the driver only.
Regards,
Robby
^ permalink raw reply
* Re: [PATCH 01/35] dt-bindings: qcom,pdc: Tighten reg to single APSS DRV region
From: Konrad Dybcio @ 2026-04-14 10:47 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Dmitry Baryshkov, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
cros-qcom-dts-watchers, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260414082426.fhkgwpjth7a6hzxe@hu-mojha-hyd.qualcomm.com>
On 4/14/26 10:24 AM, Mukesh Ojha wrote:
> On Mon, Apr 13, 2026 at 10:23:59AM +0200, Konrad Dybcio wrote:
>> On 4/11/26 4:32 PM, Dmitry Baryshkov wrote:
>>> On Sat, Apr 11, 2026 at 12:10:38AM +0530, Mukesh Ojha wrote:
>>>> The PDC has multiple DRV regions, each sized 0x10000, where each region
>>>> serves a specific client in the system. Linux only needs access to the
>>>
>>> Nit: there are other OS than Linux. Would you rather point out that
>>> other DRV regions are to be used by ... what?
>>
>> TZ, HYP, HLOS, CPUCP..
>
> Thanks for pitching in..
>
>>
>> I'm wondering if we can make use of the HYP one on e.g. Glymur, to
>> parallelize accesses (and whether that would bring any practical
>> benefit).
>
> I mean, Ideally, It makes sense to utilize extra 0x10000 to use or just
> to use the hypervisor one for Glymur.
Which one does the UEFI use?
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] mmc: dw_mmc: implement option for configuring DMA threshold
From: Kaustabh Chakraborty @ 2026-04-14 10:49 UTC (permalink / raw)
To: Shawn Lin, Kaustabh Chakraborty, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaehoon Chung,
Krzysztof Kozlowski, Alim Akhtar
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc
In-Reply-To: <cec99f99-5ac4-7f0d-8e2a-947edfef8930@rock-chips.com>
On 2026-04-14 16:50 +08:00, Shawn Lin wrote:
> 在 2026/04/14 星期二 16:36, Kaustabh Chakraborty 写道:
>> Some controllers, such as certain Exynos SDIO ones, are unable to
>> perform DMA transfers of small amount of bytes properly. Following the
>> device tree schema, implement the property to define the DMA transfer
>> threshold (from a hard coded value of 16 bytes) so that lesser number of
>> bytes can be transferred safely skipping DMA in such controllers. The
>> value of 16 bytes stays as the default for controllers which do not
>> define it. This value can be overridden by implementation-specific init
>> sequences.
>>
>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> ---
>> drivers/mmc/host/dw_mmc.c | 5 +++--
>> drivers/mmc/host/dw_mmc.h | 2 ++
>> 2 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 20193ee7b73eb..9dd9fed4ccf49 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -40,7 +40,6 @@
>> SDMMC_INT_RESP_ERR | SDMMC_INT_HLE)
>> #define DW_MCI_ERROR_FLAGS (DW_MCI_DATA_ERROR_FLAGS | \
>> DW_MCI_CMD_ERROR_FLAGS)
>> -#define DW_MCI_DMA_THRESHOLD 16
>>
>> #define DW_MCI_FREQ_MAX 200000000 /* unit: HZ */
>> #define DW_MCI_FREQ_MIN 100000 /* unit: HZ */
>> @@ -821,7 +820,7 @@ static int dw_mci_pre_dma_transfer(struct dw_mci *host,
>> * non-word-aligned buffers or lengths. Also, we don't bother
>> * with all the DMA setup overhead for short transfers.
>> */
>> - if (data->blocks * data->blksz < DW_MCI_DMA_THRESHOLD)
>> + if (data->blocks * data->blksz < host->dma_threshold)
>> return -EINVAL;
>>
>> if (data->blksz & 3)
>> @@ -3245,6 +3244,8 @@ int dw_mci_probe(struct dw_mci *host)
>> goto err_clk_ciu;
>> }
>>
>> + host->dma_threshold = 16;
>
> I'd prefer to set it in dw_mci_alloc_host() instead of picking up
> a random place to put it, for better code management.
Okay, that function is in -next I see.
>
>> +
>> if (host->rstc) {
>> reset_control_assert(host->rstc);
>> usleep_range(10, 50);
>> diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
>> index 42e58be74ce09..fc7601fba849f 100644
>> --- a/drivers/mmc/host/dw_mmc.h
>> +++ b/drivers/mmc/host/dw_mmc.h
>> @@ -164,6 +164,8 @@ struct dw_mci {
>> void __iomem *fifo_reg;
>> u32 data_addr_override;
>> bool wm_aligned;
>> + /* Configurable data byte threshold value for DMA transfer. */
>
> No here, there is a long section of comment before struct dw_mci{ } that
> describes each member of it, please add it there.
Ah, you mean the documenting comment. Shouldn't have missed in either
way.
>
>> + u32 dma_threshold;
>>
>> struct scatterlist *sg;
>> struct sg_mapping_iter sg_miter;
>>
^ permalink raw reply
* Re: [PATCH v2 1/6] ASoC: renesas: fsi: Add shared SPU clock support
From: Bui Duc Phuc @ 2026-04-14 10:53 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <87v7dupfx6.wl-kuninori.morimoto.gx@renesas.com>
Hi,
Thanks for the review and explanation.
> You added clk_spu in this patch, but not touched.
> When I checked whole patch-set, you initialize it at [4/6], but [2/6] is
> using it. Maybe it works, but is strange.
You are right, clk_spu is used before being initialized.
I was not careful with the patch ordering and only ensured the series
worked as a whole.
I understand now and will fix the ordering accordingly.
Best regards,
Phuc
^ permalink raw reply
* Re: [PATCH 32/35] arm64: dts: qcom: monaco: Drop unused second PDC reg entry
From: Krzysztof Kozlowski @ 2026-04-14 10:54 UTC (permalink / raw)
To: Mukesh Ojha, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: cros-qcom-dts-watchers, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-33-mukesh.ojha@oss.qualcomm.com>
On 10/04/2026 20:41, Mukesh Ojha wrote:
> The PDC driver only maps the first register region (APSS DRV) via
> of_address_to_resource(node, 0, ...). The second reg entry was never
> accessed by the driver and can be removed.
This is not a correct reason, see writing bindings.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 35/35] arm64: dts: qcom: talos: Drop unused second PDC reg entry
From: Krzysztof Kozlowski @ 2026-04-14 10:55 UTC (permalink / raw)
To: Mukesh Ojha, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: cros-qcom-dts-watchers, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-36-mukesh.ojha@oss.qualcomm.com>
On 10/04/2026 20:41, Mukesh Ojha wrote:
> The PDC driver only maps the first register region (APSS DRV) via
> of_address_to_resource(node, 0, ...). The second reg entry was never
> accessed by the driver and can be removed.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
Same comment as for other patches like that. This is not a valid reason
or at least not sufficiently explained. Either hardware has it or has
not. Why is driver relevant here? That must be explained in commit msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 31/35] arm64: dts: qcom: milos: Drop unused second PDC reg entry
From: Krzysztof Kozlowski @ 2026-04-14 10:57 UTC (permalink / raw)
To: Mukesh Ojha, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: cros-qcom-dts-watchers, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-32-mukesh.ojha@oss.qualcomm.com>
On 10/04/2026 20:41, Mukesh Ojha wrote:
> The PDC driver only maps the first register region (APSS DRV) via
> of_address_to_resource(node, 0, ...). The second reg entry was never
> accessed by the driver and can be removed.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/milos.dtsi | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> index 71941e6f49bf..a3c2ac8ca675 100644
> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> @@ -1564,8 +1564,7 @@ dispcc: clock-controller@af00000 {
>
> pdc: interrupt-controller@b220000 {
> compatible = "qcom,milos-pdc", "qcom,pdc";
> - reg = <0x0 0x0b220000 0x0 0x10000>,
You already changed this line in previous patch. Fixing one property in
DTS to match hardware is one commit.
Best regards,
Krzysztof
^ 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