* Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype
From: Rodrigo Alencar @ 2026-03-30 12:49 UTC (permalink / raw)
To: Rodrigo Alencar, Andy Shevchenko
Cc: Petr Mladek, rodrigo.alencar, linux-kernel, linux-iio, devicetree,
linux-doc, Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <x34d7jz7be4ommjh6efx5mcq5pbpellykwuyrqayr4ske3lywf@wh46mu3anmcz>
On 26/03/27 03:17PM, Rodrigo Alencar wrote:
> On 26/03/27 12:21PM, Andy Shevchenko wrote:
> > On Fri, Mar 27, 2026 at 10:11:56AM +0000, Rodrigo Alencar wrote:
> > > On 26/03/27 11:17AM, Andy Shevchenko wrote:
> > > > On Fri, Mar 27, 2026 at 09:45:17AM +0100, Petr Mladek wrote:
> > > > > On Fri 2026-03-20 16:27:27, Rodrigo Alencar via B4 Relay wrote:
...
> > > > Maybe we want to have kstrtof32() and kstrtof64() for these two cases?
> > > >
> > > > With that we will always consider the fraction part as 32- or 64-bit,
> > > > imply floor() on the fraction for the sake of simplicity and require
> > > > it to be NUL-terminated with possible trailing '\n'.
> > >
> > > I think this is a good idea, but calling it float or fixed point itself
> > > is a bit confusing as float often refers to the IEEE 754 standard and
> > > fixed point types is often expressed in Q-format.
> >
> > Yeah... I am lack of better naming.
>
> decimals is the name, but they are often represented as:
>
> DECIMAL = INT * 10^X + FRAC
>
> in a single 64-bit number, which would be fine for my end use case.
> However IIO decimal fixed point parsing is out there for quite some time a
> lot of drivers use that. The interface often relies on breaking parsed values
> into an integer array (for standard attributes int val and int val2 are expected).
Thinking about this again and in IIO drivers we end up doing something like:
val64 = (u64)val * MICRO + val2;
so that drivers often work with scaled versions of the decimal value.
then, would it make sense to have a function that already outputs such value?
That would allow to have more freedom over the 64-bit split between integer
and fractional parts.
As a draft:
static int _kstrtodec64(const char *s, unsigned int scale, u64 *res)
{
u64 _res = 0, _frac = 0;
unsigned int rv;
if (*s != '.') {
rv = _parse_integer(s, 10, &_res);
if (rv & KSTRTOX_OVERFLOW)
return -ERANGE;
if (rv == 0)
return -EINVAL;
s += rv;
}
if (*s == '.') {
s++;
rv = _parse_integer_limit(s, 10, &_frac, scale);
if (rv & KSTRTOX_OVERFLOW)
return -ERANGE;
if (rv == 0)
return -EINVAL;
s += rv;
if (rv < scale)
_frac *= int_pow(10, scale - rv);
while (isdigit(*s)) /* truncate */
s++;
}
if (*s == '\n')
s++;
if (*s)
return -EINVAL;
if (check_mul_overflow(_res, int_pow(10, scale), &_res) ||
check_add_overflow(_res, _frac, &_res))
return -ERANGE;
*res = _res;
return 0;
}
noinline
int kstrtoudec64(const char *s, unsigned int scale, u64 *res)
{
if (s[0] == '+')
s++;
return _kstrtodec64(s, scale, res);
}
EXPORT_SYMBOL(kstrtoudec64);
noinline
int kstrtosdec64(const char *s, unsigned int scale, s64 *res)
{
u64 tmp;
int rv;
if (s[0] == '-') {
rv = _kstrtodec64(s + 1, scale, &tmp);
if (rv < 0)
return rv;
if ((s64)-tmp > 0)
return -ERANGE;
*res = -tmp;
} else {
rv = kstrtoudec64(s, scale, &tmp);
if (rv < 0)
return rv;
if ((s64)tmp < 0)
return -ERANGE;
*res = tmp;
}
return 0;
}
EXPORT_SYMBOL(kstrtosdec64);
e.g., kstrtosdec64() or kstrtoudec64() parses "3.1415" with scale 3 into 3141
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH 5/7] dt-bindings: cache: ax45mp-cache: rename ax45mp-cache to llcache
From: Rob Herring (Arm) @ 2026-03-30 12:51 UTC (permalink / raw)
To: Hui Min Mina Chou
Cc: krzk+dt, jonathan.cameron, pjw, palmer, conor+dt, aou, alex749,
az70021, linux-renesas-soc, linux-kernel,
prabhakar.mahadev-lad.rj, devicetree, linux-riscv, geert+renesas,
alex, magnus.damm, ben717, tim609
In-Reply-To: <20260330102724.1012470-6-minachou@andestech.com>
On Mon, 30 Mar 2026 18:27:22 +0800, Hui Min Mina Chou wrote:
> The AX45MP-specific cache binding is renamed to a generic Last Level
> Cache (LLC) schema, as the driver now supports more Andes CPU cores
> beyond just AX45MP.
>
> Updated compatible strings:
> andestech,qilai-ax45mp-cache -> andestech,qilai-llcache
> renesas,r9a07g043f-ax45mp-cache -> renesas,r9a07g043f-llcache
> andestech,ax45mp-cache -> andestech,llcache
>
> Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
> ---
> ...ache.yaml => andestech,andes-llcache.yaml} | 20 +++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
> rename Documentation/devicetree/bindings/cache/{andestech,ax45mp-cache.yaml => andestech,andes-llcache.yaml} (76%)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/cache/andestech,andes-llcache.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename
$id: http://devicetree.org/schemas/cache/andestech,llcache.yaml
file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/cache/andestech,andes-llcache.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260330102724.1012470-6-minachou@andestech.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 5/7] dt-bindings: cache: ax45mp-cache: rename ax45mp-cache to llcache
From: Krzysztof Kozlowski @ 2026-03-30 13:00 UTC (permalink / raw)
To: Hui Min Mina Chou, pjw, palmer, aou, alex, geert+renesas,
prabhakar.mahadev-lad.rj, magnus.damm, ben717, robh, krzk+dt,
conor+dt, jonathan.cameron, devicetree, linux-riscv, linux-kernel,
linux-renesas-soc
Cc: tim609, alex749, az70021
In-Reply-To: <20260330102724.1012470-6-minachou@andestech.com>
On 30/03/2026 12:27, Hui Min Mina Chou wrote:
> The AX45MP-specific cache binding is renamed to a generic Last Level
> Cache (LLC) schema, as the driver now supports more Andes CPU cores
> beyond just AX45MP.
>
> Updated compatible strings:
> andestech,qilai-ax45mp-cache -> andestech,qilai-llcache
> renesas,r9a07g043f-ax45mp-cache -> renesas,r9a07g043f-llcache
> andestech,ax45mp-cache -> andestech,llcache
Why? No explanations and that is clear ABI break.
=
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/7] cache: ax45mp_cache: refactor cache driver for generic Andes platform support
From: Krzysztof Kozlowski @ 2026-03-30 13:01 UTC (permalink / raw)
To: Hui Min Mina Chou, pjw, palmer, aou, alex, geert+renesas,
prabhakar.mahadev-lad.rj, magnus.damm, ben717, robh, krzk+dt,
conor+dt, jonathan.cameron, devicetree, linux-riscv, linux-kernel,
linux-renesas-soc
Cc: tim609, alex749, az70021, charles
In-Reply-To: <20260330102724.1012470-2-minachou@andestech.com>
On 30/03/2026 12:27, Hui Min Mina Chou wrote:
> -
> -static const struct riscv_nonstd_cache_ops ax45mp_cmo_ops __initdata = {
> - .wback = &ax45mp_dma_cache_wback,
> - .inv = &ax45mp_dma_cache_inv,
> - .wback_inv = &ax45mp_dma_cache_wback_inv,
> -};
> -
> -static const struct of_device_id ax45mp_cache_ids[] = {
> - { .compatible = "andestech,ax45mp-cache" },
NAK, actual ABI break.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/7] cache: andes_llcache: refactor initialization and cache operations
From: Krzysztof Kozlowski @ 2026-03-30 13:02 UTC (permalink / raw)
To: Hui Min Mina Chou, pjw, palmer, aou, alex, geert+renesas,
prabhakar.mahadev-lad.rj, magnus.damm, ben717, robh, krzk+dt,
conor+dt, jonathan.cameron, devicetree, linux-riscv, linux-kernel,
linux-renesas-soc
Cc: tim609, alex749, az70021
In-Reply-To: <20260330102724.1012470-3-minachou@andestech.com>
On 30/03/2026 12:27, Hui Min Mina Chou wrote:
> This patch cleans up the Andes LLC cache driver:
> - improved error handling in andes_cache_init() by using goto labels
> - updated andes_dma_cache_inv/wback() to check for !size instead of
> start == end
> - cache-line-size mismatch from an error to a warning
> - Use ALIGN and ALIGN_DOWN helpers instead of the alignment logic in
> andes_dma_cache_inv() and andes_dma_cache_wback().
Please read submitting patches document. One thing per commit with
proper rationale WHY you are doing this.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/7] dts: riscv: update cache compatible strings to LLC
From: Krzysztof Kozlowski @ 2026-03-30 13:03 UTC (permalink / raw)
To: Hui Min Mina Chou, pjw, palmer, aou, alex, geert+renesas,
prabhakar.mahadev-lad.rj, magnus.damm, ben717, robh, krzk+dt,
conor+dt, jonathan.cameron, devicetree, linux-riscv, linux-kernel,
linux-renesas-soc
Cc: tim609, alex749, az70021
In-Reply-To: <20260330102724.1012470-7-minachou@andestech.com>
On 30/03/2026 12:27, Hui Min Mina Chou wrote:
> Update the cache driver compatible strings from ax45mp-cache to llcache
Driver? DTS is for hardware.
> for both Qilai and RZ/Five platforms.
> This follows the Andes cache driver refactoring to use more generic
Nope, driver changes cannot be the reason to change DTS.
> Last Level Cache (LLC) naming.
>
> Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
> ---
> arch/riscv/boot/dts/andes/qilai.dtsi | 4 ++--
> arch/riscv/boot/dts/renesas/r9a07g043f.dtsi | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/boot/dts/andes/qilai.dtsi b/arch/riscv/boot/dts/andes/qilai.dtsi
> index de3de32f8c39..a7436cbf6f69 100644
> --- a/arch/riscv/boot/dts/andes/qilai.dtsi
> +++ b/arch/riscv/boot/dts/andes/qilai.dtsi
> @@ -137,8 +137,8 @@ plmt: timer@100000 {
> };
>
> l2_cache: cache-controller@200000 {
> - compatible = "andestech,qilai-ax45mp-cache",
> - "andestech,ax45mp-cache", "cache";
> + compatible = "andestech,qilai-llcache",
> + "andestech,llcache", "cache";
NAK, actual impact on users.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Add Eliza QMP PHY
From: Abel Vesa @ 2026-03-30 13:05 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260330-eliza-phy-usb-dp-combo-v1-1-2ec11e793a08@oss.qualcomm.com>
On 26-03-30 15:19:12, Abel Vesa wrote:
> The QMP combo PHY found on Eliza SoC is fully compatible with the one
> found on SM8650.
>
> So document its compatible string and use the SM8650 as fallback.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Please ignore this one.
It has been sent already here:
https://lore.kernel.org/all/20260330-eliza-phy-usb-dp-combo-v1-1-2ec11e793a08@oss.qualcomm.com/
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Dikshita Agarwal @ 2026-03-30 13:06 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Jonathan Marek,
Ulf Hansson, Rafael J. Wysocki, Bryan O'Donoghue,
Vikash Garodia, Mauro Carvalho Chehab, Stanimir Varbanov,
Abhinav Kumar, Hans Verkuil, Stefan Schmidt, Konrad Dybcio,
Bryan O'Donoghue, Dikshita Agarwal, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm, linux-media,
Mauro Carvalho Chehab
In-Reply-To: <x5gv6dxdum5klzfjyo7xjqull6o43okkmkn7avssg26epbvrz6@z2brpssbk7iv>
On 3/30/2026 4:45 PM, Dmitry Baryshkov wrote:
> On Mon, Mar 30, 2026 at 10:55:02AM +0530, Dikshita Agarwal wrote:
>>
>>
>> On 2/9/2026 7:02 AM, Dmitry Baryshkov wrote:
>>> On SM8250 most of the video clocks are powered by the MMCX domain, while
>>> the PLL is powered on by the MX domain. Extend the driver to support
>>> scaling both power domains, while keeping compatibility with the
>>> existing DTs, which define only the MX domain.
>>>
>>> Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC")
>>> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> ---
>>> drivers/media/platform/qcom/iris/iris_platform_gen1.c | 2 +-
>>> drivers/media/platform/qcom/iris/iris_probe.c | 7 +++++++
>>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>> index df8e6bf9430e..aa71f7f53ee3 100644
>>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>> @@ -281,7 +281,7 @@ static const struct bw_info sm8250_bw_table_dec[] = {
>>>
>>> static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
>>>
>>> -static const char * const sm8250_opp_pd_table[] = { "mx" };
>>> +static const char * const sm8250_opp_pd_table[] = { "mx", "mmcx" };
>>>
>>> static const struct platform_clk_data sm8250_clk_table[] = {
>>> {IRIS_AXI_CLK, "iface" },
>>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
>>> index 7b612ad37e4f..74ec81e3d622 100644
>>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
>>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
>>> @@ -64,6 +64,13 @@ static int iris_init_power_domains(struct iris_core *core)
>>> return ret;
>>>
>>> ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data, &core->opp_pmdomain_tbl);
>>> + /* backwards compatibility for incomplete ABI SM8250 */
>>> + if (ret == -ENODEV &&
>>> + of_device_is_compatible(core->dev->of_node, "qcom,sm8250-venus")) {
>>> + iris_opp_pd_data.num_pd_names--;
>>> + ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data,
>>> + &core->opp_pmdomain_tbl);
>>> + }
>>> if (ret < 0)
>>> return ret;
>>>
>>>
>>
>> Hitting below compilation error on latest kernel
>>
>> drivers/media/platform/qcom/iris/iris_probe.c: In function
>> ‘iris_init_power_domains’:
>> drivers/media/platform/qcom/iris/iris_probe.c:71:46: error: decrement of
>> read-only member ‘num_pd_names’
>> 71 | iris_opp_pd_data.num_pd_names--;
>
> See commit 7ad7f43e568b ("pmdomain: de-constify fields struct
> dev_pm_domain_attach_data")
Ack, Thanks!
Regards,
Dikshita
>
>>
>> Could you please check and fix.
>>
>> Thanks,
>> Dikshita
>
^ permalink raw reply
* Re: [PATCH v5 1/4] usb: port: track the disabled state
From: Greg Kroah-Hartman @ 2026-03-30 13:15 UTC (permalink / raw)
To: Marco Felsch
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Fabio Estevam,
Matthias Kaehlcke, Liam Girdwood, Mark Brown, linux-usb,
linux-kernel, devicetree, kernel
In-Reply-To: <mavc4ului42mdozzfwxd6zfa5b664umlqe5dal2r6knnilbi5a@ubnxauwhnoue>
On Fri, Mar 20, 2026 at 11:16:43PM +0100, Marco Felsch wrote:
> On 26-03-11, Greg Kroah-Hartman wrote:
> > On Mon, Feb 23, 2026 at 12:27:34PM +0100, Marco Felsch wrote:
> > > The disable state isn't tracked at the moment, instead the state is
> > > directly passed to the hub driver. Change this behavior to only trigger
> > > the hub if a state change happened. Exit early in case of no state
> > > changes but don't return an error.
> > >
> > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
>
> ...
>
> > > #define to_usb_port(_dev) \
> > > diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> > > index 44e38f922bc553adee64b35c536dfd4154a42d8a..86e9d6d0c0f505782569565fde8e4a46b06b8b4d 100644
> > > --- a/drivers/usb/core/port.c
> > > +++ b/drivers/usb/core/port.c
> > > @@ -117,6 +117,10 @@ static ssize_t disable_store(struct device *dev, struct device_attribute *attr,
> > > if (rc)
> > > return rc;
> > >
> > > + /* Early quit if no change was detected */
> > > + if (port_dev->disabled == disabled)
> > > + return count;
> > > +
> >
> > This will change behavior where someone tells the port to be enabled
> > again, when it already is. Is that ok?
>
> That's the whole purpose of this patch. Can you please elaborate why
> someone wants to enable or disbale a port more than once in a row?
I have given up trying to understand why users do what users do :)
^ permalink raw reply
* Re: [PATCH v1 3/6] arm64: dts: qcom: talos: Add QSPI support
From: Konrad Dybcio @ 2026-03-30 13:19 UTC (permalink / raw)
To: Viken Dadhaniya, Dmitry Baryshkov
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20062190-609a-4977-99be-c27df90ff321@oss.qualcomm.com>
On 3/30/26 1:23 PM, Viken Dadhaniya wrote:
>
>
> On 3/25/2026 3:02 PM, Konrad Dybcio wrote:
>> On 3/24/26 9:51 PM, Dmitry Baryshkov wrote:
>>> On Tue, Mar 24, 2026 at 06:43:20PM +0530, Viken Dadhaniya wrote:
>>>> The Talos (QCS615) platform includes a QSPI controller used for accessing
>>>> external flash storage. Add the QSPI OPP table, TLMM pinmux entries, and
>>>> the QSPI controller node to enable support for this hardware.
>>>>
>>>> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/talos.dtsi | 80 +++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 80 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
>>>> index 75716b4a58d6..fd727924b8ca 100644
>>>> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
>>>> @@ -530,6 +530,25 @@ cdsp_smp2p_in: slave-kernel {
>>>>
>>>> };
>>>>
>>>> + qspi_opp_table: opp-table-qspi {
>>>
>>> Why is it not defined inside the QSPI device itself?
>>
>> The QSPI device has #address-cells = <1>, so we'd get:
>>
>> Warning (spi_bus_reg): /soc@0/spi@88dc000/opp-table-qspi: missing or empty reg property
>>
>> Konrad
>
> Yes, I am seeing the same warning when the OPP table is placed inline
> under the QSPI node.
>
> Given that opp-table nodes are not addressable bus devices and therefore
> do not define a reg property, what would be your preferred way to model
> this while keeping the DT warning‑free?
>
> Would placing the OPP table as a sibling of the QSPI node (for example
> under the same &soc scope) and referencing it via operating-points-v2 be
> acceptable in this case, even though there is only a single QSPI instance?
I personally don't mind it being in the place where the current version
of the patch puts it, Krzysztof?
Konrad
^ permalink raw reply
* Re: [PATCH 3/5] arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
From: Krzysztof Kozlowski @ 2026-03-30 13:21 UTC (permalink / raw)
To: Akashdeep Kaur, praneeth, nm, vigneshr, kristo, robh, krzk+dt,
conor+dt, rafael, viresh.kumar, linux-arm-kernel, devicetree,
linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <20260330120105.2985200-4-a-kaur@ti.com>
On 30/03/2026 14:01, Akashdeep Kaur wrote:
> Link CPU OPP table to k3-socinfo driver for dependency tracking.
>
> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> index b6e5eee99370..6d1459e9ea71 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
> @@ -109,6 +109,7 @@ a53_opp_table: opp-table {
> compatible = "operating-points-v2-ti-cpu";
> opp-shared;
> syscon = <&opp_efuse_table>;
> + ti,soc-info = <&chipid>;
You should have tested this before sending. It obviously fails checks.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/3] Add USB support for Kaanapali
From: Bjorn Andersson @ 2026-03-30 13:21 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260329175249.2946508-1-krishna.kurapati@oss.qualcomm.com>
On Sun, Mar 29, 2026 at 11:22:46PM +0530, Krishna Kurapati wrote:
> Add support for the PHYs and controllers used for USB on Kaanapali SoCs.
>
> V1 of this was a consolidated series of many functionlities on Kaanapali.
> The first patch is patch-6 from v1 unchanges. The second and third patches
> are parts of MTP and QRD specific changes (patches 14 and 16) and commit
> text modified to indicate mtp and qrd specific changes are being made.
>
> Ronak is the original author of the patches. Kept Jingyi's and mine SoB
> (with no CDB) since we just rebased and send the patches in v1 and v2.
>
That's the correct way to do it.
> Since SoCCP changes are not acked yet, enabling only device mode.
I'm sure it clear to you what this mean, but for everyone else: what
SoCCP changes and what do you mean "acked"?
Regards,
Bjorn
>
> Changes in v2:
> - Sent USB specific changes instead of all MTP and QRD specific changes
>
> Link to v1:
> https://lore.kernel.org/all/20250924-knp-dts-v1-0-3fdbc4b9e1b1@oss.qualcomm.com/
>
> Ronak Raheja (3):
> arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
> arm64: dts: qcom: kaanpaali: Add USB support for MTP platform
> arm64: dts: qcom: kaanpaali: Add USB support for QRD platform
>
> arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 27 ++++
> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 27 ++++
> arch/arm64/boot/dts/qcom/kaanapali.dtsi | 154 +++++++++++++++++++++
> 3 files changed, 208 insertions(+)
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Krzysztof Kozlowski @ 2026-03-30 13:22 UTC (permalink / raw)
To: Akashdeep Kaur, praneeth, nm, vigneshr, kristo, robh, krzk+dt,
conor+dt, rafael, viresh.kumar, linux-arm-kernel, devicetree,
linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <20260330120105.2985200-6-a-kaur@ti.com>
On 30/03/2026 14:01, Akashdeep Kaur wrote:
> opp_data->cpu_dev = get_cpu_device(0);
> if (!opp_data->cpu_dev) {
> @@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
> if (ret)
> goto fail_put_node;
>
> + /* Create device link to k3-socinfo if specified in DT */
> + if (opp_data->soc_data == &am625_soc_data ||
> + opp_data->soc_data == &am62a7_soc_data ||
> + opp_data->soc_data == &am62l3_soc_data ||
> + opp_data->soc_data == &am62p5_soc_data) {
> + struct device_node *socinfo_np;
> +
> + socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
Undocumented ABI.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/4] drm/panel: simple: add Waveshare LCD panels
From: Dmitry Baryshkov @ 2026-03-30 13:25 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec
Cc: dri-devel, devicetree, linux-kernel
Waveshare have a serie of DSI panel kits with the DPI or LVDS panel
being attached to the DSI2DPI or DSI2LVDS bridge. Commit 80b0eb11f8e0
("dt-bindings: display: panel: Add waveshare DPI panel support")
described two of them in the bindings and commit 46be11b678e0
("drm/panel: simple: Add Waveshare 13.3" panel support") added
definitions for one of those panels. Add support for the rest of them.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Dmitry Baryshkov (4):
dt-bindings: display: waveshare,dsp2dpi: describe DSI2LVDS setup
drm/bridge: waveshare-dsi: support DSI LCD kits with LVDS panels
dt-bindings: display: panel: add Waveshare LCD panels
drm/panel: simple: add Waveshare LCD panels
.../bindings/display/bridge/waveshare,dsi2dpi.yaml | 4 +-
.../bindings/display/panel/panel-simple.yaml | 28 ++
drivers/gpu/drm/bridge/waveshare-dsi.c | 5 +-
drivers/gpu/drm/panel/panel-simple.c | 381 +++++++++++++++++++++
4 files changed, 415 insertions(+), 3 deletions(-)
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260330-ws-lcd-b65c03c5ac17
Best regards,
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH 1/4] dt-bindings: display: waveshare,dsp2dpi: describe DSI2LVDS setup
From: Dmitry Baryshkov @ 2026-03-30 13:25 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260330-ws-lcd-v1-0-309834a435c0@oss.qualcomm.com>
Several the Waveshare DSI LCD panel kits use DSI2LVDS ICN6202 bridge
together with the LVDS panels. Define new compatible for the on-kit
bridge setup (it is not defailed and it uses Waveshare prefix since the
rest of the integration details are not known).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
.../devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml b/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml
index 3820dd7e11af..0d9372fd2ff9 100644
--- a/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml
@@ -14,7 +14,9 @@ description:
properties:
compatible:
- const: waveshare,dsi2dpi
+ enum:
+ - waveshare,dsi2dpi
+ - waveshare,dsi2lvds
reg:
maxItems: 1
--
2.47.3
^ permalink raw reply related
* [PATCH 2/4] drm/bridge: waveshare-dsi: support DSI LCD kits with LVDS panels
From: Dmitry Baryshkov @ 2026-03-30 13:25 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260330-ws-lcd-v1-0-309834a435c0@oss.qualcomm.com>
Several Waveshare DSI LCD kits use LVDS panels and the ICN6202 DSI2LVDS
bridge. Support that setup by handling waveshare,dsi2lvds compatible.
The only difference with the existing waveshare,dsi2dpi is the bridge's
output type (LVDS vs DPI).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/waveshare-dsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/waveshare-dsi.c b/drivers/gpu/drm/bridge/waveshare-dsi.c
index 32d40414adb9..ded57f298d64 100644
--- a/drivers/gpu/drm/bridge/waveshare-dsi.c
+++ b/drivers/gpu/drm/bridge/waveshare-dsi.c
@@ -177,7 +177,7 @@ static int ws_bridge_probe(struct i2c_client *i2c)
regmap_write(ws->reg_map, 0xc2, 0x01);
regmap_write(ws->reg_map, 0xac, 0x01);
- ws->bridge.type = DRM_MODE_CONNECTOR_DPI;
+ ws->bridge.type = (uintptr_t)i2c_get_match_data(i2c);
ws->bridge.of_node = dev->of_node;
devm_drm_bridge_add(dev, &ws->bridge);
@@ -185,7 +185,8 @@ static int ws_bridge_probe(struct i2c_client *i2c)
}
static const struct of_device_id ws_bridge_of_ids[] = {
- {.compatible = "waveshare,dsi2dpi",},
+ {.compatible = "waveshare,dsi2dpi", .data = (void *)DRM_MODE_CONNECTOR_DPI, },
+ {.compatible = "waveshare,dsi2lvds", .data = (void *)DRM_MODE_CONNECTOR_LVDS, },
{ }
};
--
2.47.3
^ permalink raw reply related
* [PATCH 3/4] dt-bindings: display: panel: add Waveshare LCD panels
From: Dmitry Baryshkov @ 2026-03-30 13:25 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260330-ws-lcd-v1-0-309834a435c0@oss.qualcomm.com>
Waveshare has a family of LVDS / DPI panels bundled with the DSI2DPI or
DSI2LVDS bridge. The bridge and the rest of the logic are covered by the
waveshare,dsi2dpi compatible. The bindings already include several
entries for the panels from this series (waveshare,13.3inch-panel,
waveshare,7.0inch-c-panel). Define compatible strings for the rest of
the panels from that series.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
.../bindings/display/panel/panel-simple.yaml | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 9b8fa03f7cbc..c9ac59e04118 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -343,10 +343,38 @@ properties:
- vivax,tpc9150-panel
# VXT 800x480 color TFT LCD panel
- vxt,vl050-8048nt-c01
+ # Waveshare 10.1" WXGA (1280x800) LCD panel
+ - waveshare,10.1inch-c-panel
+ # Waveshare 11.9" (320x1480) LCD panel
+ - waveshare,11.9inch-panel
# Waveshare 13.3" FHD (1920x1080) LCD panel
- waveshare,13.3inch-panel
+ # Waveshare 2.8" VGA (480x640) LCD panel
+ - waveshare,2.8inch-panel
+ # Waveshare 3.4" (800x800) LCD panel
+ - waveshare,3.4inch-c-panel
+ # Waveshare 4.0" WVGA (480x800) LCD panel
+ - waveshare,4.0inch-panel
+ # Waveshare 4.0" (720x720) LCD panel
+ - waveshare,4.0inch-c-panel
+ # Waveshare 5.0" WSVGA (1024x600) LCD panel
+ - waveshare,5.0inch-c-panel
+ # Waveshare 5.0" HD 720p (720x1280) LCD panel
+ - waveshare,5.0inch-d-panel
+ # Waveshare 6.25" (720x1560) LCD panel
+ - waveshare,6.25inch-panel
# Waveshare 7.0" WSVGA (1024x600) LCD panel
- waveshare,7.0inch-c-panel
+ # Waveshare 7.0" WXGA (1280x800) LCD panel
+ - waveshare,7.0inch-e-panel
+ # Waveshare 7.0" HD 720p (720x1280) LCD panel
+ - waveshare,7.0inch-h-panel
+ # Waveshare 7.9" (400x1280) LCD panel
+ - waveshare,7.9inch-panel
+ # Waveshare 8.0" WXGA (1280x800) LCD panel
+ - waveshare,8.0inch-c-panel
+ # Waveshare 8.8" (480x1920) LCD panel
+ - waveshare,8.8inch-panel
# Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
- winstar,wf35ltiacd
# Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel
--
2.47.3
^ permalink raw reply related
* [PATCH 4/4] drm/panel: simple: add Waveshare LCD panels
From: Dmitry Baryshkov @ 2026-03-30 13:25 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260330-ws-lcd-v1-0-309834a435c0@oss.qualcomm.com>
Waveshare have a serie of DSI panel kits with the DPI or LVDS panel
being attached to the DSI2DPI or DSI2LVDS bridge. The commit
46be11b678e0 ("drm/panel: simple: Add Waveshare 13.3" panel support")
added definitions for one of those panels, describe the rest of them.
Note, since the panels are hidden behind the bridges which are not being
programmed by the kernel, I could not confirm the pixel format for the
panels.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/panel/panel-simple.c | 381 +++++++++++++++++++++++++++++++++++
1 file changed, 381 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 236bd56208cc..b2708a1fe464 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -5061,6 +5061,342 @@ static const struct panel_desc vl050_8048nt_c01 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
};
+static const struct drm_display_mode waveshare_28_lcd_mode = {
+ .clock = 50000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 150,
+ .hsync_end = 480 + 150 + 50,
+ .htotal = 480 + 150 + 50 + 150,
+ .vdisplay = 640,
+ .vsync_start = 640 + 150,
+ .vsync_end = 640 + 150 + 50,
+ .vtotal = 640 + 150 + 50 + 150,
+ .flags = DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_PHSYNC,
+};
+
+static const struct panel_desc waveshare_28_lcd_panel = {
+ .modes = &waveshare_28_lcd_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 44,
+ .height = 58,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE,
+};
+
+static const struct drm_display_mode waveshare_34_lcd_c_mode = {
+ .clock = 50000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 32,
+ .hsync_end = 800 + 32 + 6,
+ .htotal = 800 + 32 + 6 + 120,
+ .vdisplay = 800,
+ .vsync_start = 800 + 8,
+ .vsync_end = 800 + 8 + 4,
+ .vtotal = 800 + 8 + 4 + 16,
+};
+
+static const struct panel_desc waveshare_34_lcd_c_panel = {
+ .modes = &waveshare_34_lcd_c_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 88,
+ .height = 88,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
+static const struct drm_display_mode waveshare_40_lcd_mode = {
+ .clock = 50000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 150,
+ .hsync_end = 480 + 150 + 100,
+ .htotal = 480 + 150 + 100 + 150,
+ .vdisplay = 800,
+ .vsync_start = 800 + 20,
+ .vsync_end = 800 + 20 + 100,
+ .vtotal = 800 + 20 + 100 + 20,
+ .flags = DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_PHSYNC,
+};
+
+static const struct panel_desc waveshare_40_lcd_panel = {
+ .modes = &waveshare_40_lcd_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 52,
+ .height = 87,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE,
+};
+
+static const struct drm_display_mode waveshare_40_lcd_c_mode = {
+ .clock = 50000,
+ .hdisplay = 720,
+ .hsync_start = 720 + 32,
+ .hsync_end = 720 + 32 + 200,
+ .htotal = 720 + 32 + 200 + 120,
+ .vdisplay = 720,
+ .vsync_start = 720 + 8,
+ .vsync_end = 720 + 8 + 4,
+ .vtotal = 720 + 8 + 4 + 16,
+};
+
+static const struct panel_desc waveshare_40_lcd_c_panel = {
+ .modes = &waveshare_40_lcd_c_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 102,
+ .height = 102,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
+static const struct drm_display_mode waveshare_50_lcd_c_mode = {
+ .clock = 50000,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 100,
+ .hsync_end = 1024 + 100 + 100,
+ .htotal = 1024 + 100 + 100 + 100,
+ .vdisplay = 600,
+ .vsync_start = 600 + 10,
+ .vsync_end = 600 + 10 + 10,
+ .vtotal = 600 + 10 + 10 + 10,
+ .flags = DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_PHSYNC,
+};
+
+static const struct panel_desc waveshare_50_lcd_c_panel = {
+ .modes = &waveshare_50_lcd_c_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 109,
+ .height = 66,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE,
+};
+
+static const struct drm_display_mode waveshare_50_lcd_d_mode = {
+ .clock = 83333,
+ .hdisplay = 720,
+ .hsync_start = 720 + 100,
+ .hsync_end = 720 + 100 + 80,
+ .htotal = 720 + 100 + 80 + 100,
+ .vdisplay = 1280,
+ .vsync_start = 1280 + 20,
+ .vsync_end = 1280 + 20 + 20,
+ .vtotal = 1280 + 20 + 20 + 20,
+};
+
+static const struct panel_desc waveshare_50_lcd_d_panel = {
+ .modes = &waveshare_50_lcd_d_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 62,
+ .height = 110,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
+static const struct drm_display_mode waveshare_625_lcd_mode = {
+ .clock = 83333,
+ .hdisplay = 720,
+ .hsync_start = 720 + 50,
+ .hsync_end = 720 + 50 + 50,
+ .htotal = 720 + 50 + 50 + 50,
+ .vdisplay = 1560,
+ .vsync_start = 1560 + 20,
+ .vsync_end = 1560 + 20 + 20,
+ .vtotal = 1560 + 20 + 20 + 20,
+};
+
+static const struct panel_desc waveshare_625_lcd_panel = {
+ .modes = &waveshare_625_lcd_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 66,
+ .height = 144,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
+static const struct panel_desc waveshare_70_lcd_c_panel = {
+ .modes = &waveshare_50_lcd_c_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 155,
+ .height = 87,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE,
+};
+
+static const struct drm_display_mode waveshare_80_lcd_c_mode;
+static const struct panel_desc waveshare_70_lcd_e_panel = {
+ .modes = &waveshare_80_lcd_c_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 152,
+ .height = 95,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
+static const struct drm_display_mode waveshare_70_lcd_h_mode = {
+ .clock = 83333,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 64,
+ .hsync_end = 1280 + 64 + 64,
+ .htotal = 1280 + 64 + 64 + 64,
+ .vdisplay = 720,
+ .vsync_start = 720 + 64,
+ .vsync_end = 720 + 64 + 64,
+ .vtotal = 720 + 64 + 64 + 64,
+};
+
+static const struct panel_desc waveshare_70_lcd_h_panel = {
+ .modes = &waveshare_70_lcd_h_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 155,
+ .height = 88,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
+static const struct drm_display_mode waveshare_79_lcd_mode = {
+ .clock = 50000,
+ .hdisplay = 400,
+ .hsync_start = 400 + 40,
+ .hsync_end = 400 + 40 + 30,
+ .htotal = 400 + 40 + 30 + 40,
+ .vdisplay = 1280,
+ .vsync_start = 1280 + 20,
+ .vsync_end = 1280 + 20 + 10,
+ .vtotal = 1280 + 20 + 10 + 20,
+};
+
+static const struct panel_desc waveshare_79_lcd_panel = {
+ .modes = &waveshare_79_lcd_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 60,
+ .height = 191,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
+static const struct drm_display_mode waveshare_80_lcd_c_mode = {
+ .clock = 83333,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 156,
+ .hsync_end = 1280 + 156 + 20,
+ .htotal = 1280 + 156 + 20 + 40,
+ .vdisplay = 800,
+ .vsync_start = 800 + 40,
+ .vsync_end = 800 + 40 + 48,
+ .vtotal = 800 + 40 + 48 + 40,
+};
+
+static const struct panel_desc waveshare_80_lcd_c_panel = {
+ .modes = &waveshare_80_lcd_c_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 173,
+ .height = 108,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
+static const struct drm_display_mode waveshare_88_lcd_mode = {
+ .clock = 83333,
+ .hdisplay = 480,
+ .hsync_start = 480 + 50,
+ .hsync_end = 480 + 50 + 50,
+ .htotal = 480 + 50 + 50 + 50,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 20,
+ .vsync_end = 1920 + 20 + 20,
+ .vtotal = 1920 + 20 + 20 + 20,
+};
+
+static const struct panel_desc waveshare_88_lcd_panel = {
+ .modes = &waveshare_88_lcd_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 56,
+ .height = 220,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
+static const struct panel_desc waveshare_101_lcd_c_panel = {
+ .modes = &waveshare_80_lcd_c_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
+static const struct drm_display_mode waveshare_119_lcd_mode = {
+ .clock = 50000,
+ .hdisplay = 320,
+ .hsync_start = 320 + 60,
+ .hsync_end = 320 + 60 + 60,
+ .htotal = 320 + 60 + 60 + 60,
+ .vdisplay = 1480,
+ .vsync_start = 1480 + 60,
+ .vsync_end = 1480 + 60 + 60,
+ .vtotal = 1480 + 60 + 60 + 60,
+};
+
+static const struct panel_desc waveshare_119_lcd_panel = {
+ .modes = &waveshare_119_lcd_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 58,
+ .height = 268,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode waveshare_133inch_mode = {
.clock = 148500,
.hdisplay = 1920,
@@ -5697,6 +6033,51 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "vxt,vl050-8048nt-c01",
.data = &vl050_8048nt_c01,
+ }, {
+ .compatible = "waveshare,2.8inch-panel",
+ .data = &waveshare_28_lcd_panel
+ }, {
+ .compatible = "waveshare,3.4inch-c-panel",
+ .data = &waveshare_34_lcd_c_panel
+ }, {
+ .compatible = "waveshare,4.0inch-panel",
+ .data = &waveshare_40_lcd_panel
+ }, {
+ .compatible = "waveshare,4.0inch-c-panel",
+ .data = &waveshare_40_lcd_c_panel
+ }, {
+ .compatible = "waveshare,5.0inch-c-panel",
+ .data = &waveshare_50_lcd_c_panel
+ }, {
+ .compatible = "waveshare,5.0inch-d-panel",
+ .data = &waveshare_50_lcd_d_panel
+ }, {
+ .compatible = "waveshare,6.25inch-panel",
+ .data = &waveshare_625_lcd_panel
+ }, {
+ .compatible = "waveshare,7.0inch-c-panel",
+ .data = &waveshare_70_lcd_c_panel
+ }, {
+ .compatible = "waveshare,7.0inch-e-panel",
+ .data = &waveshare_70_lcd_e_panel
+ }, {
+ .compatible = "waveshare,7.0inch-h-panel",
+ .data = &waveshare_70_lcd_h_panel
+ }, {
+ .compatible = "waveshare,7.9inch-panel",
+ .data = &waveshare_79_lcd_panel
+ }, {
+ .compatible = "waveshare,8.0inch-c-panel",
+ .data = &waveshare_80_lcd_c_panel
+ }, {
+ .compatible = "waveshare,8.8inch-panel",
+ .data = &waveshare_88_lcd_panel
+ }, {
+ .compatible = "waveshare,10.1inch-c-panel",
+ .data = &waveshare_101_lcd_c_panel
+ }, {
+ .compatible = "waveshare,11.9inch-panel",
+ .data = &waveshare_119_lcd_panel
}, {
.compatible = "waveshare,13.3inch-panel",
.data = &waveshare_133inch,
--
2.47.3
^ permalink raw reply related
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-30 13:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <a417e45b-1632-4b14-9e3c-f7110db53190@kernel.org>
On Mon, 30 Mar 2026 at 13:24, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/03/2026 13:12, Ulf Hansson wrote:
> >
> >>
> >>>
> >>> Although, as I said, if you think it's best to funnel them through
> >>> your tree, please do and then share them via an immutable branch, so I
> >>> can apply the pmdomain driver changes.
> >>
> >> soc must go via my tree, but there is no reason to take the pmdomain
> >> binding patch. So I did not take.
> >
> > Yes, they belong to soc/platform, which is common for most
> > power-domain providers.
>
> What does belong to soc/platform? pmdomain changes? No, they do not...
I think you may have misunderstood me here. I was referring to the DT
bindings that describe power domain providers.
Generally speaking, these are often provided via some
SOC/platform-specific hardware (like a PMU for example).
>
> >
> > To allow us to merge/maintain power-domain provider *driver* changes
> > separately, we needed a way to manage the corresponding DT bindings.
>
> Nothing stops that, there is no dependency. For a week I am saying there
> are no dependencies. If there are, please provide any sort of
> argument/proof, otherwise there is nothing to do here.
>
> > That's why I am hosting the immutable "dt" branch for these, which
> > soc/platform maintainers can pull-in when they need it.
> >
> > Of course, doing it the other way around is also possible. Just let me
> > know what you prefer.
>
> Nothing like that is necessary.
Usually we want bindings to go along with their respective drivers on
a subsystem basis.
Both patch2 and patch4 updates DT bindings for the power-domain providers.
Why shouldn't the bindings go along with the driver changes here?
Kind regards
Uffe
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 13:38 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFomzokuF+UL8d0+Syk1FCG3jnUfy7rVr+3iC1GPZmH1UQ@mail.gmail.com>
On 30/03/2026 15:30, Ulf Hansson wrote:
>
> Usually we want bindings to go along with their respective drivers on
> a subsystem basis.
>
> Both patch2 and patch4 updates DT bindings for the power-domain providers.
Patch 2 yes. Patch 4 not. That's why I did not take patch 2.
>
> Why shouldn't the bindings go along with the driver changes here?
Patch #2 is pmdomain, so with pmdomain drivers thus your tree. Patch #4
is not pmdomain, so not with pmdomain drivers, so not your tree... At
least I do not see any pmdomain parts in that patch #4. It's a Samsung
SoC PMU driver and none of further driver patches touch that PMU driver.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 00/16] Add support for Inside-Secure EIP-150 crypto block
From: Geert Uytterhoeven @ 2026-03-30 13:33 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric)
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc, Herve Codina
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-0-5e6ff7853994@bootlin.com>
Hi Miquel,
On Fri, 27 Mar 2026 at 21:10, Miquel Raynal (Schneider Electric)
<miquel.raynal@bootlin.com> wrote:
> This is a series adding support for the EIP-150, which is a crypto block
> containing:
> - a public key accelerator
> - a random number generator
> - an interrupt controller
Thanks for your series!
> irqchip/eip201-aic: Add support for Safexcel EIP-201 AIC
[...]
> crypto: eip28: Add support for SafeXcel EIP-28 Public Key Accelerator
My OCD tells me to ask for using "SafeXcel" consistently, ;-)
drivers/crypto/inside-secure/eip28.c: .name = "Safexcel EIP28 PKA",
drivers/irqchip/Kconfig: tristate "Safexcel EIP201 AIC"
drivers/irqchip/Kconfig: inside Safexcel EIP150 IPs, gathering
Public Key Accelerator
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 00/11] Add SIM pbias regulator support for USB on OMAP4
From: Thomas Richard @ 2026-03-30 13:43 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree,
Thomas Richard
To get USB working on OMAP4, pbias shall be configured to enable
SIM_VDDS and unlock I/O cells. Until now this was done by the bootloader.
The goal of this series is to add SIM pbias support to handle this in the
kernel ensuring correct operation regardless of the bootloader. The
vsim_pbias regulator (defined in pbias-regulator driver) will be handled by
the omap-usb-host driver.
In this second iteration I converted ti,pbias-regulator binding to DT
schema and documented the pbias_sim_omap4 regulator. The vmod bit
configuration for the pbias_sim_omap4 regulator has been fixed.
On omap-usb-host side, I fixed the binding file as requested by Conor. In
the driver I fixed the error path in suspend callback and now probe()
function gracefully handles cases where no pbias regulator is provided.
This series has been tested on VAR-SOM-OM44.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
Changes in v2:
- bindings: regulator: convert ti,pbias-regulator binding to DT schema.
- bindings: regulator: document new pbias_sim_omap4 regulator.
- regulator: pbias: fix disable_val and vmod for pbias_sim_omap4.
- bindings: omap-usb-host: document missing clocks.
- bindings: omap-usb-host: add a ref to usb object.
- mfd: omap-usb-host: refactor suspend and resume callbacks.
- mfd: omap-usb-host: do not return an error if optional pbias regulator is
not provided.
- Link to v1: https://lore.kernel.org/r/20260323-omap4-fix-usb-support-v1-0-b668132124ac@bootlin.com
---
Thomas Richard (11):
dt-bindings: regulator: ti,pbias-regulator: Convert to DT schema
dt-bindings: regulator: ti,pbias-regulator: Add pbias_sim_omap4 regulator
regulator: pbias: Add pbias SIM regulator for OMAP4
ARM: dts: ti: omap4: Add pbias SIM regulator
mfd: omap-usb-host: Cleanup header includes
mfd: omap-usb-host: Sanitize error path in the probe()
mfd: omap-usb-host: Refactor suspend and resume callbacks
dt-bindings: mfd: ti,omap-usb-host: Convert to DT schema
dt-bindings: mfd: ti,omap-usb-host: Add 'pbias-supply' property
mfd: omap-usb-host: Add pbias regulator support
ARM: dts: ti: omap4: Add pbias regulator to the HS USB Host
.../devicetree/bindings/mfd/omap-usb-host.txt | 103 ---------
.../devicetree/bindings/mfd/ti,omap-usb-host.yaml | 167 +++++++++++++++
.../bindings/regulator/pbias-regulator.txt | 32 ---
.../bindings/regulator/ti,pbias-regulator.yaml | 126 +++++++++++
MAINTAINERS | 2 +
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 7 +
drivers/mfd/omap-usb-host.c | 236 ++++++++++++---------
drivers/regulator/pbias-regulator.c | 12 ++
8 files changed, 449 insertions(+), 236 deletions(-)
---
base-commit: 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
change-id: 20260317-omap4-fix-usb-support-cda83c7079b7
Best regards,
--
Thomas Richard <thomas.richard@bootlin.com>
^ permalink raw reply
* [PATCH v2 01/11] dt-bindings: regulator: ti,pbias-regulator: Convert to DT schema
From: Thomas Richard @ 2026-03-30 13:43 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree,
Thomas Richard
In-Reply-To: <20260330-omap4-fix-usb-support-v2-0-1c1e11b190dc@bootlin.com>
Convert PBIAS internal regulator binding to DT schema.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
.../bindings/regulator/pbias-regulator.txt | 32 ------
.../bindings/regulator/ti,pbias-regulator.yaml | 125 +++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 126 insertions(+), 32 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
deleted file mode 100644
index acbcb452a69a..000000000000
--- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
-
-Required properties:
-- compatible:
- - should be "ti,pbias-dra7" for DRA7
- - should be "ti,pbias-omap2" for OMAP2
- - should be "ti,pbias-omap3" for OMAP3
- - should be "ti,pbias-omap4" for OMAP4
- - should be "ti,pbias-omap5" for OMAP5
- - "ti,pbias-omap" is deprecated
-- reg: pbias register offset from syscon base and size of pbias register.
-- syscon : phandle of the system control module
-- regulator-name : should be
- pbias_mmc_omap2430 for OMAP2430, OMAP3 SoCs
- pbias_sim_omap3 for OMAP3 SoCs
- pbias_mmc_omap4 for OMAP4 SoCs
- pbias_mmc_omap5 for OMAP5 and DRA7 SoC
-
-Optional properties:
-- Any optional property defined in bindings/regulator/regulator.txt
-
-Example:
-
- pbias_regulator: pbias_regulator {
- compatible = "ti,pbias-omap";
- reg = <0 0x4>;
- syscon = <&omap5_padconf_global>;
- pbias_mmc_reg: pbias_mmc_omap5 {
- regulator-name = "pbias_mmc_omap5";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3000000>;
- };
diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
new file mode 100644
index 000000000000..3e020d87701b
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/ti,pbias-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PBIAS internal regulator
+
+maintainers:
+ - Thomas Richard <thomas.richard@bootlin.com>
+
+description: |
+ PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - ti,pbias-dra7
+ - ti,pbias-omap2
+ - ti,pbias-omap3
+ - ti,pbias-omap4
+ - ti,pbias-omap5
+ - const: ti,pbias-omap
+
+ reg:
+ maxItems: 1
+
+ syscon:
+ description: Phandle of the system control module
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+patternProperties:
+ '^pbias_*':
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - syscon
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,pbias-omap2
+ then:
+ patternProperties:
+ '^pbias_*':
+ properties:
+ regulator-name:
+ contains:
+ enum:
+ - pbias_mmc_omap2430
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,pbias-omap3
+ then:
+ patternProperties:
+ '^pbias_*':
+ properties:
+ regulator-name:
+ contains:
+ enum:
+ - pbias_mmc_omap2430
+ - pbias_sim_omap3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,pbias-omap4
+ then:
+ patternProperties:
+ '^pbias_*':
+ properties:
+ regulator-name:
+ contains:
+ enum:
+ - pbias_mmc_omap4
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,pbias-dra7
+ - ti,pbias-omap5
+ then:
+ patternProperties:
+ '^pbias_*':
+ properties:
+ regulator-name:
+ contains:
+ enum:
+ - pbias_mmc_omap5
+
+examples:
+ - |
+ bus {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pbias_regulator: pbias_regulator@0 {
+ compatible = "ti,pbias-omap5", "ti,pbias-omap";
+ reg = <0 0x4>;
+ syscon = <&omap5_padconf_global>;
+ pbias_mmc_reg: pbias_mmc_omap5 {
+ regulator-name = "pbias_mmc_omap5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3000000>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index c3fe46d7c4bc..15052c0f5377 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19406,6 +19406,7 @@ W: http://linux.omap.com/
Q: http://patchwork.kernel.org/project/linux-omap/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
F: Documentation/devicetree/bindings/arm/ti/omap.yaml
+F: Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
F: arch/arm/configs/omap2plus_defconfig
F: arch/arm/mach-omap2/
F: drivers/bus/omap*.[ch]
--
2.53.0
^ permalink raw reply related
* [PATCH v2 02/11] dt-bindings: regulator: ti,pbias-regulator: Add pbias_sim_omap4 regulator
From: Thomas Richard @ 2026-03-30 13:43 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree,
Thomas Richard
In-Reply-To: <20260330-omap4-fix-usb-support-v2-0-1c1e11b190dc@bootlin.com>
Define pbias_sim_omap4 regulator for OMAP4. This regulators drives SIM_VDDS
supply and allows to unlock USB I/O cell.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
index 3e020d87701b..908fbb46b5cf 100644
--- a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
@@ -89,6 +89,7 @@ allOf:
contains:
enum:
- pbias_mmc_omap4
+ - pbias_sim_omap4
- if:
properties:
--
2.53.0
^ permalink raw reply related
* [PATCH v2 03/11] regulator: pbias: Add pbias SIM regulator for OMAP4
From: Thomas Richard @ 2026-03-30 13:44 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree,
Thomas Richard
In-Reply-To: <20260330-omap4-fix-usb-support-v2-0-1c1e11b190dc@bootlin.com>
Add support for the pbias SIM regulator found on OMAP4 (for USB I/O cell).
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
drivers/regulator/pbias-regulator.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/regulator/pbias-regulator.c b/drivers/regulator/pbias-regulator.c
index cd5a0d7e4455..23cc106cd9fb 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -81,6 +81,17 @@ static const struct pbias_reg_info pbias_sim_omap3 = {
.name = "pbias_sim_omap3"
};
+static const struct pbias_reg_info pbias_sim_omap4 = {
+ .enable = BIT(28) | BIT(20),
+ .enable_mask = BIT(31) | BIT(28) | BIT(20),
+ .disable_val = BIT(31),
+ .vmode = BIT(27),
+ .enable_time = 100,
+ .pbias_volt_table = pbias_volt_table_3_0V,
+ .n_voltages = 2,
+ .name = "pbias_sim_omap4"
+};
+
static const struct pbias_reg_info pbias_mmc_omap4 = {
.enable = BIT(26) | BIT(22),
.enable_mask = BIT(26) | BIT(25) | BIT(22),
@@ -108,6 +119,7 @@ static struct of_regulator_match pbias_matches[] = {
{ .name = "pbias_sim_omap3", .driver_data = (void *)&pbias_sim_omap3},
{ .name = "pbias_mmc_omap4", .driver_data = (void *)&pbias_mmc_omap4},
{ .name = "pbias_mmc_omap5", .driver_data = (void *)&pbias_mmc_omap5},
+ { .name = "pbias_sim_omap4", .driver_data = (void *)&pbias_sim_omap4},
};
#define PBIAS_NUM_REGS ARRAY_SIZE(pbias_matches)
--
2.53.0
^ permalink raw reply related
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