* RE: [PATCH v5 3/4] iio: adc: ad4691: add triggered buffer support
From: Sabau, Radu bogdan @ 2026-03-30 9:01 UTC (permalink / raw)
To: Nuno Sá, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <324e16aba4029ec4679f7b141c5f58e8929a0da3.camel@gmail.com>
> -----Original Message-----
> From: Nuno Sá <noname.nuno@gmail.com>
> Sent: Saturday, March 28, 2026 11:44 AM
> To: Sabau, Radu bogdan <Radu.Sabau@analog.com>; Lars-Peter Clausen
...
);
> >
> > - return 0;
> > + if (st->manual_mode)
> > + return 0;
> > +
> > + for (gp_num = 0; gp_num < ARRAY_SIZE(ad4691_gp_names);
> gp_num++) {
> > + if (fwnode_irq_get_byname(dev_fwnode(dev),
> > + ad4691_gp_names[gp_num]) > 0)
>
> Don't love this line break. I'm also a bit puzzled. How does the above differs
> from
> the trigger code? I guess this should be the same GP pin?
>
>
Hi Nuno,
You are right - both loops scan ad4691_gp_names[] independently and must
agree by construction, which is fragile. While gpio_setup() needs to happen,
there is no reason for it to live on ad4691_config(), since setup_triggered_buffer
is only called for the non-offload path and already iterates gp_names[] to find
the IRQ. So we can call gpio_setup right there and frop the lookup from
ad4691_config() entirely, and no need for those early returns either.
Thanks,
Radu
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: sdm670-google-common: enable debug uart
From: Konrad Dybcio @ 2026-03-30 9:34 UTC (permalink / raw)
To: pabloyoyoista, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Richard Acayan,
~postmarketos/upstreaming
In-Reply-To: <20260328-pabloyoyoista-debug-uart-on-rdacayan-next-v2-3-53abd9db8f0a@postmarketos.org>
On 3/28/26 11:58 PM, Pablo Correa Gómez via B4 Relay wrote:
> From: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
>
> This has been tested on the Pixel 3a with USB Cereal board
>
> Depends on
> https://lore.kernel.org/all/20260310002606.16413-5-mailingradian@gmail.com/
>
> Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: sdm670: add debug uart soc node
From: Konrad Dybcio @ 2026-03-30 9:33 UTC (permalink / raw)
To: pabloyoyoista, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Richard Acayan,
~postmarketos/upstreaming
In-Reply-To: <20260328-pabloyoyoista-debug-uart-on-rdacayan-next-v2-2-53abd9db8f0a@postmarketos.org>
On 3/28/26 11:58 PM, Pablo Correa Gómez via B4 Relay wrote:
> From: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
>
> Values are taken from the other geni nodes
>
> Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v8 2/3] hwmon: ltc4283: Add support for the LTC4283 Swap Controller
From: Nuno Sá @ 2026-03-30 9:28 UTC (permalink / raw)
To: Nuno Sá
Cc: linux-gpio, linux-hwmon, devicetree, linux-doc, Guenter Roeck,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <20260327-ltc4283-support-v8-2-471de255d728@analog.com>
Hi Guenter, Regarding AI review, I think most of the points were
discussed in previous revisions, but there are two valid.
On Fri, Mar 27, 2026 at 05:26:15PM +0000, Nuno Sá wrote:
> Support the LTC4283 Hot Swap Controller. The device features programmable
> current limit with foldback and independently adjustable inrush current to
> optimize the MOSFET safe operating area (SOA). The SOA timer limits MOSFET
> temperature rise for reliable protection against overstresses.
>
> An I2C interface and onboard ADC allow monitoring of board current,
> voltage, power, energy, and fault status.
>
> Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> ---
> Documentation/hwmon/index.rst | 1 +
> Documentation/hwmon/ltc4283.rst | 266 ++++++
> MAINTAINERS | 1 +
> drivers/hwmon/Kconfig | 12 +
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/ltc4283.c | 1796 +++++++++++++++++++++++++++++++++++++++
> 6 files changed, 2077 insertions(+)
>
...
> +static int ltc4283_read_in_alarm(struct ltc4283_hwmon *st, u32 channel,
> + bool max_alm, long *val)
> +{
> + if (channel == LTC4283_VPWR)
> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_1,
> + BIT(2 + max_alm), val);
> +
> + if (channel >= LTC4283_CHAN_ADI_1 && channel <= LTC4283_CHAN_ADI_4) {
> + u32 bit = (channel - LTC4283_CHAN_ADI_1) * 2;
> + /*
> + * Lower channels go to higher bits. We also want to go +1 down
> + * in the min_alarm case.
> + */
> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_2,
> + BIT(7 - bit - !max_alm), val);
> + }
> +
> + if (channel >= LTC4283_CHAN_ADIO_1 && channel <= LTC4283_CHAN_ADIO_4) {
> + u32 bit = (channel - LTC4283_CHAN_ADIO_1) * 2;
> +
> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_3,
> + BIT(7 - bit - !max_alm), val);
> + }
> +
> + if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIN34) {
> + u32 bit = (channel - LTC4283_CHAN_ADIN12) * 2;
> +
> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_5,
> + BIT(7 - bit - !max_alm), val);
> + }
"Will this condition handle the ADIO12 and ADIO34 differential channels?
It looks like channels 14 and 15 fall through to the default return intended
for the DRAIN channel. Since reading the alarm implicitly clears the register
bits, could reading these ADIO alarms unintentionally clear actual DRAIN
alarms? Should the upper bound be LTC4283_CHAN_ADIO34?"
Good catch and should be:
- if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIN34) {
+ if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIO34) {
> +
> + if (channel == LTC4283_CHAN_DRNS)
> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_4,
> + BIT(6 + max_alm), val);
> +
> + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_4, BIT(4 + max_alm),
> + val);
> +}
...
> +
> +static int ltc4283_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev, *hwmon;
> + struct auxiliary_device *adev;
> + struct ltc4283_hwmon *st;
> + int ret;
> +
> + st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
> + if (!st)
> + return -ENOMEM;
> +
> + if (!i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_BYTE_DATA |
> + I2C_FUNC_SMBUS_WORD_DATA |
> + I2C_FUNC_SMBUS_READ_I2C_BLOCK))
> + return -EOPNOTSUPP;
> +
> + st->client = client;
> + st->map = devm_regmap_init(dev, <c4283_regmap_bus, client,
> + <c4283_regmap_config);
> + if (IS_ERR(st->map))
> + return dev_err_probe(dev, PTR_ERR(st->map),
> + "Failed to create regmap\n");
> +
> + ret = ltc4283_setup(st, dev);
> + if (ret)
> + return ret;
> +
> + hwmon = devm_hwmon_device_register_with_info(dev, "ltc4283", st,
> + <c4283_chip_info, NULL);
> +
> + if (IS_ERR(hwmon))
> + return PTR_ERR(hwmon);
> +
> + ltc4283_debugfs_init(st, client);
> +
> + if (!st->gpio_mask)
> + return 0;
> +
> + adev = devm_auxiliary_device_create(dev, "gpio", &st->gpio_mask);
> + if (!adev)
> + return dev_err_probe(dev, -ENODEV, "Failed to add GPIO device\n");
"Does this allow multiple LTC4283 chips to probe successfully?
Without allocating a unique ID per I2C instance, it seems the first probed
chip takes the generic name. If a second chip is present, it might attempt
to register with the exact same name, resulting in a failure in device_add()
and aborting the probe."
Also looks valid and I suspect is one of those that a quick look will
find more "offenders". I would purpose:
- adev = devm_auxiliary_device_create(dev, "gpio", &st->gpio_mask);
+ adev = __devm_auxiliary_device_create(dev, KBUILD_MODNAME, "gpio",
+ &st->gpio_mask, client->addr);
If there's nothing else and you agree with the above, is this something
you can tweak while applying or should I spin a new version?
Thanks!
- Nuno Sá
^ permalink raw reply
* Re: [PATCH v4 2/2] pinctrl: qcom: Introduce IPQ5210 TLMM driver
From: Kathiravan Thirumoorthy @ 2026-03-30 9:27 UTC (permalink / raw)
To: Linus Walleij, Mukesh Ojha
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-gpio, devicetree, linux-kernel,
Konrad Dybcio
In-Reply-To: <CAD++jLkp0AfxUqAHzjJjS8k_NcbHyT4qy=yPhUwbvAYXcAhdZw@mail.gmail.com>
On 3/30/2026 2:19 PM, Linus Walleij wrote:
> On Mon, Mar 30, 2026 at 10:45 AM Linus Walleij <linusw@kernel.org> wrote:
>> right before merging this patch I merged:
>> https://lore.kernel.org/linux-gpio/20260327171240.3222755-2-mukesh.ojha@oss.qualcomm.com/
>>
>> On Mon, Mar 30, 2026 at 6:51 AM Kathiravan Thirumoorthy
>> <kathiravan.thirumoorthy@oss.qualcomm.com> wrote:
>>
>>> + .intr_status_reg = 0xc + REG_SIZE * id, \
>>> + .intr_target_reg = 0x8 + REG_SIZE * id, \
>> (...)
>>
>> Should intr_target_reg be dropped also from this driver?
>>
>> If so, please send a follow-up patch.
> After reading closer I can see it definitely should be dropped
> so I just augmented the patch.
>
> No need to do anything.
Hi Linus,
Thanks, I noticed the Mukesh's change and I thought I can send the
follow-up patch. But thanks for taking care of this.
Thanks,
Kathiravan T.
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-30 9:25 UTC (permalink / raw)
To: Neil Armstrong, Bryan O'Donoghue, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Vladimir Zapolskiy, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <76ea03d0-d41b-4880-a48c-06570eb089ed@linaro.org>
On 30/03/2026 10:17, Neil Armstrong wrote:
> On 3/30/26 11:02, Bryan O'Donoghue wrote:
>> On 30/03/2026 08:49, Neil Armstrong wrote:
>>> On 3/27/26 18:42, Bryan O'Donoghue wrote:
>>>> On 27/03/2026 15:28, Neil Armstrong wrote:
>>>>>> To be frankly honest you can make an argument for it either way. However my honestly held position is analysing other upstream implementations connecting to the PHY means we can't make the PHY device a drivers/phy device - it would have to be a V4L2 device and then for me the question is why is that even required ?
>>>>>
>>>>> This is plain wrong, DT definition is different from software implementation, you can do whatever you want if you describe HW accurately.
>>>>
>>>> I'm not sure what point it is you are trying to make here. Are you trying to say drivers/phy is OK with you but you want an endpoint ? If so, please just say so.
>>>
>>> I'm against using the "phys = <>" property in the CAMSS to reference the PHYs, a "PHY" in the classic terminology is tied to a single consumer, and if it can be shared to multiple consumer you must model a mux or whatever in the middle.
>>
>> The CSIPHY-to-CSID routing is runtime-configurable and is already managed by the media controller framework.
>
> This is not compatible with the PHY bindings if you don't have a defined MUX device in the middle, it's wrong. You're hiding the muxing details in the CAMSS blob node.
>
>>
>> DT describes static hardware connections. The dynamic mux is a software concern, not a hardware description concern.
>
> DT must describe the possible interconnections between the nodes, if a PHY can be used by multiple hardware components, it must be described.
But right now the CAMSS block is described as a single block. There is
no CSID device in the kernel _yet_.
When we break CSID into its own block then fine, lets have a debate
about a mux then but right now the "nodes" are CAMSS[MONOLITH] <=>
CSIPHY there is no DT CSID device to model this to.
>
>>
>>
>>> The PHY API as an internal software implementation is probably fine, even if it makes implementation of split mode much much harder and doesn't really solve anything, you can just call init()/poweron()/ poweroff()/exit() directly from the CSIPHY media callbacks.
>>
>> Great.
>>
>>>> I can see an argument for that hence my response to Konrad, I just don't see why its a Qualcomm specific argument and of course understood stuff bubbles up in review, we have a public debate and come to a consensus - that's a good thing.
>>>>
>>>> However, I'd want wider buy-in and understanding that endpoints in the PHYs is a more accurate description of the data-flow.
>>>
>>> It is, and it was designed for that, and extensively used in the media DT representation, so I wonder here you would not use it...
>>> In an ideal world, you would add nodes for each CAMSS hw elements and adds port/endpoints links between all nodes to describe the data graph, this would be used to construct the media controller graph, and make it much easier supporting new hardware.
>>
>> Yes but be pragmatic Neil. The first step in making the monolith into sub-nodes is the CSIPHY.
>
> I am, and I agree it's fine to do it step by step.
Cool.
So let's talk about muxing to CSID devices, when we have CSID devices in
the DT.
>>
>> Once the CSIPHY is in, we can follow on with adding new nodes that way IPE, BPS, ICP, JPEG whatever and also work on implementing the old stuff in that new way.
>
> I agree on the approach, I never said otherwise, but you need to have the big picture in mind.
>
> When you'll have the CSID subnodes, where will you add the phys properties ? you'll keep them in the CAMSS top node ? add all CSIPHY to all CSID nodes ? this is wrong and this needs to be fixed now.
>
>>
>>
>>>
>>>>
>>>> We've been applying DT bindings aplenty without that so far. So we would establish new CSI2 PHY bindings should represent the sensor endpoints.
>>>
>>> We've been using a dummy representation of CAMM in a single node with only endpoints connecting to the sensors and hiding all the hardware layout in code, it doesn't scale and makes supporting new HW hard.
>>> I mean this is common sense, why would we continue to stick to the current CAMSS bindings ???
>>
>> We _won't_ I just don't support a big bang integration. Progressive changes over a longer timeline make the transition manageable, without accepting endless sub-standard stuff in the meantime or holding up all new SoC submission unless/until.
>>
>> I mean there is a CAMSS meeting which I've been running for nearly a year now that both you and Vlad are invited to where we have been discussing this for months...
>>
>> Anyway one conclusion of that is we want to transition to individual nodes for everything.
>>
>> PHY is the first step which I'm taking because its easier for me as CAMSS maintainer to convince the CAMSS maintainer to take the relevant patches.
>>
>> drivers/phy notwithstanding.
>
> As I said I agree on the progressive approach, not the PHY DT bindins approach.
>
>>
>>>>
>>>> Is that what you want ?
>>>>
>>>>> The CSIPHYs are not tied to a single "consumer" block, they can be connected to different consumers at runtime, which is not something classic PHY devices are designed for. So they are de facto a media element in the dynamic camera pipeline.
>>>>
>>>> The existing CAMSS binding and media graph are not changed by this series.
>>>
>>> This is not my point, I don't care about the software implementation at all, I care about accurate hardware representation. Using the "phys = <>" property does not describe hardware accurately.
>>>
>>> In other words: The CSIPHY are not connected to CAMSS. This is _not_ true, tying the CSIPHYs to the CAMSS block hides the real data muxing in software.
>>>
>>> Please remind DT is used by multiple operating systems, and properly describing hardware in DT will help have good software support over all OSes, not just Linux.
>>>
>>>>
>>>>> And actually Rob Herring asked use to define the complete data flow, it was a strong requirement. I don't see why we wouldn't here.
>>>>
>>>> I'm implementing feedback from Rob.
>>>>
>>>> https://lore.kernel.org/linux-media/20250710230846.GA44483- robh@kernel.org/
>>>
>>> Where did he ask using the PHY DT bindings ? Is he aware those CSIPHYs are muxed to multiple consumers which are burried in the CAMSS code ?
>>
>> I freely admit to taking the initiative of phys = <> but Neil there is _no_change_ to the media graph and the "mux" is a runtime configuration that is one register in the CSID.
>
> Honestly I don't care about the userspace media graph, this is a software problem and we can totally make the transition seamless if we want.
>
> Don't limit the DT hardware description because of a software userspace ABI breakage, this approach is not the right one.
>
>>
>> You seriously want a mux device in the kernel to model one bit in a register ?
>
> Why not ? We have drivers that even toggles even single bit to solve those kind of situations.
>
> Physically they're a mux to route the CSIPHY to the consumers, it's a fact... even if it's a register or a single bit.
That's fine. I can understanding making that case if/when CSID becomes
its own node but, I don't think it makes sense when connecting the PHY
back to the monolith.
---
bod
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: power: qcom-rpmpd: Split MSM8953 and SDM632
From: Konrad Dybcio @ 2026-03-30 9:24 UTC (permalink / raw)
To: Barnabás Czémán, Dmitry Baryshkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold,
linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc
In-Reply-To: <39a320e472ddc6d44c950a995b577e77@mainlining.org>
On 3/28/26 9:22 AM, Barnabás Czémán wrote:
> On 2026-03-27 21:26, Dmitry Baryshkov wrote:
>> On Fri, Mar 27, 2026 at 09:11:43PM +0100, Barnabás Czémán wrote:
>>> Remove modem related bindings from MSM8953 rpmpd because MSM8953 MSS
>>> is using mss-supply as a regulator usually it is pm8953_s1.
>>> Split SDM632 bindings from MSM8953 because SDM632 is using mss-supply
>>> as a pm domain.
>>>
>>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
>>> ---
>>> .../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
>>> include/dt-bindings/power/qcom-rpmpd.h | 20 +++++++++++++-------
>>> 2 files changed, 14 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
>>> index 8174ceeab572..659936d6a46e 100644
>>> --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
>>> +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
>>> @@ -48,6 +48,7 @@ properties:
>>> - qcom,sc7280-rpmhpd
>>> - qcom,sc8180x-rpmhpd
>>> - qcom,sc8280xp-rpmhpd
>>> + - qcom,sdm632-rpmpd
>>> - qcom,sdm660-rpmpd
>>> - qcom,sdm670-rpmhpd
>>> - qcom,sdm845-rpmhpd
>>> diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
>>> index 4371ac941f29..2d82434b993c 100644
>>> --- a/include/dt-bindings/power/qcom-rpmpd.h
>>> +++ b/include/dt-bindings/power/qcom-rpmpd.h
>>> @@ -84,13 +84,11 @@
>>> #define QM215_VDDMX_AO MSM8917_VDDMX_AO
>>>
>>> /* MSM8953 Power Domain Indexes */
>>> -#define MSM8953_VDDMD 0
>>> -#define MSM8953_VDDMD_AO 1
>>> -#define MSM8953_VDDCX 2
>>> -#define MSM8953_VDDCX_AO 3
>>> -#define MSM8953_VDDCX_VFL 4
>>> -#define MSM8953_VDDMX 5
>>> -#define MSM8953_VDDMX_AO 6
>>> +#define MSM8953_VDDCX RPMPD_VDDCX
>>> +#define MSM8953_VDDCX_AO RPMPD_VDDCX_AO
>>> +#define MSM8953_VDDCX_VFL RPMPD_VDDCX_VFL
>>> +#define MSM8953_VDDMX RPMPD_VDDMX
>>> +#define MSM8953_VDDMX_AO RPMPD_VDDMX_AO
>>
>> Well, no. This is an ABI break. It will make previous DT to stop from
>> working. You can drop unused indices, but you can not change the values
>> used by the existing domains.
> Do these indices never can be changed?
Yes, values in include/dt-bindings are supposed to never change
Here you're e.g. changing the "msm8953 domain 0" from translating into
VDDMD to translating into VDDCX (because RPMPD_VDDCX is defined as 0)
Some other older platforms were converted to use these macros, because
the indices happened to match
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: kaanpaali: Add USB support for MTP platform
From: Konrad Dybcio @ 2026-03-30 9:19 UTC (permalink / raw)
To: Krishna Kurapati, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang
In-Reply-To: <20260329175249.2946508-3-krishna.kurapati@oss.qualcomm.com>
On 3/29/26 7:52 PM, Krishna Kurapati wrote:
> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>
> Enable USB support on Kaanapali MTP variant. Enable USB controller in
> device mode till glink node is added.
>
> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> index a603f3056d83..38269aebdf03 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> @@ -82,6 +82,11 @@ key-volume-up {
> };
> };
>
> + pmih0108_e1_eusb2_repeater {
Huh??
You're creating a new node here - /pmih0108_e1_eusb2_repeater{}
I believe your intent was to override it by label
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
From: Konrad Dybcio @ 2026-03-30 9:18 UTC (permalink / raw)
To: Krishna Kurapati, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang
In-Reply-To: <20260329175249.2946508-2-krishna.kurapati@oss.qualcomm.com>
On 3/29/26 7:52 PM, Krishna Kurapati wrote:
> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>
> Add the base USB devicetree definitions for Kaanapali platform. The overall
> chipset contains a single DWC3 USB3 controller (rev. 200a), SS QMP PHY
> (rev. v8) and M31 eUSB2 PHY.
>
> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
[...]
> + usb: usb@a600000 {
> + compatible = "qcom,kaanapali-dwc3", "qcom,snps-dwc3";
> + reg = <0x0 0x0a600000 0x0 0xfc100>;
Following the woes on Hamoa, can the platform suspend and wake up
succesfully with the flattened DT node?
Konrad
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Neil Armstrong @ 2026-03-30 9:17 UTC (permalink / raw)
To: Bryan O'Donoghue, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <456ded59-d13e-4b61-975b-97ca48b5e771@linaro.org>
On 3/30/26 11:02, Bryan O'Donoghue wrote:
> On 30/03/2026 08:49, Neil Armstrong wrote:
>> On 3/27/26 18:42, Bryan O'Donoghue wrote:
>>> On 27/03/2026 15:28, Neil Armstrong wrote:
>>>>> To be frankly honest you can make an argument for it either way. However my honestly held position is analysing other upstream implementations connecting to the PHY means we can't make the PHY device a drivers/phy device - it would have to be a V4L2 device and then for me the question is why is that even required ?
>>>>
>>>> This is plain wrong, DT definition is different from software implementation, you can do whatever you want if you describe HW accurately.
>>>
>>> I'm not sure what point it is you are trying to make here. Are you trying to say drivers/phy is OK with you but you want an endpoint ? If so, please just say so.
>>
>> I'm against using the "phys = <>" property in the CAMSS to reference the PHYs, a "PHY" in the classic terminology is tied to a single consumer, and if it can be shared to multiple consumer you must model a mux or whatever in the middle.
>
> The CSIPHY-to-CSID routing is runtime-configurable and is already managed by the media controller framework.
This is not compatible with the PHY bindings if you don't have a defined MUX device in the middle, it's wrong. You're hiding the muxing details in the CAMSS blob node.
>
> DT describes static hardware connections. The dynamic mux is a software concern, not a hardware description concern.
DT must describe the possible interconnections between the nodes, if a PHY can be used by multiple hardware components, it must be described.
>
>
>> The PHY API as an internal software implementation is probably fine, even if it makes implementation of split mode much much harder and doesn't really solve anything, you can just call init()/poweron()/ poweroff()/exit() directly from the CSIPHY media callbacks.
>
> Great.
>
>>> I can see an argument for that hence my response to Konrad, I just don't see why its a Qualcomm specific argument and of course understood stuff bubbles up in review, we have a public debate and come to a consensus - that's a good thing.
>>>
>>> However, I'd want wider buy-in and understanding that endpoints in the PHYs is a more accurate description of the data-flow.
>>
>> It is, and it was designed for that, and extensively used in the media DT representation, so I wonder here you would not use it...
>> In an ideal world, you would add nodes for each CAMSS hw elements and adds port/endpoints links between all nodes to describe the data graph, this would be used to construct the media controller graph, and make it much easier supporting new hardware.
>
> Yes but be pragmatic Neil. The first step in making the monolith into sub-nodes is the CSIPHY.
I am, and I agree it's fine to do it step by step.
>
> Once the CSIPHY is in, we can follow on with adding new nodes that way IPE, BPS, ICP, JPEG whatever and also work on implementing the old stuff in that new way.
I agree on the approach, I never said otherwise, but you need to have the big picture in mind.
When you'll have the CSID subnodes, where will you add the phys properties ? you'll keep them in the CAMSS top node ? add all CSIPHY to all CSID nodes ? this is wrong and this needs to be fixed now.
>
>
>>
>>>
>>> We've been applying DT bindings aplenty without that so far. So we would establish new CSI2 PHY bindings should represent the sensor endpoints.
>>
>> We've been using a dummy representation of CAMM in a single node with only endpoints connecting to the sensors and hiding all the hardware layout in code, it doesn't scale and makes supporting new HW hard.
>> I mean this is common sense, why would we continue to stick to the current CAMSS bindings ???
>
> We _won't_ I just don't support a big bang integration. Progressive changes over a longer timeline make the transition manageable, without accepting endless sub-standard stuff in the meantime or holding up all new SoC submission unless/until.
>
> I mean there is a CAMSS meeting which I've been running for nearly a year now that both you and Vlad are invited to where we have been discussing this for months...
>
> Anyway one conclusion of that is we want to transition to individual nodes for everything.
>
> PHY is the first step which I'm taking because its easier for me as CAMSS maintainer to convince the CAMSS maintainer to take the relevant patches.
>
> drivers/phy notwithstanding.
As I said I agree on the progressive approach, not the PHY DT bindins approach.
>
>>>
>>> Is that what you want ?
>>>
>>>> The CSIPHYs are not tied to a single "consumer" block, they can be connected to different consumers at runtime, which is not something classic PHY devices are designed for. So they are de facto a media element in the dynamic camera pipeline.
>>>
>>> The existing CAMSS binding and media graph are not changed by this series.
>>
>> This is not my point, I don't care about the software implementation at all, I care about accurate hardware representation. Using the "phys = <>" property does not describe hardware accurately.
>>
>> In other words: The CSIPHY are not connected to CAMSS. This is _not_ true, tying the CSIPHYs to the CAMSS block hides the real data muxing in software.
>>
>> Please remind DT is used by multiple operating systems, and properly describing hardware in DT will help have good software support over all OSes, not just Linux.
>>
>>>
>>>> And actually Rob Herring asked use to define the complete data flow, it was a strong requirement. I don't see why we wouldn't here.
>>>
>>> I'm implementing feedback from Rob.
>>>
>>> https://lore.kernel.org/linux-media/20250710230846.GA44483- robh@kernel.org/
>>
>> Where did he ask using the PHY DT bindings ? Is he aware those CSIPHYs are muxed to multiple consumers which are burried in the CAMSS code ?
>
> I freely admit to taking the initiative of phys = <> but Neil there is _no_change_ to the media graph and the "mux" is a runtime configuration that is one register in the CSID.
Honestly I don't care about the userspace media graph, this is a software problem and we can totally make the transition seamless if we want.
Don't limit the DT hardware description because of a software userspace ABI breakage, this approach is not the right one.
>
> You seriously want a mux device in the kernel to model one bit in a register ?
Why not ? We have drivers that even toggles even single bit to solve those kind of situations.
Physically they're a mux to route the CSIPHY to the consumers, it's a fact... even if it's a register or a single bit.
>
> No.
>
>>>
>>> To me, here is where we stand:
>>>
>>> - Individual nodes - we all agree that
>>> - As sub-nodes - I think the majority agrees this Krzsztof, Dmitry
>>> I'm fine with it too.
>>> - drivers/phy - I think we are accepting this is also fine ?
>>
>> Like I said this adds a supplementary API layer for no reason and will make life harder, but I don't care personally.
>>
>>> - endpoints should flow into the PHY and then back to the controller
>>>
>>> I get that argument. In fact I _like_ that argument at least I like my conception of that argument.
>>>
>>> I'll stipulate to that argument meaning then that, new CSI2 PHYs shall include endpoints for this purpose globally.
>>>
>>> As I've said before, there's nothing Qualcomm specific about this discussion, really.
>>
>> There is, because the current Qualcomm CAMSS bindings are insufficient and should be entirely redesigned from the ground up to properly describe the HW.
>
> The long term plan is to do that. Discussed extensively with the Qcom teams delivering CAMSS, even invited community members along.
>
> Here are the meeting notes - its all in the public domain
>
> https://docs.google.com/document/d/1yUwWHaKLuovKVgGTzvKm68K1zS6xBONVzjOsRjDl03U/edit?tab=t.0#heading=h.mtbm7qfohwfs
>
> ---
> bod
^ permalink raw reply
* Re: [PATCH v5 3/9] mmc: sdhci-of-k1: add regulator and pinctrl voltage switching support
From: Troy Mitchell @ 2026-03-30 9:15 UTC (permalink / raw)
To: Iker Pedrosa, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Adrian Hunter, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: Michael Opdenacker, Javier Martinez Canillas, linux-mmc,
devicetree, linux-riscv, spacemit, linux-kernel, Anand Moon,
Trevor Gamblin, Troy Mitchell
In-Reply-To: <20260330-orangepi-sd-card-uhs-v5-3-bd853604322d@gmail.com>
On Mon, Mar 30, 2026 at 16:38:04 CST, Iker Pedrosa wrote:
> Add voltage switching infrastructure for UHS-I modes by integrating both
> regulator framework (for supply voltage control) and pinctrl state
> switching (for pin drive strength optimization).
>
> - Add regulator supply parsing and voltage switching callback
> - Add optional pinctrl state switching between "default" (3.3V) and
> "state_uhs" (1.8V) configurations
> - Enable coordinated voltage and pin configuration changes for UHS modes
>
> This provides complete voltage switching support while maintaining
> backward compatibility when pinctrl states are not defined.
>
> Tested-by: Anand Moon <linux.amoon@gmail.com>
> Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.dev>
^ permalink raw reply
* Re: [PATCH v11 10/11] arm64: kexec: Add support for crashkernel CMA reservation
From: Breno Leitao @ 2026-03-30 9:13 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, feng.tang, pawan.kumar.gupta, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, ardb, cfsworks, osandov, jbohac,
tangyouling, sourabhjain, ritesh.list, eajames, songshuaishuai,
kevin.brodsky, vishal.moola, junhui.liu, coxu, fuqiang.wang,
liaoyuanhong, guoren, chenjiahao16, hbathini, takahiro.akashi,
james.morse, lizhengyu3, x86, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv,
devicetree, kexec
In-Reply-To: <20260328074013.3589544-11-ruanjinjie@huawei.com>
On Sat, Mar 28, 2026 at 03:40:12PM +0800, Jinjie Ruan wrote:
> Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the
> crashkernel= command line option") and commit ab475510e042 ("kdump:
> implement reserve_crashkernel_cma") added CMA support for kdump
> crashkernel reservation.
>
> Crash kernel memory reservation wastes production resources if too
> large, risks kdump failure if too small, and faces allocation difficulties
> on fragmented systems due to contiguous block constraints. The new
> CMA-based crashkernel reservation scheme splits the "large fixed
> reservation" into a "small fixed region + large CMA dynamic region": the
> CMA memory is available to userspace during normal operation to avoid
> waste, and is reclaimed for kdump upon crash—saving memory while
> improving reliability.
>
> So extend crashkernel CMA reservation support to arm64. The following
> changes are made to enable CMA reservation:
>
> - Parse and obtain the CMA reservation size along with other crashkernel
> parameters.
> - Call reserve_crashkernel_cma() to allocate the CMA region for kdump.
> - Include the CMA-reserved ranges for kdump kernel to use.
> - Exclude the CMA-reserved ranges from the crash kernel memory to
> prevent them from being exported through /proc/vmcore, which is already
> done in the crash core.
>
> Update kernel-parameters.txt to document CMA support for crashkernel on
> arm64 architecture.
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Acked-by: Baoquan He <bhe@redhat.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Acked-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Tested-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [PATCH v5 2/9] mmc: sdhci-of-k1: enable essential clock infrastructure for SD operation
From: Troy Mitchell @ 2026-03-30 9:11 UTC (permalink / raw)
To: Iker Pedrosa, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Adrian Hunter, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: Michael Opdenacker, Javier Martinez Canillas, linux-mmc,
devicetree, linux-riscv, spacemit, linux-kernel, Anand Moon,
Trevor Gamblin, Troy Mitchell
In-Reply-To: <20260330-orangepi-sd-card-uhs-v5-2-bd853604322d@gmail.com>
On Mon, Mar 30, 2026 at 16:38:03 CST, Iker Pedrosa wrote:
> Ensure SD card pins receive clock signals by enabling pad clock
> generation and overriding automatic clock gating. Required for all SD
> operation modes.
>
> The SDHC_GEN_PAD_CLK_ON setting in LEGACY_CTRL_REG is safe for both SD
> and eMMC operation as both protocols use the same physical MMC interface
> pins and require proper clock signal generation at the hardware level
> for signal integrity and timing.
>
> Additional SD-specific clock overrides (SDHC_OVRRD_CLK_OEN and
> SDHC_FORCE_CLK_ON) are conditionally applied only for SD-only
> controllers to handle removable card scenarios.
>
> Tested-by: Anand Moon <linux.amoon@gmail.com>
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.dev>
^ permalink raw reply
* Re: [PATCH v5 5/9] riscv: dts: spacemit: k1: add SD card controller and pinctrl support
From: Troy Mitchell @ 2026-03-30 9:08 UTC (permalink / raw)
To: Iker Pedrosa, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Adrian Hunter, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: Michael Opdenacker, Javier Martinez Canillas, linux-mmc,
devicetree, linux-riscv, spacemit, linux-kernel, Anand Moon,
Trevor Gamblin, Troy Mitchell
In-Reply-To: <20260330-orangepi-sd-card-uhs-v5-5-bd853604322d@gmail.com>
On Mon, Mar 30, 2026 at 16:38:06 CST, Iker Pedrosa wrote:
> Add SD card controller infrastructure for SpacemiT K1 SoC with complete
> pinctrl support for both standard and UHS modes.
>
> - Add sdhci0 controller definition with clocks, resets and interrupts
> - Add mmc1_cfg pinctrl for 3.3V standard SD operation
> - Add mmc1_uhs_cfg pinctrl for 1.8V UHS high-speed operation
> - Configure appropriate drive strength and power-source properties
>
> This provides complete SD card infrastructure that K1-based boards can
> enable.
>
> Tested-by: Anand Moon <linux.amoon@gmail.com>
> Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
> ---
> arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi | 40 ++++++++++++++++++++++++++++
> arch/riscv/boot/dts/spacemit/k1.dtsi | 13 +++++++++
> 2 files changed, 53 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
> index b13dcb10f4d66022d27307de73a6ea3287e97441..8d82011f1af666fb78c282a2abcc0cb88f962053 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
> @@ -570,4 +570,44 @@ pwm14-1-pins {
> drive-strength = <32>;
> };
> };
> +
> + mmc1_cfg: mmc1-cfg {
> + mmc1-data-cmd-pins {
> + pinmux = <K1_PADCONF(104, 0)>, /* mmc1_d3 */
> + <K1_PADCONF(105, 0)>, /* mmc1_d2 */
> + <K1_PADCONF(106, 0)>, /* mmc1_d1 */
> + <K1_PADCONF(107, 0)>, /* mmc1_d0 */
> + <K1_PADCONF(108, 0)>; /* mmc1_cmd */
> + bias-pull-up = <1>;
> + drive-strength = <7>;
I'm a bit concerned about this value. Looking at the downstream 6.6 code, 3.3V uses DS4,
which equals 13mA. Since 7mA maps to DS0, what's the reasoning for using it here?
Do we have any documentation or measurement to back this up?
> + power-source = <3300>;
> + };
> +
> + mmc1-clk-pins {
> + pinmux = <K1_PADCONF(109, 0)>; /* mmc1_clk */
> + bias-pull-down = <1>;
> + drive-strength = <7>;
> + power-source = <3300>;
> + };
> + };
> +
> + mmc1_uhs_cfg: mmc1-uhs-cfg {
> + mmc1-data-cmd-pins {
> + pinmux = <K1_PADCONF(104, 0)>, /* mmc1_d3 */
> + <K1_PADCONF(105, 0)>, /* mmc1_d2 */
> + <K1_PADCONF(106, 0)>, /* mmc1_d1 */
> + <K1_PADCONF(107, 0)>, /* mmc1_d0 */
> + <K1_PADCONF(108, 0)>; /* mmc1_cmd */
> + bias-pull-up = <1>;
> + drive-strength = <13>;
See above.
- Troy
^ permalink raw reply
* [PATCH v2 4/7] PCI: intel-gw: Add start_link callback function
From: Florian Eckert @ 2026-03-30 9:07 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260330-pcie-intel-gw-v2-0-8bd07367a298@dev.tdt.de>
The pcie-intel-gw driver has no start_link callback function. This commit
adds the missing callback function so that the driver works again and does
not abort with the following error messages during probing.
[ 2.512015] intel-gw-pcie d1000000.pcie: host bridge /soc/pcie@d1000000 ranges:
[ 2.517868] intel-gw-pcie d1000000.pcie: MEM 0x00dc000000..0x00ddffffff -> 0x00dc000000
[ 2.528450] intel-combo-phy d0c00000.combo-phy: Set combo mode: combophy[1]: mode: PCIe single lane mode
[ 2.551619] intel-gw-pcie d1000000.pcie: No outbound iATU found
[ 2.556060] intel-gw-pcie d1000000.pcie: Cannot initialize host
[ 2.561901] intel-gw-pcie d1000000.pcie: probe with driver intel-gw-pcie failed with error -22
[ 2.571041] intel-gw-pcie c1100000.pcie: host bridge /soc/pcie@c1100000 ranges:
[ 2.577736] intel-gw-pcie c1100000.pcie: MEM 0x00ce000000..0x00cfffffff -> 0x00ce000000
[ 2.588299] intel-combo-phy c0c00000.combo-phy: Set combo mode: combophy[3]: mode: PCIe single lane mode
[ 2.611471] intel-gw-pcie c1100000.pcie: No outbound iATU found
[ 2.615934] intel-gw-pcie c1100000.pcie: Cannot initialize host
[ 2.621759] intel-gw-pcie c1100000.pcie: probe with driver intel-gw-pcie failed with error -22
Fixes: c5097b9869a1 ("Revert "PCI: dwc: Wait for link up only if link is started"")
Fixes: da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started")
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index 6d9499d954674a26a74bff56b7fb5759767424c0..24c463781f1e31d5617a5ff81bdbce563ed5a1d0 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -284,6 +284,16 @@ static void intel_pcie_turn_off(struct intel_pcie *pcie)
pcie_rc_cfg_wr_mask(pcie, PCI_COMMAND, PCI_COMMAND_MEMORY, 0);
}
+static int intel_pcie_start_link(struct dw_pcie *pci)
+{
+ struct intel_pcie *pcie = dev_get_drvdata(pci->dev);
+
+ intel_pcie_device_rst_deassert(pcie);
+ intel_pcie_ltssm_enable(pcie);
+
+ return 0;
+}
+
static int intel_pcie_host_setup(struct intel_pcie *pcie)
{
int ret;
@@ -310,19 +320,8 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
intel_pcie_link_setup(pcie);
intel_pcie_init_n_fts(pci);
- ret = dw_pcie_setup_rc(&pci->pp);
- if (ret)
- goto err;
-
dw_pcie_upconfig_setup(pci);
- intel_pcie_device_rst_deassert(pcie);
- intel_pcie_ltssm_enable(pcie);
-
- ret = dw_pcie_wait_for_link(pci);
- if (ret)
- goto err;
-
intel_pcie_core_irq_enable(pcie);
return 0;
@@ -386,6 +385,7 @@ static int intel_pcie_rc_init(struct dw_pcie_rp *pp)
}
static const struct dw_pcie_ops intel_pcie_ops = {
+ .start_link = intel_pcie_start_link,
};
static const struct dw_pcie_host_ops intel_pcie_dw_ops = {
--
2.47.3
^ permalink raw reply related
* [PATCH v2 6/7] dt-bindings: PCI: intel,lgm-pcie: Make atu resource mandatory
From: Florian Eckert @ 2026-03-30 9:07 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260330-pcie-intel-gw-v2-0-8bd07367a298@dev.tdt.de>
The ATU information is already set in the dwc core if it is specified in
the DTS. The driver uses its own value here [1]. This information is
hardware specific and should therefore be maintained in the DTS rather
than in the source.
Backwards compatibility is not an issue here [5], as the driver is
exclusively used by Maxlinear.
Old DTS entry for PCIe:
reg = <0xd1000000 0x1000>,
<0xd3000000 0x20000>,
<0xd0c41000.0x1000>;
reg-names = "dbi", "config", "app";
New DTS entry for PCIe:
reg = <0xd1000000 0x1000>,
<0xd10c0000 0x1000>,
<0xd3000000 0x20000>,
<0xd0c41000.0x1000>;
reg-names = "dbi", "atu", "config", "app";
[1] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-intel-gw.c#L301
[2] https://lore.kernel.org/all/BY3PR19MB507667CE7531D863E1E5F8AEBDD82@BY3PR19MB5076.namprd19.prod.outlook.com/
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
index 54e2890ae6314ac6847fc23f49440d05d66d87d4..e4b781f57e8ae84a3ffc33635a421e1a5761587e 100644
--- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
@@ -29,12 +29,14 @@ properties:
reg:
items:
- description: Controller control and status registers.
+ - description: Internal Address Translation Unit (iATU) registers.
- description: PCIe configuration registers.
- description: Controller application registers.
reg-names:
items:
- const: dbi
+ - const: atu
- const: config
- const: app
@@ -94,9 +96,10 @@ examples:
#address-cells = <3>;
#size-cells = <2>;
reg = <0xd0e00000 0x1000>,
+ <0xd0ec0000 0x1000>,
<0xd2000000 0x800000>,
<0xd0a41000 0x1000>;
- reg-names = "dbi", "config", "app";
+ reg-names = "dbi", "atu", config", "app";
linux,pci-domain = <0>;
max-link-speed = <4>;
bus-range = <0x00 0x08>;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 5/7] PCI: intel-gw: Remove atu base assignment
From: Florian Eckert @ 2026-03-30 9:07 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260330-pcie-intel-gw-v2-0-8bd07367a298@dev.tdt.de>
If no ATU resource is defined in the DTS, the default value is 0x300000[1].
This is set during probing in the function 'dw_pcie_get_resources()'[2].
The driver overwrites this again when its init callback is called in its
'intel_pcie_host_setup()' [3] function. This is because the value here is
'0xC0000' rather than '0x300000'. This callback is called by the dwc core
via 'pp->ops->init' [4].
function callstack:
intel_pcie_probe()
dw_pcie_host_init()
dw_pcie_host_get_resources()
dw_pcie_get_resources() [2]
pp->ops->init = intel_pcie_rc_init()
intel_pcie_host_setup() [3]
As backwards compatibility is not an issue here [5], the value for the ATU
resource is moved to the DTS and is therefore loaded by the dwc core. It
is therefore no longer necessary to overwrite the pci->atu_base address in
the init callback. The DTS must be modified so that the additional resource
is loaded correctly by the DWC core.
[1] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-designware.h#L292
[2] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-designware.c#L150
[3] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-intel-gw.c#L301
[4] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-designware-host.c#L589
[5] https://lore.kernel.org/all/BY3PR19MB507667CE7531D863E1E5F8AEBDD82@BY3PR19MB5076.namprd19.prod.outlook.com/
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index 24c463781f1e31d5617a5ff81bdbce563ed5a1d0..f41b64ac48d5c05e6b0e5b14c3e0cd7a4c407d16 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -310,8 +310,6 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
goto clk_err;
}
- pci->atu_base = pci->dbi_base + 0xC0000;
-
ret = phy_init(pcie->phy);
if (ret)
goto phy_err;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 3/7] PCI: intel-gw: Enable clock before phy init
From: Florian Eckert @ 2026-03-30 9:07 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260330-pcie-intel-gw-v2-0-8bd07367a298@dev.tdt.de>
To ensure that the boot sequence is correct, the dwc pcie core clock must
be switched on before phy init call [1]. This changes are based on patched
kernel sources of the MaxLinear SDK.
[1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L544
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index e88b8243cc41c607c39e4d58c4dcd8c8c082e8b0..6d9499d954674a26a74bff56b7fb5759767424c0 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -291,13 +291,9 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
intel_pcie_core_rst_assert(pcie);
intel_pcie_device_rst_assert(pcie);
-
- ret = phy_init(pcie->phy);
- if (ret)
- return ret;
-
intel_pcie_core_rst_deassert(pcie);
+ /* Controller clock must be provided earlier than PHY */
ret = clk_prepare_enable(pcie->core_clk);
if (ret) {
dev_err(pcie->pci.dev, "Core clock enable failed: %d\n", ret);
@@ -306,13 +302,17 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
pci->atu_base = pci->dbi_base + 0xC0000;
+ ret = phy_init(pcie->phy);
+ if (ret)
+ goto phy_err;
+
intel_pcie_ltssm_disable(pcie);
intel_pcie_link_setup(pcie);
intel_pcie_init_n_fts(pci);
ret = dw_pcie_setup_rc(&pci->pp);
if (ret)
- goto app_init_err;
+ goto err;
dw_pcie_upconfig_setup(pci);
@@ -321,17 +321,18 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
ret = dw_pcie_wait_for_link(pci);
if (ret)
- goto app_init_err;
+ goto err;
intel_pcie_core_irq_enable(pcie);
return 0;
-app_init_err:
+err:
+ phy_exit(pcie->phy);
+phy_err:
clk_disable_unprepare(pcie->core_clk);
clk_err:
intel_pcie_core_rst_assert(pcie);
- phy_exit(pcie->phy);
return ret;
}
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/7] PCI: intel-gw: Fixes to make the driver working again
From: Florian Eckert @ 2026-03-30 9:07 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
This patch series fixes the 'intel-gw' driver to work again with the
current pcie framework. The following changes are:
* Move interrupt 'enable' to its own function to improve readability,
and add additinal register writes just as the Maxlinear kernel does in
their SDK.
* Enable clock for the PHY before PHY init call.
* Add missing 'start_link' callback that was added to the PCIe dwc
framework.
* Read ATU base assignment from the DTS rather than specifying it in the
source of the driver.
* Remove unused preprocessor define.
* Mark driver as orphaned as the maitainer's email no longer works
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
Changes in v2:
- Added additional information to the commit descriptions
- Add additional patch to mark driver as orphaned as the maintainer's
email no longer works.
- Fix wrong error path for enable clock before phy init.
- Add new patch to update the devicetree documentation for the 'atu'
resource
- Add additional recipients responsible for documenting the dervicetree
bindings.
- Link to v1: https://lore.kernel.org/r/20260317-pcie-intel-gw-v1-0-7fe13726ad4f@dev.tdt.de
---
Florian Eckert (7):
PCI: intel-gw: Remove unused define
PCI: intel-gw: Move interrupt enable to own function
PCI: intel-gw: Enable clock before phy init
PCI: intel-gw: Add start_link callback function
PCI: intel-gw: Remove atu base assignment
dt-bindings: PCI: intel,lgm-pcie: Make atu resource mandatory
MAINTAINERS: Remove bouncing intel-gw maintainer
.../devicetree/bindings/pci/intel-gw-pcie.yaml | 5 ++-
MAINTAINERS | 3 +-
drivers/pci/controller/dwc/pcie-intel-gw.c | 49 ++++++++++++----------
3 files changed, 31 insertions(+), 26 deletions(-)
---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20260317-pcie-intel-gw-50902113f9e1
Best regards,
--
Florian Eckert <fe@dev.tdt.de>
^ permalink raw reply
* [PATCH v2 2/7] PCI: intel-gw: Move interrupt enable to own function
From: Florian Eckert @ 2026-03-30 9:07 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260330-pcie-intel-gw-v2-0-8bd07367a298@dev.tdt.de>
To improve the readability of the code, move the interrupt enable
instructions to a separate function. That is already done for the disable
interrupt instruction.
In addtion, all pending interrupts are cleared and disabled, just as this
is done in the disable function 'intel_pcie_core_irq_disable()'. After
that, all relevant interrupts are enabled again. The 'PCIE_APP_IRNEN'
definition contains all the relevant interrupts that are of interest.
This change is also done in the Maxlinear SDK [1]. As I unfortunately
don’t have any documentation for this IP core, I suspect that the
intention is to set the IP core for interrupt handling to a specific
state. Perhaps the problem was that the IP core did not reinitialize the
interrupt register properly after a power cycle.
In my view, it can’t do any harm to switch the interrupt off and then on
again to set them to a specific state.
[1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L431
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index 80d1607c46cbbb1e274b37a0bb9377a877678f5d..e88b8243cc41c607c39e4d58c4dcd8c8c082e8b0 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -195,6 +195,13 @@ static void intel_pcie_device_rst_deassert(struct intel_pcie *pcie)
gpiod_set_value_cansleep(pcie->reset_gpio, 0);
}
+static void intel_pcie_core_irq_enable(struct intel_pcie *pcie)
+{
+ pcie_app_wr(pcie, PCIE_APP_IRNEN, 0);
+ pcie_app_wr(pcie, PCIE_APP_IRNCR, PCIE_APP_IRN_INT);
+ pcie_app_wr(pcie, PCIE_APP_IRNEN, PCIE_APP_IRN_INT);
+}
+
static void intel_pcie_core_irq_disable(struct intel_pcie *pcie)
{
pcie_app_wr(pcie, PCIE_APP_IRNEN, 0);
@@ -316,9 +323,7 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
if (ret)
goto app_init_err;
- /* Enable integrated interrupts */
- pcie_app_wr_mask(pcie, PCIE_APP_IRNEN, PCIE_APP_IRN_INT,
- PCIE_APP_IRN_INT);
+ intel_pcie_core_irq_enable(pcie);
return 0;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/7] PCI: intel-gw: Remove unused define
From: Florian Eckert @ 2026-03-30 9:07 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260330-pcie-intel-gw-v2-0-8bd07367a298@dev.tdt.de>
The C preprocessor define 'PCIE_APP_INTX_OFST' is not used in the sources
and can therefore be deleted.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index c21906eced61896c8a8307dbd6b72d229f9a5c5f..80d1607c46cbbb1e274b37a0bb9377a877678f5d 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -47,7 +47,6 @@
#define PCIE_APP_IRN_INTD BIT(16)
#define PCIE_APP_IRN_MSG_LTR BIT(18)
#define PCIE_APP_IRN_SYS_ERR_RC BIT(29)
-#define PCIE_APP_INTX_OFST 12
#define PCIE_APP_IRN_INT \
(PCIE_APP_IRN_AER_REPORT | PCIE_APP_IRN_PME | \
--
2.47.3
^ permalink raw reply related
* [PATCH v2 7/7] MAINTAINERS: Remove bouncing intel-gw maintainer
From: Florian Eckert @ 2026-03-30 9:07 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260330-pcie-intel-gw-v2-0-8bd07367a298@dev.tdt.de>
The maintainer's email address has been bouncing for months. Mark the PCI
intel-gw driver as orphaned.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 96ea84948d76aff5e07579911d0f370ae13f481b..26f3b2e192fa9ef2e1c89d2310bebaa0a67dff00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20505,9 +20505,8 @@ F: Documentation/devicetree/bindings/pci/intel,keembay-pcie*
F: drivers/pci/controller/dwc/pcie-keembay.c
PCIE DRIVER FOR INTEL LGM GW SOC
-M: Chuanhua Lei <lchuanhua@maxlinear.com>
L: linux-pci@vger.kernel.org
-S: Maintained
+S: Orphan
F: Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
F: drivers/pci/controller/dwc/pcie-intel-gw.c
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: msm8939-asus-z00t: add regulators for ambient light and proximity sensor
From: Konrad Dybcio @ 2026-03-30 9:05 UTC (permalink / raw)
To: Erikas Bitovtas, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260330-z00t-cm36686-regulators-v1-1-03e23b03bd70@gmail.com>
On 3/30/26 1:37 AM, Erikas Bitovtas wrote:
> VCNL4000 includes support for regulators. Add regulators listed in the
> downstream device tree so they can be powered in during initialization.
> VLED supply is missing downstream, so it will be powered on by a dummy.
>
> Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
> ---
> arm64: dts: qcom: msm8939-asus-z00t: add regulators for ambient light
> and proximity sensor.
>
> This patch series describes regulators needed for the ambient light and
> proximity sensor.
>
> In the patch series which added the ambient light and proximity sensor
> for this device, regulators were missing, as they were not yet supported
> by the sensor's device tree binding. Missing regulators for the ambient
> light and proximity sensor resulted in it not powering on when a
> regulator supplied only the ambient light and proximity sensor. In Asus
> ZenFone 2 Laser case, the regulators were shared with the panel and
> magnetometer, so it was not affected by this bug. However, for the sake
> of completeness of the binding, we add the neccessary regulators anyway.
>
> The mainline binding for the sensor also includes vled-supply, however,
> in downstream, it is missing, and we have no datasheet for the device,
> so for now, we'll have it being supplied by a dummy.
> ---
In case this isn't AI-generated, you don't need a novel-length cover
letter for such a simple patch
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Akhil R @ 2026-03-30 9:03 UTC (permalink / raw)
To: frank.li
Cc: Frank.Li, akhilrajeev, conor+dt, devicetree, dmaengine, jonathanh,
krzk+dt, ldewangan, linux-kernel, linux-tegra, p.zabel, robh,
thierry.reding, vkoul
In-Reply-To: <acWWW6r5gZ2nGerQ@lizhi-Precision-Tower-5810>
On Thu, 26 Mar 2026 16:26:03 -0400, Frank Li wrote:
> On Thu, Mar 26, 2026 at 04:39:45PM +0530, Akhil R wrote:
>> Use 'iommu-map', when provided, to get the stream ID to be programmed
>> for each channel. Iterate over the channels registered and configure
>> each channel device separately using of_dma_configure_id() to allow
>> it to use a separate IOMMU domain for the transfer. But do this
>> in a second loop since the first loop populates the DMA device channels
>> list and async_device_register() registers the channels. Both are
>> prerequisites for using the channel device in the next loop.
>>
>> Channels will continue to use the same global stream ID if the
>> 'iommu-map' property is not present in the device tree.
>>
>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> ---
> ...
>> @@ -1490,6 +1496,41 @@ static int tegra_dma_probe(struct platform_device *pdev)
>> return ret;
>> }
>>
>> + /*
>> + * Configure stream ID for each channel from the channels registered
>> + * above. This is done in a separate iteration to ensure that only
>> + * the channels available and registered for the DMA device are used.
>> + */
>> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
>> + chdev = &chan->dev->device;
>> + tdc = to_tegra_dma_chan(chan);
>> +
>> + if (use_iommu_map) {
>> + chdev->bus = pdev->dev.bus;
>> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
>> +
>> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
>> + true, &tdc->id);
>> + if (ret) {
>> + dev_err(chdev, "Failed to configure IOMMU for channel %d: %d\n",
>> + tdc->id, ret);
>> + return ret;
>
> This is in probe funciton
>
> return dev_err_probe();
Ack. I will update.
Best Regards,
Akhil
^ permalink raw reply
* [PATCH net-next v1] net: macb: fix use of at91_default_usrio without CONFIG_OF
From: Conor Dooley @ 2026-03-30 9:02 UTC (permalink / raw)
To: netdev
Cc: conor, Conor Dooley, kernel test robot, Jiawen Wu, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Nicolas Ferre, Claudiu Beznea, devicetree, linux-kernel,
linux-riscv
From: Conor Dooley <conor.dooley@microchip.com>
If CONFIG_OF is not enabled, at91_default_usrio is used undeclared in
gem_default_config. Rather than move the struct around, take the
opportunity to rename gem_default_config, as the only compatible it is
ever used for is "cdns,macb" - not "cdns,gem" at all! With that done,
remove the use of default_gem_config as a fallback in probe, as every
device has a specific set of match data.
It pains me a little to leave at91_default_usrio in match data used by
"cdns,macb", but this is probably required to avoid regressing anyone.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603280028.wQjUrIvv-lkp@intel.com/
Reported-by: Jiawen Wu <jiawenwu@trustnetic.com>
Closes: https://lore.kernel.org/all/06a701dcc014$86def5b0$949ce110$@trustnetic.com/
Fixes: a17871778ee28 ("net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
lkp also reported this over the weekend, but against the dev copy in my
tree. I had thought that CONFIG_OF was standard off on x86, but I guess
it isn't, given lkp didn't catch it until randconfigs.
CC: Andrew Lunn <andrew+netdev@lunn.ch>
CC: David S. Miller <davem@davemloft.net>
CC: Eric Dumazet <edumazet@google.com>
CC: Jakub Kicinski <kuba@kernel.org>
CC: Paolo Abeni <pabeni@redhat.com>
CC: Nicolas Ferre <nicolas.ferre@microchip.com>
CC: Claudiu Beznea <claudiu.beznea@tuxon.dev>
CC: netdev@vger.kernel.org
CC: devicetree@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: linux-riscv@lists.infradead.org
---
drivers/net/ethernet/cadence/macb_main.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 12e2b2f4aaf88..4f70e4fcf4606 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -5716,9 +5716,18 @@ static const struct macb_config pic64hpsc_config = {
.jumbo_max_len = 16383,
};
+static const struct macb_config macb_macb_config = {
+ .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE |
+ MACB_CAPS_JUMBO |
+ MACB_CAPS_GEM_HAS_PTP,
+ .dma_burst_length = 16,
+ .usrio = &at91_default_usrio,
+ .jumbo_max_len = 10240,
+};
+
static const struct of_device_id macb_dt_ids[] = {
{ .compatible = "cdns,at91sam9260-macb", .data = &at91sam9260_config },
- { .compatible = "cdns,macb" },
+ { .compatible = "cdns,macb", .data = &macb_macb_config},
{ .compatible = "cdns,np4-macb", .data = &np4_config },
{ .compatible = "cdns,pc302-gem", .data = &pc302gem_config },
{ .compatible = "cdns,gem", .data = &pc302gem_config },
@@ -5747,15 +5756,6 @@ static const struct of_device_id macb_dt_ids[] = {
MODULE_DEVICE_TABLE(of, macb_dt_ids);
#endif /* CONFIG_OF */
-static const struct macb_config default_gem_config = {
- .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE |
- MACB_CAPS_JUMBO |
- MACB_CAPS_GEM_HAS_PTP,
- .dma_burst_length = 16,
- .usrio = &at91_default_usrio,
- .jumbo_max_len = 10240,
-};
-
static int macb_probe(struct platform_device *pdev)
{
struct clk *pclk, *hclk = NULL, *tx_clk = NULL, *rx_clk = NULL;
@@ -5778,7 +5778,7 @@ static int macb_probe(struct platform_device *pdev)
macb_config = of_device_get_match_data(&pdev->dev);
if (!macb_config)
- macb_config = &default_gem_config;
+ return -EINVAL;
err = macb_clk_init(pdev, &pclk, &hclk, &tx_clk, &rx_clk, &tsu_clk,
macb_config);
--
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