* [PATCH v3 1/7] dt-bindings: pwm: Document Tegra264 controller
From: Mikko Perttunen @ 2026-03-30 8:53 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding,
Mikko Perttunen
In-Reply-To: <20260330-t264-pwm-v3-0-5714427d5976@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
Add a new compatible string for the PWM controller found on Tegra264.
The controller is similar to earlier generations but not compatible
with them.
Signed-off-by: Thierry Reding <treding@nvidia.com>
[mperttunen: Drop extra Tegra194 compatible string]
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
index 41cea4979132..cb2f36e7b5d6 100644
--- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
@@ -16,6 +16,7 @@ properties:
- enum:
- nvidia,tegra20-pwm
- nvidia,tegra186-pwm
+ - nvidia,tegra264-pwm
- items:
- enum:
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/7] Tegra264 PWM support
From: Mikko Perttunen @ 2026-03-30 8:53 UTC (permalink / raw)
To: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding,
Mikko Perttunen, Yi-Wei Wang
Hello,
this adds support for the PWM controller on Tegra264. The controller
is similar to previous generations, but the register fields are
widened, the depth is made configurable, and the enable bit moves
to a different spot.
This series adds only basic support with fixed depth -- configurable
depth will come later.
Patch 1 adds device tree bindings for Tegra264 PWM (compatible
string).
Patches 2 to 6 contain the PWM driver changes.
Patch 7 adds device tree nodes for the PWM controllers on Tegra264.
Thanks,
Mikko
---
Changes in v3:
- Fixed device tree binding patch.
- Picked up trailers.
- Link to v2: https://lore.kernel.org/r/20260325-t264-pwm-v2-0-998d885984b3@nvidia.com
Changes in v2:
- Added device tree binding and Tegra264 device tree patches by Thierry.
- Link to v1: https://lore.kernel.org/r/20260323-t264-pwm-v1-0-4c4ff743050f@nvidia.com
---
Mikko Perttunen (4):
pwm: tegra: Modify read/write accessors for multi-register channel
pwm: tegra: Parametrize enable register offset
pwm: tegra: Parametrize duty and scale field widths
pwm: tegra: Add support for Tegra264
Thierry Reding (2):
dt-bindings: pwm: Document Tegra264 controller
arm64: tegra: Add PWM controllers on Tegra264
Yi-Wei Wang (1):
pwm: tegra: Avoid hard-coded max clock frequency
.../bindings/pwm/nvidia,tegra20-pwm.yaml | 1 +
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 72 +++++++++++
drivers/pwm/pwm-tegra.c | 141 ++++++++++++++-------
3 files changed, 171 insertions(+), 43 deletions(-)
---
base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
change-id: 20260303-t264-pwm-57e10d039df1
^ permalink raw reply
* [PATCH v2] staging: nvec: validate battery response length before memcpy
From: Sebastian Josue Alba Vives @ 2026-03-30 6:09 UTC (permalink / raw)
To: gregkh
Cc: marvin24, linux-staging, ac100, linux-tegra, linux-kernel, stable,
Sebastián Alba Vives
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
In nvec_power_notifier(), the response length from the embedded
controller is used directly as the size argument to memcpy() when
copying battery manufacturer, model, and type strings. The
destination buffers (bat_manu, bat_model, bat_type) are fixed at
30 bytes, but res->length is a u8 that can be up to 255, allowing
a heap buffer overflow.
Additionally, if res->length is less than 2, the subtraction
res->length - 2 wraps around as an unsigned value, resulting in a
large copy that corrupts kernel heap memory.
Introduce NVEC_BAT_STRING_SIZE to replace the hardcoded buffer
size, store res->length - 2 in a local copy_len variable for
clarity, and add bounds checks before each memcpy to ensure the
copy length does not exceed the destination buffer and that
res->length is at least 2 to prevent unsigned integer underflow.
Tested-by: Marc Dietrich <marvin24@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
v2:
- Introduce NVEC_BAT_STRING_SIZE constant to replace hardcoded
buffer size (Marc Dietrich)
- Store res->length - 2 in local copy_len variable for clarity
(Marc Dietrich)
- Use NVEC_BAT_STRING_SIZE in strncmp call for consistency
drivers/staging/nvec/nvec_power.c | 41 +++++++++++++++++++++----------
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/nvec/nvec_power.c b/drivers/staging/nvec/nvec_power.c
index 2faab9fde..7b7980127 100644
--- a/drivers/staging/nvec/nvec_power.c
+++ b/drivers/staging/nvec/nvec_power.c
@@ -19,6 +19,7 @@
#include "nvec.h"
#define GET_SYSTEM_STATUS 0x00
+#define NVEC_BAT_STRING_SIZE 30
struct nvec_power {
struct notifier_block notifier;
@@ -38,9 +39,9 @@ struct nvec_power {
int bat_temperature;
int bat_cap;
int bat_type_enum;
- char bat_manu[30];
- char bat_model[30];
- char bat_type[30];
+ char bat_manu[NVEC_BAT_STRING_SIZE];
+ char bat_model[NVEC_BAT_STRING_SIZE];
+ char bat_type[NVEC_BAT_STRING_SIZE];
};
enum {
@@ -192,22 +193,36 @@ static int nvec_power_bat_notifier(struct notifier_block *nb,
case TEMPERATURE:
power->bat_temperature = res->plu - 2732;
break;
- case MANUFACTURER:
- memcpy(power->bat_manu, &res->plc, res->length - 2);
- power->bat_manu[res->length - 2] = '\0';
+ case MANUFACTURER: {
+ size_t copy_len = res->length - 2;
+
+ if (res->length < 2 || copy_len > NVEC_BAT_STRING_SIZE - 1)
+ break;
+ memcpy(power->bat_manu, &res->plc, copy_len);
+ power->bat_manu[copy_len] = '\0';
break;
- case MODEL:
- memcpy(power->bat_model, &res->plc, res->length - 2);
- power->bat_model[res->length - 2] = '\0';
+ }
+ case MODEL: {
+ size_t copy_len = res->length - 2;
+
+ if (res->length < 2 || copy_len > NVEC_BAT_STRING_SIZE - 1)
+ break;
+ memcpy(power->bat_model, &res->plc, copy_len);
+ power->bat_model[copy_len] = '\0';
break;
- case TYPE:
- memcpy(power->bat_type, &res->plc, res->length - 2);
- power->bat_type[res->length - 2] = '\0';
+ }
+ case TYPE: {
+ size_t copy_len = res->length - 2;
+
+ if (res->length < 2 || copy_len > NVEC_BAT_STRING_SIZE - 1)
+ break;
+ memcpy(power->bat_type, &res->plc, copy_len);
+ power->bat_type[copy_len] = '\0';
/*
* This differs a little from the spec fill in more if you find
* some.
*/
- if (!strncmp(power->bat_type, "Li", 30))
+ if (!strncmp(power->bat_type, "Li", NVEC_BAT_STRING_SIZE))
power->bat_type_enum = POWER_SUPPLY_TECHNOLOGY_LION;
else
power->bat_type_enum = POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] staging: nvec: validate battery response length before memcpy
From: Greg KH @ 2026-03-30 5:49 UTC (permalink / raw)
To: Sebastian Josue Alba Vives
Cc: marvin24, ac100, linux-tegra, linux-kernel, stable
In-Reply-To: <20260329210800.597697-1-sebasjosue84@gmail.com>
On Sun, Mar 29, 2026 at 03:08:00PM -0600, Sebastian Josue Alba Vives wrote:
> From: Sebastián Alba Vives <sebasjosue84@gmail.com>
>
> In nvec_power_notifier(), the response length from the embedded
> controller is used directly as the size argument to memcpy() when
> copying battery manufacturer, model, and type strings. The
> destination buffers (bat_manu, bat_model, bat_type) are fixed at
> 30 bytes, but res->length is a u8 that can be up to 255, allowing
> a heap buffer overflow.
>
> Additionally, if res->length is less than 2, the subtraction
> res->length - 2 wraps around as an unsigned value, resulting in a
> large copy that corrupts kernel heap memory.
>
> Introduce NVEC_BAT_STRING_SIZE to replace the hardcoded buffer
> size, store res->length - 2 in a local copy_len variable for
> clarity, and add bounds checks before each memcpy to ensure the
> copy length does not exceed the destination buffer and that
> res->length is at least 2 to prevent unsigned integer underflow.
>
> Tested-by: Marc Dietrich <marvin24@gmx.de>
> Cc: stable@vger.kernel.org
> Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
> ---
> v2:
> - Introduce NVEC_BAT_STRING_SIZE constant to replace hardcoded
> buffer size (Marc Dietrich)
> - Store res->length - 2 in local copy_len variable for clarity
> (Marc Dietrich)
> - Use NVEC_BAT_STRING_SIZE in strncmp call for consistency
> drivers/staging/nvec/nvec_power.c | 41 +++++++++++++++++++++----------
> 1 file changed, 28 insertions(+), 13 deletions(-)
Is there a reason you are not sending these to the staging maintainer
and mailing list so that they can actually be applied?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Akhil R @ 2026-03-30 5:26 UTC (permalink / raw)
To: alexandre.belloni
Cc: Frank.Li, acpica-devel, akhilrajeev, conor+dt, conor, devicetree,
ebiggers, fredrik.markstrom, jonathanh, krzk+dt, lenb, linux-acpi,
linux-hwmon, linux-i3c, linux-kernel, linux-tegra, linux,
miquel.raynal, p.zabel, rafael, robert.moore, robh, smangipudi,
thierry.reding
In-Reply-To: <2026032717064247cc495e@mail.local>
On Fri, 27 Mar 2026 18:06:42 +0100, Alexandre Belloni wrote:
> On 27/03/2026 17:12:04+0530, Akhil R wrote:
>> On Fri, 27 Mar 2026 09:27:21 +0100, Alexandre Belloni wrote:
>> > On 27/03/2026 13:48:58+0530, Akhil R wrote:
>> >> On Thu, 26 Mar 2026 16:44:31 +0100, Alexandre Belloni wrote:
>> >> > On 26/03/2026 10:05:03-0500, Rob Herring wrote:
>> >> >> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
>> >> >> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
>> >> >> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
>> >> >> > > Discovery and Configuration Specification [1] to specify which discovery
>> >> >> > > method an I3C device supports during bus initialization. The property is
>> >> >> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
>> >> >> > > indicates lack of support.
>> >> >> > > Bit 0: SETDASA CCC (Direct)
>> >> >> > > Bit 1: SETAASA CCC (Broadcast)
>> >> >> > > Bit 2: Other CCC (vendor / standards extension)
>> >> >> > > All other bits are reserved.
>> >> >> > >
>> >> >> > > It is specifically needed when an I3C device requires SETAASA for the
>> >> >> > > address assignment. SETDASA will be supported by default if this property
>> >> >> > > is absent - which means for now the property just serves as a flag to
>> >> >> > > enable SETAASA, but keep the property as a bitmap to align with the
>> >> >> > > specifications.
>> >> >> > >
>> >> >> > > [1] https://www.mipi.org/specifications/disco
>> >> >> > >
>> >> >> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> >> >> > > ---
>> >> >> > > .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
>> >> >> > > 1 file changed, 26 insertions(+), 4 deletions(-)
>> >> >> > >
>> >> >> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> >> > > index e25fa72fd785..1705d90d4d79 100644
>> >> >> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> >> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> >> > > @@ -31,10 +31,12 @@ properties:
>> >> >> > > described in the device tree, which in turn means we have to describe
>> >> >> > > I3C devices.
>> >> >> > >
>> >> >> > > - Another use case for describing an I3C device in the device tree is when
>> >> >> > > - this I3C device has a static I2C address and we want to assign it a
>> >> >> > > - specific I3C dynamic address before the DAA takes place (so that other
>> >> >> > > - devices on the bus can't take this dynamic address).
>> >> >> > > + Other use-cases for describing an I3C device in the device tree are:
>> >> >> > > + - When the I3C device has a static I2C address and we want to assign
>> >> >> > > + it a specific I3C dynamic address before the DAA takes place (so
>> >> >> > > + that other devices on the bus can't take this dynamic address).
>> >> >> > > + - When the I3C device requires SETAASA for its discovery and uses a
>> >> >> > > + pre-defined static address.
>> >> >> > >
>> >> >> > > "#size-cells":
>> >> >> > > const: 0
>> >> >> > > @@ -147,6 +149,26 @@ patternProperties:
>> >> >> > > through SETDASA. If static address is not present, this address is assigned
>> >> >> > > through SETNEWDA after assigning a temporary address via ENTDAA.
>> >> >> > >
>> >> >> > > + mipi-i3c-static-method:
>> >> >> > > + $ref: /schemas/types.yaml#/definitions/uint32
>> >> >> > > + minimum: 0x1
>> >> >> > > + maximum: 0xff
>> >> >> > > + default: 1
>> >> >> > > + description: |
>> >> >> > > + Bitmap describing which methods of Dynamic Address Assignment from a
>> >> >> > > + static address are supported by this I3C Target. A bit value of 1
>> >> >> > > + indicates support for that method, and 0 indicates lack of support.
>> >> >> >
>> >> >> > I really am not keen on properties that are bitmaps, why can't we just
>> >> >> > use the strings "setdasa", "setaasa" etc?
>> >> >>
>> >> >> If this comes from a specification, then I'd tend to just copy it rather
>> >> >> than invent our own thing. Obviously if is something structured
>> >> >> fundamentally different from how DT is designed, then we wouldn't. But
>> >> >> this is just a simple property.
>> >> >>
>> >> >
>> >> > The issue being that the specification is not public so it is difficult
>> >> > to take any decision.
>> >>
>> >> There is a public version available in the same link, but you would still
>> >> have to provide them a name and an email ID. The document will be sent to
>> >> the mail ID.
>> >>
>> >
>> > The public version only contains one property:
>> > mipi-disco-interface-revision
>>
>> Could you check once if the below link works?
>> https://www.mipi.org/mipi-disco-for-i3c-download
>
> It works, thanks. The bitfield is fine then.
Thanks for checking. I will update the link in the commit description and
keep the rest of the patch as is. Hope that sounds good.
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v2 4/7] pwm: tegra: Parametrize enable register offset
From: Mikko Perttunen @ 2026-03-30 2:24 UTC (permalink / raw)
To: Thierry Reding
Cc: Mikko Perttunen, Thierry Reding, Uwe Kleine-König,
Jonathan Hunter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-pwm, linux-tegra, linux-kernel, devicetree, Yi-Wei Wang
In-Reply-To: <acT_nz0TRM4yXwkb@orome>
On 2026-03-26 10:47 +0100, Thierry Reding wrote:
> On Wed, Mar 25, 2026 at 07:17:02PM +0900, Mikko Perttunen wrote:
> > On Tegra264, the PWM enablement bit is not located at the base address
> > of the PWM controller. Hence, introduce an enablement offset field in
> > the tegra_pwm_soc structure to describe the offset of the register.
> >
> > Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
> > Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
> > Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> > ---
> > drivers/pwm/pwm-tegra.c | 17 ++++++++++++-----
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
> > index cf54f75d92a5..22d709986e8c 100644
> > --- a/drivers/pwm/pwm-tegra.c
> > +++ b/drivers/pwm/pwm-tegra.c
> > @@ -61,6 +61,7 @@
> >
> > struct tegra_pwm_soc {
> > unsigned int num_channels;
> > + unsigned int enable_reg;
> > };
> >
> > struct tegra_pwm_chip {
> > @@ -197,8 +198,9 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> > err = pm_runtime_resume_and_get(pwmchip_parent(chip));
> > if (err)
> > return err;
> > - } else
> > + } else if (pc->soc->enable_reg == PWM_CSR_0) {
> > val |= PWM_ENABLE;
> > + }
>
> This looks incomplete for the Tegra264 case where
>
> pc->soc->enable_reg == PWM_CSR_1
>
> >
> > pwm_writel(pwm, PWM_CSR_0, val);
>
> I think we need another write for PWM_CSR_1 here to properly toggle the
> PWM_ENABLE bit on Tegra264.
>
> Or am I missing something?
This check is here just so we don't change the value of PWM_ENABLE when
writing the CSR_0 register. The function doesn't write to CSR_1 so
nothing needs to be done on Tegra264.
I agree it's not the clearest, but it'll get cleaned up when adding
support for configurable depth, as at that point we will need to write
both registers on Tegra264.
>
> Thierry
^ permalink raw reply
* Re: [PATCH v3 5/6] PCI: tegra: Add Tegra264 support
From: Mikko Perttunen @ 2026-03-30 2:17 UTC (permalink / raw)
To: Thierry Reding
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jon Hunter, Mikko Perttunen, linux-pci, devicetree,
linux-tegra
In-Reply-To: <20260326135855.2795149-6-thierry.reding@kernel.org>
On Thu, 26 Mar 2026 14:58:52 +0100, Thierry Reding <thierry.reding@kernel.org> wrote:
> diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
> new file mode 100644
> index 000000000000..21872797e41a
> --- /dev/null
> +++ b/drivers/pci/controller/pcie-tegra264.c
> @@ -0,0 +1,522 @@
> [ ... skip 137 lines ... ]
> +
> + value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> + speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
> + width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
> +
> + bw = width * (PCIE_SPEED2MBS_ENC(pcie_link_speed[speed]));
Nit: this now has unnecessary double parentheses.
--
^ permalink raw reply
* Re: [PATCH v3 0/6] PCI: tegra: Add Tegra264 support
From: Mikko Perttunen @ 2026-03-30 2:17 UTC (permalink / raw)
To: Thierry Reding
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jon Hunter, Mikko Perttunen, linux-pci, devicetree,
linux-tegra
In-Reply-To: <20260326135855.2795149-1-thierry.reding@kernel.org>
On Thu, 26 Mar 2026 14:58:47 +0100, Thierry Reding <thierry.reding@kernel.org> wrote:
> [...]
> 16 files changed, 4629 insertions(+), 955 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> create mode 100644 drivers/pci/controller/pcie-tegra264.c
>
> --
> 2.52.0
Thank you! Works nicely.
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Mikko Perttunen <mperttunen@nvidia.com>
--
^ permalink raw reply
* [PATCH v2] staging: nvec: validate battery response length before memcpy
From: Sebastian Josue Alba Vives @ 2026-03-29 21:08 UTC (permalink / raw)
To: marvin24
Cc: ac100, linux-tegra, linux-kernel, stable,
Sebastián Alba Vives
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
In nvec_power_notifier(), the response length from the embedded
controller is used directly as the size argument to memcpy() when
copying battery manufacturer, model, and type strings. The
destination buffers (bat_manu, bat_model, bat_type) are fixed at
30 bytes, but res->length is a u8 that can be up to 255, allowing
a heap buffer overflow.
Additionally, if res->length is less than 2, the subtraction
res->length - 2 wraps around as an unsigned value, resulting in a
large copy that corrupts kernel heap memory.
Introduce NVEC_BAT_STRING_SIZE to replace the hardcoded buffer
size, store res->length - 2 in a local copy_len variable for
clarity, and add bounds checks before each memcpy to ensure the
copy length does not exceed the destination buffer and that
res->length is at least 2 to prevent unsigned integer underflow.
Tested-by: Marc Dietrich <marvin24@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
v2:
- Introduce NVEC_BAT_STRING_SIZE constant to replace hardcoded
buffer size (Marc Dietrich)
- Store res->length - 2 in local copy_len variable for clarity
(Marc Dietrich)
- Use NVEC_BAT_STRING_SIZE in strncmp call for consistency
drivers/staging/nvec/nvec_power.c | 41 +++++++++++++++++++++----------
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/nvec/nvec_power.c b/drivers/staging/nvec/nvec_power.c
index 2faab9fde..7b7980127 100644
--- a/drivers/staging/nvec/nvec_power.c
+++ b/drivers/staging/nvec/nvec_power.c
@@ -19,6 +19,7 @@
#include "nvec.h"
#define GET_SYSTEM_STATUS 0x00
+#define NVEC_BAT_STRING_SIZE 30
struct nvec_power {
struct notifier_block notifier;
@@ -38,9 +39,9 @@ struct nvec_power {
int bat_temperature;
int bat_cap;
int bat_type_enum;
- char bat_manu[30];
- char bat_model[30];
- char bat_type[30];
+ char bat_manu[NVEC_BAT_STRING_SIZE];
+ char bat_model[NVEC_BAT_STRING_SIZE];
+ char bat_type[NVEC_BAT_STRING_SIZE];
};
enum {
@@ -192,22 +193,36 @@ static int nvec_power_bat_notifier(struct notifier_block *nb,
case TEMPERATURE:
power->bat_temperature = res->plu - 2732;
break;
- case MANUFACTURER:
- memcpy(power->bat_manu, &res->plc, res->length - 2);
- power->bat_manu[res->length - 2] = '\0';
+ case MANUFACTURER: {
+ size_t copy_len = res->length - 2;
+
+ if (res->length < 2 || copy_len > NVEC_BAT_STRING_SIZE - 1)
+ break;
+ memcpy(power->bat_manu, &res->plc, copy_len);
+ power->bat_manu[copy_len] = '\0';
break;
- case MODEL:
- memcpy(power->bat_model, &res->plc, res->length - 2);
- power->bat_model[res->length - 2] = '\0';
+ }
+ case MODEL: {
+ size_t copy_len = res->length - 2;
+
+ if (res->length < 2 || copy_len > NVEC_BAT_STRING_SIZE - 1)
+ break;
+ memcpy(power->bat_model, &res->plc, copy_len);
+ power->bat_model[copy_len] = '\0';
break;
- case TYPE:
- memcpy(power->bat_type, &res->plc, res->length - 2);
- power->bat_type[res->length - 2] = '\0';
+ }
+ case TYPE: {
+ size_t copy_len = res->length - 2;
+
+ if (res->length < 2 || copy_len > NVEC_BAT_STRING_SIZE - 1)
+ break;
+ memcpy(power->bat_type, &res->plc, copy_len);
+ power->bat_type[copy_len] = '\0';
/*
* This differs a little from the spec fill in more if you find
* some.
*/
- if (!strncmp(power->bat_type, "Li", 30))
+ if (!strncmp(power->bat_type, "Li", NVEC_BAT_STRING_SIZE))
power->bat_type_enum = POWER_SUPPLY_TECHNOLOGY_LION;
else
power->bat_type_enum = POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] staging: nvec: validate battery response length before memcpy
From: Marc Dietrich @ 2026-03-29 20:48 UTC (permalink / raw)
To: Sebastian Josue Alba Vives; +Cc: ac100, linux-tegra, linux-kernel, stable
In-Reply-To: <20260324195041.38343-1-sebasjosue84@gmail.com>
Hello Sebastian,
On Tue, 24 Mar 2026, Sebastian Josue Alba Vives wrote:
> In nvec_power_notifier(), the response length from the embedded
> controller is used directly as the size argument to memcpy() when
> copying battery manufacturer, model, and type strings. The
> destination buffers (bat_manu, bat_model, bat_type) are fixed at 30
> bytes, but res->length is a u8 that can be up to 255, allowing a
> heap buffer overflow.
>
> Additionally, if res->length is less than 2, the subtraction
> res->length - 2 wraps around as an unsigned value, resulting in a
> large copy that corrupts kernel heap memory.
>
> Add bounds checks before each memcpy to ensure the copy length does
> not exceed the destination buffer size, and that res->length is at
> least 2 to prevent unsigned integer underflow.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
> ---
> drivers/staging/nvec/nvec_power.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/staging/nvec/nvec_power.c b/drivers/staging/nvec/nvec_power.c
> index 2faab9fde..29beef0a7 100644
> --- a/drivers/staging/nvec/nvec_power.c
> +++ b/drivers/staging/nvec/nvec_power.c
> @@ -193,14 +193,20 @@ static int nvec_power_bat_notifier(struct notifier_block *nb,
> power->bat_temperature = res->plu - 2732;
> break;
> case MANUFACTURER:
> + if (res->length < 2 || res->length - 2 > sizeof(power->bat_manu) - 1)
> + break;
I think this check is a valid one, even if unlikely to fail. Could be a
bit nicer by replacing sizeof() with a contant and storing res->length-2
to some variable, but I guess that's a matter of taste.
Tested-by: Marc Dietrich <marvin24@gmx.de>
Thanks,
Marc
> memcpy(power->bat_manu, &res->plc, res->length - 2);
> power->bat_manu[res->length - 2] = '\0';
> break;
> case MODEL:
> + if (res->length < 2 || res->length - 2 > sizeof(power->bat_model) - 1)
> + break;
> memcpy(power->bat_model, &res->plc, res->length - 2);
> power->bat_model[res->length - 2] = '\0';
> break;
> case TYPE:
> + if (res->length < 2 || res->length - 2 > sizeof(power->bat_type) - 1)
> + break;
> memcpy(power->bat_type, &res->plc, res->length - 2);
> power->bat_type[res->length - 2] = '\0';
> /*
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH v3] mailbox: remove superfluous internal header
From: Jassi Brar @ 2026-03-29 16:18 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Sudeep Holla, Daniel Baluta, Peter Chen,
Fugang Duan, CIX Linux Kernel Upstream Group, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Thierry Reding, Jonathan Hunter, linux-kernel, linux-arm-kernel,
imx, linux-acpi, linux-tegra
In-Reply-To: <20260327151112.5202-2-wsa+renesas@sang-engineering.com>
On Fri, Mar 27, 2026 at 10:11 AM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
> Quite some controller drivers use the defines from the internal header
> already. This prevents controller drivers outside the mailbox directory.
> Move the defines to the public controller header to allow this again as
> the defines are not strictly internal anyhow.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
> ---
>
> Changes since v2:
> * rebased to 7.0-rc5
> * add tag (Thanks, Daniel!)
>
> drivers/mailbox/cix-mailbox.c | 2 --
> drivers/mailbox/hi3660-mailbox.c | 2 --
> drivers/mailbox/imx-mailbox.c | 2 --
> drivers/mailbox/mailbox-sti.c | 2 --
> drivers/mailbox/mailbox.c | 2 --
> drivers/mailbox/mailbox.h | 12 ------------
> drivers/mailbox/omap-mailbox.c | 2 --
> drivers/mailbox/pcc.c | 2 --
> drivers/mailbox/tegra-hsp.c | 2 --
> include/linux/mailbox_controller.h | 5 +++++
> 10 files changed, 5 insertions(+), 28 deletions(-)
> delete mode 100644 drivers/mailbox/mailbox.h
>
> diff --git a/drivers/mailbox/cix-mailbox.c b/drivers/mailbox/cix-mailbox.c
> index 443620e8ae37..864f98f21fc3 100644
> --- a/drivers/mailbox/cix-mailbox.c
> +++ b/drivers/mailbox/cix-mailbox.c
> @@ -12,8 +12,6 @@
> #include <linux/module.h>
> #include <linux/platform_device.h>
>
> -#include "mailbox.h"
> -
> /*
> * The maximum transmission size is 32 words or 128 bytes.
> */
> diff --git a/drivers/mailbox/hi3660-mailbox.c b/drivers/mailbox/hi3660-mailbox.c
> index 17c29e960fbf..9b727a2b54a5 100644
> --- a/drivers/mailbox/hi3660-mailbox.c
> +++ b/drivers/mailbox/hi3660-mailbox.c
> @@ -15,8 +15,6 @@
> #include <linux/platform_device.h>
> #include <linux/slab.h>
>
> -#include "mailbox.h"
> -
> #define MBOX_CHAN_MAX 32
>
> #define MBOX_RX 0x0
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> index 003f9236c35e..22331b579489 100644
> --- a/drivers/mailbox/imx-mailbox.c
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -23,8 +23,6 @@
> #include <linux/slab.h>
> #include <linux/workqueue.h>
>
> -#include "mailbox.h"
> -
> #define IMX_MU_CHANS 24
> /* TX0/RX0/RXDB[0-3] */
> #define IMX_MU_SCU_CHANS 6
> diff --git a/drivers/mailbox/mailbox-sti.c b/drivers/mailbox/mailbox-sti.c
> index b4b5bdd503cf..b6c9ecbbc8ec 100644
> --- a/drivers/mailbox/mailbox-sti.c
> +++ b/drivers/mailbox/mailbox-sti.c
> @@ -21,8 +21,6 @@
> #include <linux/property.h>
> #include <linux/slab.h>
>
> -#include "mailbox.h"
> -
> #define STI_MBOX_INST_MAX 4 /* RAM saving: Max supported instances */
> #define STI_MBOX_CHAN_MAX 20 /* RAM saving: Max supported channels */
>
> diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> index e63b2292ee7a..9d41a1ab9018 100644
> --- a/drivers/mailbox/mailbox.c
> +++ b/drivers/mailbox/mailbox.c
> @@ -18,8 +18,6 @@
> #include <linux/property.h>
> #include <linux/spinlock.h>
>
> -#include "mailbox.h"
> -
> static LIST_HEAD(mbox_cons);
> static DEFINE_MUTEX(con_mutex);
>
> diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h
> deleted file mode 100644
> index e1ec4efab693..000000000000
> --- a/drivers/mailbox/mailbox.h
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -
> -#ifndef __MAILBOX_H
> -#define __MAILBOX_H
> -
> -#include <linux/bits.h>
> -
> -#define TXDONE_BY_IRQ BIT(0) /* controller has remote RTR irq */
> -#define TXDONE_BY_POLL BIT(1) /* controller can read status of last TX */
> -#define TXDONE_BY_ACK BIT(2) /* S/W ACK received by Client ticks the TX */
> -
> -#endif /* __MAILBOX_H */
> diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
> index d9f100c18895..5772c6b9886a 100644
> --- a/drivers/mailbox/omap-mailbox.c
> +++ b/drivers/mailbox/omap-mailbox.c
> @@ -22,8 +22,6 @@
> #include <linux/pm_runtime.h>
> #include <linux/mailbox_controller.h>
>
> -#include "mailbox.h"
> -
> #define MAILBOX_REVISION 0x000
> #define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
> #define MAILBOX_FIFOSTATUS(m) (0x080 + 4 * (m))
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 22e70af1ae5d..636879ae1db7 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -59,8 +59,6 @@
> #include <linux/io-64-nonatomic-lo-hi.h>
> #include <acpi/pcc.h>
>
> -#include "mailbox.h"
> -
> #define MBOX_IRQ_NAME "pcc-mbox"
>
> /**
> diff --git a/drivers/mailbox/tegra-hsp.c b/drivers/mailbox/tegra-hsp.c
> index ed9a0bb2bcd8..2231050bb5a9 100644
> --- a/drivers/mailbox/tegra-hsp.c
> +++ b/drivers/mailbox/tegra-hsp.c
> @@ -16,8 +16,6 @@
>
> #include <dt-bindings/mailbox/tegra186-hsp.h>
>
> -#include "mailbox.h"
> -
> #define HSP_INT_IE(x) (0x100 + ((x) * 4))
> #define HSP_INT_IV 0x300
> #define HSP_INT_IR 0x304
> diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
> index 80a427c7ca29..16fef421c30c 100644
> --- a/include/linux/mailbox_controller.h
> +++ b/include/linux/mailbox_controller.h
> @@ -3,6 +3,7 @@
> #ifndef __MAILBOX_CONTROLLER_H
> #define __MAILBOX_CONTROLLER_H
>
> +#include <linux/bits.h>
> #include <linux/completion.h>
> #include <linux/device.h>
> #include <linux/hrtimer.h>
> @@ -11,6 +12,10 @@
>
> struct mbox_chan;
>
> +#define TXDONE_BY_IRQ BIT(0) /* controller has remote RTR irq */
> +#define TXDONE_BY_POLL BIT(1) /* controller can read status of last TX */
> +#define TXDONE_BY_ACK BIT(2) /* S/W ACK received by Client ticks the TX */
> +
> /**
> * struct mbox_chan_ops - methods to control mailbox channels
> * @send_data: The API asks the MBOX controller driver, in atomic
> --
> 2.51.0
>
Applied to mailbox/for-next
Thanks
Jassi
^ permalink raw reply
* [GIT PULL] PCI: tegra: Changes for v7.1-rc1
From: Thierry Reding @ 2026-03-29 15:50 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas; +Cc: linux-pci, linux-tegra
From: Thierry Reding <thierry.reding@gmail.com>
Hi Lorenzo, Bjorn,
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-pci
for you to fetch changes up to a0c0906bb09ee2f64690b3b8ffb458b4dbbcb26e:
PCI: tegra: Add Tegra264 support (2026-03-28 15:00:05 +0100)
This is v3 of the Tegra264 PCI patches that can be found here:
https://lore.kernel.org/linux-pci/20260326135855.2795149-1-thierry.reding@kernel.org/
This looks ready now, but if there's any more feedback, I will happily
respin these driver patches.
Note that the shortlog and the diffstat below include the dependencies
from the Tegra tree, and that subset will go in through the ARM SoC tree
as well. Effectively what's new in this pull request is just the two PCI
patches, the rest is only included here to resolve the build time
dependencies.
Thanks,
Thierry
----------------------------------------------------------------
PCI: tegra: Changes for v7.1-rc1
This set of patches uses standard wait times for PCIe link monitoring
and build on top of that to add Tegra264 support. It also includes all
the Tegra-specific build-dependencies.
----------------------------------------------------------------
Thierry Reding (8):
firmware: tegra: bpmp: Rename Tegra239 to Tegra238
soc/tegra: Update BPMP ABI header
firmware: tegra: bpmp: Add tegra_bpmp_get_with_id() function
dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
Merge branch for-7.1/dt-bindings into for-7.1/pci
Merge branch for-7.1/firmware into for-7.1/pci
PCI: Use standard wait times for PCIe link monitoring
PCI: tegra: Add Tegra264 support
.../bindings/pci/nvidia,tegra264-pcie.yaml | 149 +
drivers/firmware/tegra/bpmp.c | 34 +
drivers/pci/controller/Kconfig | 10 +-
drivers/pci/controller/Makefile | 1 +
.../controller/cadence/pcie-cadence-host-common.c | 6 +-
.../pci/controller/cadence/pcie-cadence-lga-regs.h | 5 -
drivers/pci/controller/mobiveil/pcie-mobiveil.c | 4 +-
drivers/pci/controller/mobiveil/pcie-mobiveil.h | 5 -
drivers/pci/controller/pci-aardvark.c | 7 +-
drivers/pci/controller/pcie-tegra264.c | 522 +++
drivers/pci/controller/pcie-xilinx-nwl.c | 9 +-
drivers/pci/controller/plda/pcie-starfive.c | 9 +-
drivers/pci/pci.h | 2 +
include/soc/tegra/bpmp-abi.h | 4573 ++++++++++++++++----
include/soc/tegra/bpmp.h | 8 +
15 files changed, 4412 insertions(+), 932 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
create mode 100644 drivers/pci/controller/pcie-tegra264.c
^ permalink raw reply
* [GIT PULL 7/7] arm64: tegra: Default configuration changes for v7.1-rc1
From: Thierry Reding @ 2026-03-29 15:10 UTC (permalink / raw)
To: arm, soc; +Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-1-thierry.reding@kernel.org>
From: Thierry Reding <thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-arm64-defconfig
for you to fetch changes up to c655a14958363aea8a1d0bbf3358fcee7f89a210:
arm64: tegra: defconfig: Drop redundant ARCH_TEGRA_foo_SOC (2026-03-25 10:49:46 +0100)
Thanks,
Thierry
----------------------------------------------------------------
arm64: tegra: Default configuration changes for v7.1-rc1
Drop the various ARCH_TEGRA_*_SOC options from the default configurations
since they are now enabled by default for ARCH_TEGRA.
----------------------------------------------------------------
Krzysztof Kozlowski (2):
soc/tegra: Make ARCH_TEGRA_SOC_FOO defaults for NVIDIA Tegra
arm64: tegra: defconfig: Drop redundant ARCH_TEGRA_foo_SOC
Thierry Reding (1):
Merge branch 'for-7.1/soc' into for-7.1/arm64/defconfig
arch/arm64/configs/defconfig | 7 -------
drivers/soc/tegra/Kconfig | 11 +++++++++++
2 files changed, 11 insertions(+), 7 deletions(-)
^ permalink raw reply
* [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Thierry Reding @ 2026-03-29 15:10 UTC (permalink / raw)
To: arm, soc; +Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-1-thierry.reding@kernel.org>
From: Thierry Reding <thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-arm64-dt
for you to fetch changes up to c70e6bc11d2008fbb19695394b69fd941ab39030:
arm64: tegra: Add Tegra264 GPIO controllers (2026-03-28 01:36:46 +0100)
Thanks,
Thierry
----------------------------------------------------------------
arm64: tegra: Device tree changes for v7.1-rc1
Various fixes and new additions across a number of devices. GPIO and PCI
are enabled on Tegra264 and the Jetson AGX Thor Developer Kit, allowing
it to boot via network and mass storage.
----------------------------------------------------------------
Diogo Ivo (1):
arm64: tegra: smaug: Enable SPI-NOR flash
Jon Hunter (1):
arm64: tegra: Fix RTC aliases
Prathamesh Shete (1):
arm64: tegra: Add Tegra264 GPIO controllers
Thierry Reding (6):
dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
Merge branch for-7.1/dt-bindings into for-7.1/pci
arm64: tegra: Fix snps,blen properties
arm64: tegra: Drop redundant clock and reset names for TSEC
arm64: tegra: Add PCI controllers on Tegra264
arm64: tegra: Add Jetson AGX Thor Developer Kit support
.../bindings/pci/nvidia,tegra264-pcie.yaml | 149 +++++++++
arch/arm64/boot/dts/nvidia/Makefile | 2 +
arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 12 +
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 -
arch/arm64/boot/dts/nvidia/tegra234-p3701.dtsi | 1 +
arch/arm64/boot/dts/nvidia/tegra234-p3767.dtsi | 1 +
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 6 +-
.../dts/nvidia/tegra264-p4071-0000+p3834-0008.dts | 11 +
.../boot/dts/nvidia/tegra264-p4071-0000+p3834.dtsi | 12 +
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 336 +++++++++++++++++++--
10 files changed, 500 insertions(+), 32 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p4071-0000+p3834-0008.dts
create mode 100644 arch/arm64/boot/dts/nvidia/tegra264-p4071-0000+p3834.dtsi
^ permalink raw reply
* [GIT PULL 5/7] ARM: tegra: Default configuration changes for v7.1-rc1
From: Thierry Reding @ 2026-03-29 15:10 UTC (permalink / raw)
To: arm, soc; +Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-1-thierry.reding@kernel.org>
From: Thierry Reding <thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-arm-defconfig
for you to fetch changes up to 21e380f272415387454d81788f2d62642e1fe93a:
ARM: tegra: defconfig: Drop redundant ARCH_TEGRA_foo_SOC (2026-03-25 10:49:00 +0100)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Default configuration changes for v7.1-rc1
Drop the various ARCH_TEGRA_*_SOC options from the default configurations
since they are now enabled by default for ARCH_TEGRA.
----------------------------------------------------------------
Krzysztof Kozlowski (2):
soc/tegra: Make ARCH_TEGRA_SOC_FOO defaults for NVIDIA Tegra
ARM: tegra: defconfig: Drop redundant ARCH_TEGRA_foo_SOC
Thierry Reding (1):
Merge branch 'for-7.1/soc' into for-7.1/arm/defconfig
arch/arm/configs/multi_v7_defconfig | 4 ----
arch/arm/configs/tegra_defconfig | 4 ----
drivers/soc/tegra/Kconfig | 11 +++++++++++
3 files changed, 11 insertions(+), 8 deletions(-)
^ permalink raw reply
* [GIT PULL 4/7] ARM: tegra: Device tree changes for v7.1-rc1
From: Thierry Reding @ 2026-03-29 15:10 UTC (permalink / raw)
To: arm, soc; +Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-1-thierry.reding@kernel.org>
From: Thierry Reding <thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-arm-dt
for you to fetch changes up to ce74a6c6d88ba9ee29a6b99ac97ffcded577c85d:
ARM: tegra: paz00: Configure WiFi rfkill switch through device tree (2026-03-28 00:56:36 +0100)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Device tree changes for v7.1-rc1
Various improvements for Tegra114 boards, as well as some legacy cleanup
for PAZ00 and Transformers devices.
----------------------------------------------------------------
Dmitry Torokhov (1):
ARM: tegra: paz00: Configure WiFi rfkill switch through device tree
Svyatoslav Ryhel (8):
ARM: tegra: Add SOCTHERM support on Tegra114
ARM: tn7: Adjust panel node
ARM: tegra: lg-x3: Add panel and bridge nodes
ARM: tegra: lg-x3: Add USB and power related nodes
ARM: tegra: lg-x3: Add node for capacitive buttons
ARM: tegra: Add ACTMON node to Tegra114 device tree
ARM: tegra: Add External Memory Controller node on Tegra114
ARM: tegra: transformers: Add connector node
arch/arm/boot/dts/nvidia/tegra114-tn7.dts | 13 +-
arch/arm/boot/dts/nvidia/tegra114.dtsi | 221 +++++++++++++++++++++++
arch/arm/boot/dts/nvidia/tegra20-paz00.dts | 8 +
arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts | 21 ++-
arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 23 +++
arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 33 ++++
arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 174 +++++++++++++++++-
arch/arm/mach-tegra/Makefile | 2 -
arch/arm/mach-tegra/board-paz00.c | 56 ------
arch/arm/mach-tegra/board.h | 2 -
arch/arm/mach-tegra/tegra.c | 4 -
11 files changed, 482 insertions(+), 75 deletions(-)
delete mode 100644 arch/arm/mach-tegra/board-paz00.c
^ permalink raw reply
* [GIT PULL 3/7] firmware: tegra: Changes for v7.1-rc1
From: Thierry Reding @ 2026-03-29 15:10 UTC (permalink / raw)
To: arm, soc; +Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-1-thierry.reding@kernel.org>
From: Thierry Reding <thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-firmware
for you to fetch changes up to e68d494b8946e9060e60427f365107194f90ba0d:
soc/tegra: bpmp: Use ENODEV instead of ENOTSUPP (2026-03-27 16:30:54 +0100)
Thanks,
Thierry
----------------------------------------------------------------
firmware: tegra: Changes for v7.1-rc1
This introduces a new API for the BPMP to be pass along a specifier from
DT when getting a reference from a phandle. This is used to reference
specific instances of the PCI controller on Tegra264. The ABI header for
BPMP is updated to the latest version and BPMP APIs now use the more
intuitive ENODEV instead of the non SUSV4 ENOTSUPP error code for stub
implementations.
----------------------------------------------------------------
Thierry Reding (4):
firmware: tegra: bpmp: Rename Tegra239 to Tegra238
soc/tegra: Update BPMP ABI header
firmware: tegra: bpmp: Add tegra_bpmp_get_with_id() function
soc/tegra: bpmp: Use ENODEV instead of ENOTSUPP
drivers/firmware/tegra/bpmp.c | 34 +
include/soc/tegra/bpmp-abi.h | 4573 +++++++++++++++++++++++++++++++++--------
include/soc/tegra/bpmp.h | 20 +-
3 files changed, 3725 insertions(+), 902 deletions(-)
^ permalink raw reply
* [GIT PULL 2/7] soc/tegra: Changes for v7.1-rc1
From: Thierry Reding @ 2026-03-29 15:10 UTC (permalink / raw)
To: arm, soc; +Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
In-Reply-To: <20260329151045.1443133-1-thierry.reding@kernel.org>
From: Thierry Reding <thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-soc
for you to fetch changes up to 4b23febb6b11cd06183bed3d21b87ba7d6a8a1e0:
MAINTAINERS: Change email address for Thierry Reding (2026-03-28 01:41:07 +0100)
Thanks,
Thierry
----------------------------------------------------------------
soc/tegra: Changes for v7.1-rc1
A number of fixes went into this for the PMC and CBB drivers. The PMC
driver also gains support for Tegra264 and a Kconfig symbol for the
upcoming Tegra238 is added. The various per-generation Kconfig symbols
are now also enabled by default for ARCH_TEGRA in order to reduce the
number of configuration options that need to be explicitly enabled.
----------------------------------------------------------------
Jon Hunter (10):
soc/tegra: pmc: Add kerneldoc for reboot notifier
soc/tegra: pmc: Correct function names in kerneldoc
soc/tegra: pmc: Add kerneldoc for wake-up variables
soc/tegra: pmc: Remove unused AOWAKE definitions
soc/tegra: pmc: Add support for SoC specific AOWAKE offsets
soc/tegra: pmc: Add AOWAKE regs for Tegra264
soc/tegra: pmc: Add Tegra264 wake events
soc/tegra: pmc: Refactor IO pad voltage control
soc/tegra: pmc: Rename has_impl_33v_pwr flag
soc/tegra: pmc: Add IO pads for Tegra264
Krzysztof Kozlowski (1):
soc/tegra: Make ARCH_TEGRA_SOC_FOO defaults for NVIDIA Tegra
Sumit Gupta (4):
soc/tegra: cbb: Add support for CBB fabrics in Tegra238
soc/tegra: cbb: Set ERD on resume for err interrupt
soc/tegra: cbb: Fix incorrect ARRAY_SIZE in fabric lookup tables
soc/tegra: cbb: Fix cross-fabric target timeout lookup
Svyatoslav Ryhel (2):
soc/tegra: pmc: Enable core domain support for Tegra114
soc/tegra: common: Add Tegra114 support to devm_tegra_core_dev_init_opp_table
Thierry Reding (2):
soc/tegra: Add Tegra238 Kconfig symbol
MAINTAINERS: Change email address for Thierry Reding
MAINTAINERS | 14 +-
drivers/soc/tegra/Kconfig | 20 ++
drivers/soc/tegra/cbb/tegra234-cbb.c | 169 ++++++++-
drivers/soc/tegra/common.c | 5 +-
drivers/soc/tegra/pmc.c | 662 ++++++++++++++++++++++-------------
5 files changed, 611 insertions(+), 259 deletions(-)
^ permalink raw reply
* [GIT PULL 1/7] dt-bindings: Changes for v7.1-rc1
From: Thierry Reding @ 2026-03-29 15:10 UTC (permalink / raw)
To: arm, soc; +Cc: Thierry Reding, Jon Hunter, linux-tegra, linux-arm-kernel
From: Thierry Reding <thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-7.1-dt-bindings
for you to fetch changes up to bed2f5b4de6c6fd8f8928f6373ad92e8795c370f:
dt-bindings: arm: tegra: Document Jetson AGX Thor DevKit (2026-03-28 01:05:24 +0100)
Thanks,
Thierry
----------------------------------------------------------------
dt-bindings: Changes for v7.1-rc1
This contains a few conversions to DT schema along with various
additions and fixes to reduce the amount of validation warnings.
Included are also a new binding for the PCIe controller found on
Tegra264 as well as compatible strings for the Jetson AGX Thor
Developer Kit.
----------------------------------------------------------------
Sumit Gupta (1):
dt-bindings: arm: tegra: Add Tegra238 CBB compatible strings
Svyatoslav Ryhel (1):
dt-bindings: display: tegra: Document Tegra20 HDMI port
Thierry Reding (9):
dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
dt-bindings: phy: tegra-xusb: Document Type C support
dt-bindings: clock: tegra124-dfll: Convert to json-schema
dt-bindings: interrupt-controller: tegra: Fix reg entries
dt-bindings: arm: tegra: Add missing compatible strings
dt-bindings: phy: tegra: Document Tegra210 USB PHY
dt-bindings: memory: Add Tegra210 memory controller bindings
dt-bindings: memory: tegra210: Mark EMC as cooling device
dt-bindings: arm: tegra: Document Jetson AGX Thor DevKit
Documentation/devicetree/bindings/arm/tegra.yaml | 56 +++-
.../bindings/arm/tegra/nvidia,tegra234-cbb.yaml | 4 +
.../bindings/clock/nvidia,tegra124-dfll.txt | 155 -----------
.../bindings/clock/nvidia,tegra124-dfll.yaml | 290 +++++++++++++++++++++
.../display/tegra/nvidia,tegra20-hdmi.yaml | 13 +-
.../interrupt-controller/nvidia,tegra20-ictlr.yaml | 23 +-
.../memory-controllers/nvidia,tegra210-emc.yaml | 6 +-
.../memory-controllers/nvidia,tegra210-mc.yaml | 77 ++++++
.../bindings/pci/nvidia,tegra264-pcie.yaml | 149 +++++++++++
.../bindings/phy/nvidia,tegra194-xusb-padctl.yaml | 39 ++-
.../bindings/phy/nvidia,tegra20-usb-phy.yaml | 1 +
11 files changed, 649 insertions(+), 164 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.yaml
create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-mc.yaml
create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
^ permalink raw reply
* Re: [PATCH v9 0/5] PCI: of: Remove max-link-speed generation validation
From: Hans Zhang @ 2026-03-29 14:47 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: lpieralisi, jingoohan1, mani, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260327164250.GA1513325@bhelgaas>
On 3/28/26 00:42, Bjorn Helgaas wrote:
> On Sat, Mar 14, 2026 at 12:55:17AM +0800, Hans Zhang wrote:
>> Hi,
>>
>> This series moves the validation from the common OF function to the
>> individual PCIe controller drivers. To protect against out-of-bounds
>> accesses to the pcie_link_speed[] array, we first introduce a helper
>> function pcie_get_link_speed() that safely returns the speed value
>> (or PCI_SPEED_UNKNOWN) for a given generation number.
>>
>> Then all direct uses of pcie_link_speed[] as an array are converted to
>> use the new helper, ensuring that even if an invalid generation number
>> reaches those code paths, no out-of-bounds access occurs.
>>
>> For several drivers that read the "max-link-speed" property
>> (pci-j721e, brcmstb, mediatek-gen3, rzg3s-host), we add an explicit
>> validation step: if the value is missing, out of range, or unsupported
>> by the hardware, a safe default is used (usually Gen2). Other drivers
>> (mainly DesignWare glue drivers) rely on the helper to safely handle
>> invalid values, but do not yet include fallback logic or warnings.
>>
>> Finally, the range check is removed from of_pci_get_max_link_speed(),
>> so that future PCIe generations can be supported without modifying
>> drivers/pci/of.c.
>
> Thanks for this series.
>
> We still have a couple references to pcie_link_speed[] that bypass
> pcie_get_link_speed(). These are safe because PCI_EXP_LNKSTA_CLS is
> 0xf and pcie_link_speed[] is size 16, but I'm not sure the direct
> reference is necessary.
>
> The array itself is exported, which I suppose we needed for modular
> PCI controller drivers, but we probably don't need it now that
> pcie_get_link_speed() is exported?
>
> $ git grep "\<pcie_link_speed\>"
> drivers/pci/pci-sysfs.c: speed = pcie_link_speed[linkstat & PCI_EXP_LNKSTA_CLS];
> drivers/pci/pci.c: return pcie_link_speed[FIELD_GET(PCI_EXP_LNKSTA_CLS, lnksta)];
> drivers/pci/pci.h:extern const unsigned char pcie_link_speed[];
> drivers/pci/pci.h: bus->cur_bus_speed = pcie_link_speed[linksta & PCI_EXP_LNKSTA_CLS];
> drivers/pci/probe.c:const unsigned char pcie_link_speed[] = {
> drivers/pci/probe.c:EXPORT_SYMBOL_GPL(pcie_link_speed);
> drivers/pci/probe.c: if (speed >= ARRAY_SIZE(pcie_link_speed))
> drivers/pci/probe.c: return pcie_link_speed[speed];
> drivers/pci/probe.c: bus->max_bus_speed = pcie_link_speed[linkcap & PCI_EXP_LNKCAP_SLS];
Hi Bjorn,
Yes, I also realized that this array is directly used in other places.
So I submitted this series and I would appreciate it if you could review
it to ensure its correctness.
See also this series:
https://patchwork.kernel.org/project/linux-pci/patch/20260315160057.127639-1-18255117159@163.com/
Best regards,
Hans
^ permalink raw reply
* Re: [PATCH v1 3/5] dt-bindings: memory: Add Tegra114 memory client IDs
From: Krzysztof Kozlowski @ 2026-03-28 12:11 UTC (permalink / raw)
To: Thierry Reding
Cc: Svyatoslav Ryhel, Rob Herring, Conor Dooley, Thierry Reding,
Jonathan Hunter, Mikko Perttunen, Sumit Gupta, Dmitry Osipenko,
linux-kernel, devicetree, linux-tegra
In-Reply-To: <22870432-521b-40c0-8f4a-93d2c605baa7@kernel.org>
On 28/03/2026 12:40, Krzysztof Kozlowski wrote:
> On 28/03/2026 00:53, Thierry Reding wrote:
>> On Tue, Feb 17, 2026 at 08:22:24AM +0100, Krzysztof Kozlowski wrote:
>>> On 26/01/2026 20:07, Svyatoslav Ryhel wrote:
>>>> Each memory client has unique hardware ID, add these IDs.
>>>>
>>>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>>>> Acked-by: Rob Herring (Arm) <robh@kernel.org>
>>>> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
>>>> ---
>>>> include/dt-bindings/memory/tegra114-mc.h | 67 ++++++++++++++++++++++++
>>>
>>> This is never a separate commit. Squash with the binding.
>>
>> You have previously requested that bindings and driver changes be
>> applied together. If this header file is applied to your memory tree it
>> means I cannot apply the corresponding DT changes until a release later
>> because the defines are part of the header included in the DT bindings
>> patch.
>
> I cannot apply the driver either without it, because it uses it, no?
> Otherwise what is it doing in bindings if the driver is not using it?
>
>>
>> Seems a bit suboptimal. Do you have any good ideas on how to solve that
>
> We listed five already in maintainer soc profile. Are they not good?
>
>> particular issue? The only one that comes to mind is for you to pick up
>> the DT changes as well, though that obviously runs a greater risk of
>> causing merge conflicts down the road.
One more thing:
There is no DTS here and nothing explains (commit msgs, changelogs or
cover letter) that there is any dependency and this was supposed to go
other tree. So the squash-or-not-squash is absolutely irrelevant to your
question/problem how DTS should deal with it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 3/5] dt-bindings: memory: Add Tegra114 memory client IDs
From: Krzysztof Kozlowski @ 2026-03-28 11:40 UTC (permalink / raw)
To: Thierry Reding
Cc: Svyatoslav Ryhel, Rob Herring, Conor Dooley, Thierry Reding,
Jonathan Hunter, Mikko Perttunen, Sumit Gupta, Dmitry Osipenko,
linux-kernel, devicetree, linux-tegra
In-Reply-To: <accXjw2BSCbzMyak@orome>
On 28/03/2026 00:53, Thierry Reding wrote:
> On Tue, Feb 17, 2026 at 08:22:24AM +0100, Krzysztof Kozlowski wrote:
>> On 26/01/2026 20:07, Svyatoslav Ryhel wrote:
>>> Each memory client has unique hardware ID, add these IDs.
>>>
>>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>>> Acked-by: Rob Herring (Arm) <robh@kernel.org>
>>> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
>>> ---
>>> include/dt-bindings/memory/tegra114-mc.h | 67 ++++++++++++++++++++++++
>>
>> This is never a separate commit. Squash with the binding.
>
> You have previously requested that bindings and driver changes be
> applied together. If this header file is applied to your memory tree it
> means I cannot apply the corresponding DT changes until a release later
> because the defines are part of the header included in the DT bindings
> patch.
I cannot apply the driver either without it, because it uses it, no?
Otherwise what is it doing in bindings if the driver is not using it?
>
> Seems a bit suboptimal. Do you have any good ideas on how to solve that
We listed five already in maintainer soc profile. Are they not good?
> particular issue? The only one that comes to mind is for you to pick up
> the DT changes as well, though that obviously runs a greater risk of
> causing merge conflicts down the road.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: tegra: smaug: Enable SPI-NOR flash
From: Thierry Reding @ 2026-03-28 0:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Diogo Ivo
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260203-smaug-spi_flash-v1-1-a6d477ac7055@tecnico.ulisboa.pt>
From: Thierry Reding <treding@nvidia.com>
On Tue, 03 Feb 2026 17:01:17 +0000, Diogo Ivo wrote:
> Add support for the SPI-NOR flash found in Pixel C devices.
>
>
Applied, thanks!
[1/1] arm64: tegra: smaug: Enable SPI-NOR flash
commit: e4722f5510930df0ae2467132f558b90fdc81ee0
Best regards,
--
Thierry Reding <treding@nvidia.com>
^ permalink raw reply
* Re: [PATCH v3] staging: nvec: fix block comment style in nvec.c
From: Thierry Reding @ 2026-03-28 0:21 UTC (permalink / raw)
To: Greg KH
Cc: Oskar Ray-Frayssinet, marvin24, linux-staging, linux-tegra,
linux-kernel
In-Reply-To: <2026031833-pampers-steed-4804@gregkh>
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]
On Wed, Mar 18, 2026 at 03:59:43PM +0100, Greg KH wrote:
> On Mon, Mar 09, 2026 at 11:07:18PM +0100, Oskar Ray-Frayssinet wrote:
> > Fix block comment formatting to use * on subsequent lines
> > and */ on a separate line as required by kernel coding style.
> >
> > Signed-off-by: Oskar Ray-Frayssinet <rayfraytech@gmail.com>
> > ---
> > drivers/staging/nvec/nvec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
> > index e70fafc095f2..0e655f79ea4a 100644
> > --- a/drivers/staging/nvec/nvec.c
> > +++ b/drivers/staging/nvec/nvec.c
> > @@ -659,7 +659,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
> > nvec_tx_set(nvec);
> > to_send = nvec->tx->data[0];
> > nvec->tx->pos = 1;
> > - /* Delay ACK due to AP20 HW Bug
> > + /* delay ACK due to AP20 HW Bug
> > * do not replace by usleep_range
> > */
> > udelay(33);
> > --
> > 2.43.0
> >
> >
>
> This change is not what you documented is changing :(
Hm... this is the 8th version of this patch that I've seen.
I don't know why there was a flurry of these. The checkpatch warning
certainly isn't new, so maybe this was a new wave of janitors or
something? Or maybe people using AI agents to get into kernel
development. Not that it matters much, but it's not a pattern that I've
seen before.
Also, the fact that 7 out of the 8 versions came in after the first had
already landed in linux-next:
29e79c66b3cc ("staging: nvec: fix block comment style in nvec_interrupt()")
suggests that people aren't using linux-next as their baseline. Do we
need to be stricter in this regard? Seems a bit wasteful for you to have
to spend so much time looking at duplicates, even though it seems like
your automation did a lot of the work.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ARM: tegra: paz00: configure WiFi rfkill switch through device tree
From: Thierry Reding @ 2026-03-27 23:57 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Thierry Reding, Marc Dietrich, Krzysztof Kozlowski, Rob Herring,
Conor Dooley, Jonathan Hunter, Bartosz Golaszewski, devicetree,
linux-tegra, linux-kernel, linux-arm-kernel
In-Reply-To: <acRtWZohqfDLbMKE@google.com>
[-- Attachment #1: Type: text/plain, Size: 894 bytes --]
On Wed, Mar 25, 2026 at 04:29:54PM -0700, Dmitry Torokhov wrote:
> As of d64c732dfc9e ("net: rfkill: gpio: add DT support") rfkill-gpio
> device can be instantiated via device tree.
>
> Add the declaration there and drop board-paz00.c file and relevant
> Makefile fragments.
>
> Tested-by: Marc Dietrich <marvin24@gmx.de>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>
> V2:
> - added Marc's Tested-by
>
> V1:
> - https://lore.kernel.org/r/aY_BpRQmLdqOOW2K@google.com
>
> arch/arm/boot/dts/nvidia/tegra20-paz00.dts | 8 ++++
> arch/arm/mach-tegra/Makefile | 2 -
> arch/arm/mach-tegra/board-paz00.c | 56 ----------------------
> arch/arm/mach-tegra/board.h | 2 -
> arch/arm/mach-tegra/tegra.c | 4 --
> 5 files changed, 8 insertions(+), 64 deletions(-)
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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