* Re: [PATCH 4/5] clk: qcom: Add camera clock controller driver for SM8150
From: Satya Priya Kakitapalli (Temp) @ 2024-04-05 6:27 UTC (permalink / raw)
To: Bryan O'Donoghue, Bjorn Andersson, Konrad Dybcio,
Michael Turquette, Stephen Boyd, Abhishek Sahu, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Stephen Boyd, linux-arm-msm, linux-clk, linux-kernel, devicetree,
Ajit Pandey, Imran Shaik, Taniya Das, Jagadeesh Kona
In-Reply-To: <18567989-fb60-49ae-92e6-94e1bc2fa1c7@linaro.org>
On 3/2/2024 9:43 PM, Bryan O'Donoghue wrote:
> On 29/02/2024 5:38 a.m., Satya Priya Kakitapalli wrote:
>> Add support for the camera clock controller for camera clients
>> to be able to request for camcc clocks on SM8150 platform.
>>
>> Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
>> ---
>
>> +static int cam_cc_sm8150_probe(struct platform_device *pdev)
>> +{
>> + struct regmap *regmap;
>> + int ret;
>> +
>> + ret = devm_pm_runtime_enable(&pdev->dev);
>> + if (ret)
>> + return ret;
>> +
>> + ret = pm_runtime_resume_and_get(&pdev->dev);
>> + if (ret)
>> + return ret;
>> +
>> + regmap = qcom_cc_map(pdev, &cam_cc_sm8150_desc);
>> + if (IS_ERR(regmap)) {
>> + pm_runtime_put(&pdev->dev);
>> + return PTR_ERR(regmap);
>> + }
>> +
>> + clk_trion_pll_configure(&cam_cc_pll0, regmap, &cam_cc_pll0_config);
>> + clk_trion_pll_configure(&cam_cc_pll1, regmap, &cam_cc_pll1_config);
>> + clk_regera_pll_configure(&cam_cc_pll2, regmap,
>> &cam_cc_pll2_config);
>> + clk_trion_pll_configure(&cam_cc_pll3, regmap, &cam_cc_pll3_config);
>> + clk_trion_pll_configure(&cam_cc_pll4, regmap, &cam_cc_pll4_config);
>> +
>> + /* Keep the critical clock always-on */
>> + qcom_branch_set_clk_en(regmap, 0xc1e4); /* cam_cc_gdsc_clk */
>
> Does this clock need to be specified this way ?
>
> drivers/clk/qcom/camcc-sc8280xp.c::camcc_gdsc_clk specifies the gdsc
> clock as a shared op clock.
>
> Actually it looks to be register compatible, please try defining
> titan_top_gdsc as per the example in 8280xp.
>
>> +
>> + ret = qcom_cc_really_probe(pdev, &cam_cc_sm8150_desc, regmap);
>> +
>> + pm_runtime_put(&pdev->dev);
>> +
>> + return ret;
>> +}
>
> So this is a pattern we keep repeating in the clock probe() functions
> which I am writing a series to address. There's no need to continue to
> replicate the bug in new code though.
>
> Only switch on always-on clocks if probe succeeds.
>
> ret = qcom_cc_really_probe(pdev, &cam_cc_sm8150_desc, regmap);
> if (ret)
> goto probe_err;
>
> qcom_branch_set_clk_en(regmap, 0xc1e4); /* cam_cc_gdsc_clk */
>
> pm_runtime_put(&pdev->dev);
>
> return 0;
>
> probe_err:
> pm_runtime_put_sync(&pdev->dev);
>
> Alternatively switch on the always-on clocks before the really_probe()
> but then roll back in a probe_err: goto
>
> probe_err:
> remap_bits_update(regmap, 0xc1e4, BIT(0), 0);
> pm_runtime_put_sync(&pdev->dev);
>
> There may be corner cases where always-on has to happen before
> really_probe() I suppose but as a general pattern the above should be
> how we go.
>
I have rechecked this and see that this clock is PoR ON (i.e BIT(0) is
set upon power ON) and it should be kept always ON as per HW
recommendation. So even if the probe fails we shouldn't be clearing it
against the hw recommendation. We are setting the bit here again to make
sure it is set when the driver probes.
> Anyway I suspect the right thing to do is to define a
> titan_top_gdsc_clk with shared ops to "park" the GDSC clock to 19.2
> MHz instead of turning it off.
>
> You can get rid of the hard-coded always-on and indeed represent the
> clock in /sysfs - which is preferable IMO to just whacking registers
> to keep clocks always-on in probe anyway.
>
> Please try to define the titan_top_gdsc_clk as a shared_ops clock
> instead of hard coding to always on.
>
> If that doesn't work for some reason, then please fix your always-on
> logic in probe() to only make the clock fixed on, if really_probe()
> succeeds.
>
> ---
> bod
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mfd: Add ROHM BD71879
From: Andreas Kemnade @ 2024-04-05 6:31 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Krzysztof Kozlowski, lee, robh+dt, krzysztof.kozlowski+dt,
conor+dt, devicetree, linux-kernel
In-Reply-To: <0295c8db-b01e-45e7-b44e-79d36d81cd48@gmail.com>
On Fri, 5 Apr 2024 09:01:25 +0300
Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> > Yes. If there are reasons against, please briefly mention them in commit
> > msg.
>
> I would like to understand the rationale for allowing:
> compatible = "rohm,bd71879", "rohm,bd71828".
>
> Is the intention to:
> 1) allow boards which tell the software that "the hardware may be
> bd71828 or bd71879", or
> 2) to tell a binding reader that these ICs are likely to be usable as
> replacements to each others?
> (Or, is there some other rationale beyond these?)
As far as I understand the second compatible can be a fallback for
software which does not know the bd71879 (remember the devicetree is
not only for linux). Especially if that software does not use the full
functionality of the device, like drivers in bootloaders do. E.g.
mmc drivers in bootloaders might not use high speed modes at all, so
differences in them do not matter.
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mfd: Add ROHM BD71879
From: Krzysztof Kozlowski @ 2024-04-05 6:35 UTC (permalink / raw)
To: Matti Vaittinen, Andreas Kemnade
Cc: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, devicetree,
linux-kernel
In-Reply-To: <0295c8db-b01e-45e7-b44e-79d36d81cd48@gmail.com>
On 05/04/2024 08:01, Matti Vaittinen wrote:
> On 4/4/24 15:04, Krzysztof Kozlowski wrote:
>> On 04/04/2024 12:30, Andreas Kemnade wrote:
>>> On Thu, 4 Apr 2024 08:59:54 +0200
>>> Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>>>
>>>> On 02/04/2024 21:35, Andreas Kemnade wrote:
>>>>> As this chip was seen in several devices in the wild, add it.
>>>>>
>>>>> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
>>>>> Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>>>> ---
>>>>> Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 4 +++-
>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
>>>>> index 0b62f854bf6b..e4df09e8961c 100644
>>>>> --- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
>>>>> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
>>>>> @@ -17,7 +17,9 @@ description: |
>>>>>
>>>>> properties:
>>>>> compatible:
>>>>> - const: rohm,bd71828
>>>>> + enum:
>>>>> + - rohm,bd71828
>>>>> + - rohm,bd71879
>>>>
>>>> In your second commit you claim they are compatible, so why they are not
>>>> marked as such?
>>>>
>>> so you mean allowing
>>>
>>> compatible = "rohm,bd71828"
>>> and
>>> compatible = "rohm,bd71879", "rohm,bd71828"
>
>
> This makes me slightly nervous. It wouldn't be the first time when I've
> been told "they are similar", and later the reality has turned out to be
> "they are similar, except...". Furthermore, even if these devices seem
> similar to software (which is what the comment in the MFD driver is
> referring to), it does not mean these devices are 100% electrically
> compatible so that they could be used as a "drop-in" replacement to each
> others. I wouldn't guarantee that.
compatibility does not mean that. It is only about software interface.
>
> Furthermore, my current understanding is that the BD71828 was a model
> that was used for a limited purposes. So, maybe creating an dt-entry like:
> compatible = "rohm,bd71879", "rohm,bd71828"
>
> might not prove to be too useful. (But I'm not 100% certain on this).
>
>> Yes. If there are reasons against, please briefly mention them in commit
>> msg.
>
> I would like to understand the rationale for allowing:
> compatible = "rohm,bd71879", "rohm,bd71828".
>
> Is the intention to:
> 1) allow boards which tell the software that "the hardware may be
> bd71828 or bd71879", or
> 2) to tell a binding reader that these ICs are likely to be usable as
> replacements to each others?
> (Or, is there some other rationale beyond these?)
None of these. Compatibility means that software can use fallback
compatible as matching mechanism and everything will work fine or with
reduced set of features, but still working.
>
> If it's 1), then I see limited sense in doing so, while I expect that
> not so many bd71828 variants will be seen out there - and at least not
> in that many different products. If it's the 2), then I wouldn't say we
> have the facts to do this.
> And, as always, if there is 3), 4), ... - I am keen to learn :)
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] mfd: rohm-bd71828: Add software-compatible variant BD71879
From: Lee Jones @ 2024-04-05 6:35 UTC (permalink / raw)
To: Andreas Kemnade
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, mazziesaccount,
devicetree, linux-kernel
In-Reply-To: <20240402193515.513713-3-andreas@kemnade.info>
On Tue, 02 Apr 2024, Andreas Kemnade wrote:
> Add the BD71879 PMIC which is software-compatible to the BD71828, so reuse
> the same device_type enum.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
> ---
> drivers/mfd/rohm-bd71828.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
> index 4a1fa8a0d76a..f0b444690d4d 100644
> --- a/drivers/mfd/rohm-bd71828.c
> +++ b/drivers/mfd/rohm-bd71828.c
> @@ -585,6 +585,10 @@ static const struct of_device_id bd71828_of_match[] = {
> {
> .compatible = "rohm,bd71828",
> .data = (void *)ROHM_CHIP_TYPE_BD71828,
> + }, {
> + .compatible = "rohm,bd71879",
> + /* equivalent from a software point of view */
Nit: Sentences start with capital letters.
> + .data = (void *)ROHM_CHIP_TYPE_BD71828,
> }, {
> .compatible = "rohm,bd71815",
> .data = (void *)ROHM_CHIP_TYPE_BD71815,
> --
> 2.39.2
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: imx8qxp-mek: add cm40_i2c, wm8960/wm8962 and sai[0,1,4,5]
From: Francesco Dolcini @ 2024-04-05 6:36 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20240404161914.1655305-1-Frank.Li@nxp.com>
Hello Frank,
On Thu, Apr 04, 2024 at 12:19:13PM -0400, Frank Li wrote:
> imx8qxp-mek use two kind audio codec, wm8960 and wm8962. Using dummy gpio
> i2c bus mux to connect both i2c devices. One will probe failure and other
> will probe success when devices driver check whoami. So one dtb can cover
> both board configuration.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 210 ++++++++++++++++++
> 1 file changed, 210 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> index 8360bb851ac03..adff87c7cf305 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> @@ -44,6 +51,105 @@ usb3_data_ss: endpoint {
[...]
> + /*
> + * This dummy i2c mux. GPIO actually will not impact selection. At actual boards, only 1
> + * device connectted. I2C client driver will check ID when probe. Only matched ID's driver
> + * probe successfully.
> + */
> + i2cvmux: i2cmux {
> + compatible = "i2c-mux-gpio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + mux-gpios = <&lsio_gpio5 0 GPIO_ACTIVE_HIGH>; /* use an unused gpio */
There is for sure people that have more experience and competency that
me and it would be interesting to hear their feedback, but this
looks like a bad hack, and you are just playing with the driver
behavior to ensure that you get what you need.
Francesco
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: imx8qxp-mek: add cm40_i2c, wm8960/wm8962 and sai[0,1,4,5]
From: Krzysztof Kozlowski @ 2024-04-05 6:41 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20240404161914.1655305-1-Frank.Li@nxp.com>
On 04/04/2024 18:19, Frank Li wrote:
> imx8qxp-mek use two kind audio codec, wm8960 and wm8962. Using dummy gpio
> i2c bus mux to connect both i2c devices. One will probe failure and other
> will probe success when devices driver check whoami. So one dtb can cover
> both board configuration.
I don't understand it. Either you add real device or not. If one board
has two devices, then why do you need to check for failures?
Anyway, don't add fake stuff to DTS.
NAK.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 210 ++++++++++++++++++
> 1 file changed, 210 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> index 8360bb851ac03..adff87c7cf305 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> @@ -30,6 +30,13 @@ reg_usdhc2_vmmc: usdhc2-vmmc {
> enable-active-high;
> };
>
> + reg_audio: regulator-wm8962 {
> + compatible = "regulator-fixed";
> + regulator-name = "3v3_aud";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> gpio-sbu-mux {
> compatible = "nxp,cbdtu02043", "gpio-sbu-mux";
> pinctrl-names = "default";
> @@ -44,6 +51,105 @@ usb3_data_ss: endpoint {
> };
> };
> };
> +
> + sound-wm8960 {
> + compatible = "fsl,imx-audio-wm8960";
> + model = "wm8960-audio";
> + audio-cpu = <&sai1>;
> + audio-codec = <&wm8960>;
> + hp-det-gpio = <&lsio_gpio1 0 GPIO_ACTIVE_HIGH>;
> + audio-routing =
> + "Headphone Jack", "HP_L",
> + "Headphone Jack", "HP_R",
> + "Ext Spk", "SPK_LP",
> + "Ext Spk", "SPK_LN",
> + "Ext Spk", "SPK_RP",
> + "Ext Spk", "SPK_RN",
> + "LINPUT1", "Mic Jack",
> + "Mic Jack", "MICB";
> + };
> +
> + sound-wm8962 {
> + compatible = "fsl,imx-audio-wm8962";
> + model = "wm8962-audio";
> + audio-cpu = <&sai1>;
> + audio-codec = <&wm8962>;
> + hp-det-gpio = <&lsio_gpio1 0 GPIO_ACTIVE_HIGH>;
> + audio-routing =
> + "Headphone Jack", "HPOUTL",
> + "Headphone Jack", "HPOUTR",
> + "Ext Spk", "SPKOUTL",
> + "Ext Spk", "SPKOUTR",
> + "AMIC", "MICBIAS",
> + "IN3R", "AMIC",
> + "IN1R", "AMIC";
> + };
> +
> + /*
> + * This dummy i2c mux. GPIO actually will not impact selection. At actual boards, only 1
> + * device connectted. I2C client driver will check ID when probe. Only matched ID's driver
> + * probe successfully.
NAK
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 1/5] ARM: dts: aspeed: greatlakes: correct Mellanox multi-host property
From: Krzysztof Kozlowski @ 2024-04-05 6:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
Cc: Krzysztof Kozlowski
"mlx,multi-host" is using incorrect vendor prefix and is not documented.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes in v2:
1. None
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts
index 7a53f54833a0..9a6757dd203f 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts
@@ -66,7 +66,7 @@ &mac3 {
pinctrl-0 = <&pinctrl_rmii4_default>;
no-hw-checksum;
use-ncsi;
- mlx,multi-host;
+ mellanox,multi-host;
ncsi-ctrl,start-redo-probe;
ncsi-ctrl,no-channel-monitor;
ncsi-package = <1>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/5] ARM: dts: aspeed: yosemite4: correct Mellanox multi-host property
From: Krzysztof Kozlowski @ 2024-04-05 6:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240405064624.18997-1-krzysztof.kozlowski@linaro.org>
"mlx,multi-host" is using incorrect vendor prefix and is not documented.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes in v2:
1. None
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 64075cc41d92..1bd555a6c3ba 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -88,7 +88,7 @@ &mac2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_rmii3_default>;
use-ncsi;
- mlx,multi-host;
+ mellanox,multi-host;
};
&mac3 {
@@ -96,7 +96,7 @@ &mac3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_rmii4_default>;
use-ncsi;
- mlx,multi-host;
+ mellanox,multi-host;
};
&fmc {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/5] ARM: dts: aspeed: yosemitev2: correct Mellanox multi-host property
From: Krzysztof Kozlowski @ 2024-04-05 6:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240405064624.18997-1-krzysztof.kozlowski@linaro.org>
"mlx,multi-host" is using incorrect vendor prefix and is not documented.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes in v2:
1. None
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemitev2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemitev2.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemitev2.dts
index 6bf2ff85a40e..5143f85fbd70 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemitev2.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemitev2.dts
@@ -95,7 +95,7 @@ &mac0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_rmii1_default>;
use-ncsi;
- mlx,multi-host;
+ mellanox,multi-host;
};
&adc {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: aspeed: harma: correct Mellanox multi-host property
From: Krzysztof Kozlowski @ 2024-04-05 6:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240405064624.18997-1-krzysztof.kozlowski@linaro.org>
"mlx,multi-host" is using incorrect vendor prefix and is not documented.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes in v2:
1. New patch
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
index bbbab8023cd6..b2834399f3d1 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dts
@@ -137,7 +137,7 @@ &mac3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_rmii4_default>;
use-ncsi;
- mlx,multi-host;
+ mellanox,multi-host;
};
&rtc {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/5] ARM: dts: aspeed: drop unused ref_voltage ADC property
From: Krzysztof Kozlowski @ 2024-04-05 6:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240405064624.18997-1-krzysztof.kozlowski@linaro.org>
Aspeed ADC "ref_voltage" property is neither documented nor used.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Changes in v2:
1. None
---
arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtmitchell.dts | 1 -
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts | 2 --
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 2 --
3 files changed, 5 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtmitchell.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtmitchell.dts
index 7b540880cef9..3c8925034a8c 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtmitchell.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtmitchell.dts
@@ -813,7 +813,6 @@ bmc_ast2600_cpu: temperature-sensor@35 {
};
&adc0 {
- ref_voltage = <2500>;
status = "okay";
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts
index 9a6757dd203f..998598c15fd0 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts
@@ -211,7 +211,6 @@ &i2c13 {
};
&adc0 {
- ref_voltage = <2500>;
status = "okay";
pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
&pinctrl_adc2_default &pinctrl_adc3_default
@@ -220,7 +219,6 @@ &pinctrl_adc4_default &pinctrl_adc5_default
};
&adc1 {
- ref_voltage = <2500>;
status = "okay";
pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc10_default
&pinctrl_adc11_default &pinctrl_adc12_default
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 1bd555a6c3ba..b4d003cbae8b 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -596,7 +596,6 @@ i2c-mux@72 {
};
&adc0 {
- ref_voltage = <2500>;
status = "okay";
pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
&pinctrl_adc2_default &pinctrl_adc3_default
@@ -605,7 +604,6 @@ &pinctrl_adc4_default &pinctrl_adc5_default
};
&adc1 {
- ref_voltage = <2500>;
status = "okay";
pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc9_default>;
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/4] ARM: dts: aspeed: greatlakes: correct Mellanox multi-host property
From: Krzysztof Kozlowski @ 2024-04-05 6:48 UTC (permalink / raw)
To: Andrew Jeffery, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <65060691d4649c4a8da46e5ba762a3c905ade690.camel@codeconstruct.com.au>
On 05/04/2024 01:21, Andrew Jeffery wrote:
>>>
>>> Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au>
>>>
>>> I'm working to stay on top of things a bit more now than I have in the
>>> recent past, so hopefully I won't miss patches again in the future.
>>
>> Stephen reported conflict, although trivial, but maybe better if you
>> take them?
>>
>
> Yeah, happy to.
>
>> I can rebase and resend.
I dropped these patches (and one more) from my tree, rebased and resent
everything as v2.
Thanks!
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 0/2] Add Qualcomm PCIe ECAM root complex driver
From: Krzysztof Kozlowski @ 2024-04-05 6:50 UTC (permalink / raw)
To: Mayank Rana, linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt
In-Reply-To: <1d2d231a-ab2e-4552-9e72-2655d778f3b8@quicinc.com>
On 05/04/2024 01:02, Mayank Rana wrote:
> Hi Krzysztof
>
> On 4/4/2024 12:33 PM, Krzysztof Kozlowski wrote:
>> On 04/04/2024 21:11, Mayank Rana wrote:
>>> On some of Qualcomm platform, firmware takes care of system resources
>>> related to PCIe PHY and controller as well bringing up PCIe link and
>>> having static iATU configuration for PCIe controller to work into
>>> ECAM compliant mode. Hence add Qualcomm PCIe ECAM root complex driver.
>>>
>>> Tested:
>>> - Validated NVME functionality with PCIe0 and PCIe1 on SA877p-ride platform
>>>
>>
>> RFC means code is not ready, right? Please get internal review done and
>> send it when it is ready. I am not sure if you expect any reviews. Some
>> people send RFC and do not expect reviews. Some expect. I have no clue
>> and I do not want to waste my time. Please clarify what you expect from
>> maintainers regarding this contribution.
>>
>> Best regards,
>> Krzysztof
>>
> Thanks for initial comments.
> yes, this is work in progress. There are still more functionalities
> planned to be added as part of this driver. Although purpose of sending
> initial change here to get feedback and review comments in terms of
> usage of generic Qualcomm PCIe ECAM driver, and usage of MSI
> functionality with it. I missed mentioning this as part of cover letter.
> So please help to review and provide feedback.
Thanks for explanation. Work in progress as not ready to be merged? Then
I am sorry, I am not going to provide review of unfinished work. I have
many more *finished* patches to review first. You can help with these
too....
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Krzysztof Kozlowski @ 2024-04-05 6:55 UTC (permalink / raw)
To: Siddharth Vadapalli, Krzysztof Kozlowski
Cc: lee, robh, krzk+dt, conor+dt, devicetree, linux-kernel,
linux-arm-kernel, srk
In-Reply-To: <94bae793-ba4f-467f-917d-213fa3cd6faa@ti.com>
On 05/04/2024 07:21, Siddharth Vadapalli wrote:
>>>> bindings in the changelog or cover letter.
>>>
>>> Thank you for clarifying. I will post the DTS patches corresponding to
>>> this patch and reference this patch in the DTS patch series.
>>
>> I have posted the DTS patch at:
>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240404081845.622707-1-s-vadapalli@ti.com/
>> indicating the dependency on this bindings patch.
>
> Hello Krzysztof,
>
> Do I have to post a v2 for this patch? You had Acked it initially but I
No, I acked it. All this unnecessary talk was because you did not post a
user, but it is not a requirement, at least when we expect such user.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 10/23] drivers: crypto: meson: avoid kzalloc in engine thread
From: Herbert Xu @ 2024-04-05 6:55 UTC (permalink / raw)
To: Alexey Romanov
Cc: neil.armstrong, clabbe, davem, robh+dt, krzysztof.kozlowski+dt,
conor+dt, khilman, jbrunet, martin.blumenstingl, vadim.fedorenko,
linux-crypto, linux-amlogic, linux-kernel, devicetree,
linux-arm-kernel, kernel
In-Reply-To: <20240326153219.2915080-11-avromanov@salutedevices.com>
On Tue, Mar 26, 2024 at 06:32:06PM +0300, Alexey Romanov wrote:
>
> /*
> * struct meson_cipher_tfm_ctx - context for a skcipher TFM
> - * @key: pointer to key data
> + * @keyiv: key data
> * @keylen: len of the key
> * @keymode: The keymode(type and size of key) associated with this TFM
> * @mc: pointer to the private data of driver handling this TFM
> * @fallback_tfm: pointer to the fallback TFM
> */
> struct meson_cipher_tfm_ctx {
> - u32 *key;
> - u32 keylen;
> + u8 keyiv[AES_MAX_KEY_SIZE + AES_BLOCK_SIZE] ____cacheline_aligned;
> + u32 keylen ____cacheline_aligned;
This doesn't do anything to guarantee that tfm_ctx is aligned.
You either need to align this by hand, or you could use the
crypto_skcipher_ctx_dma helper if DMA alignment is what you're
actually looking for.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v6 11/23] drivers: crypto: meson: introduce hasher
From: Herbert Xu @ 2024-04-05 6:56 UTC (permalink / raw)
To: Alexey Romanov
Cc: neil.armstrong, clabbe, davem, robh+dt, krzysztof.kozlowski+dt,
conor+dt, khilman, jbrunet, martin.blumenstingl, vadim.fedorenko,
linux-crypto, linux-amlogic, linux-kernel, devicetree,
linux-arm-kernel, kernel
In-Reply-To: <20240326153219.2915080-12-avromanov@salutedevices.com>
On Tue, Mar 26, 2024 at 06:32:07PM +0300, Alexey Romanov wrote:
> Introduce support for SHA1/SHA224/SHA256 hash algos.
> Tested via tcrypt and custom tests.
>
> Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
> ---
> drivers/crypto/amlogic/Makefile | 2 +-
> drivers/crypto/amlogic/amlogic-gxl-core.c | 25 +-
> drivers/crypto/amlogic/amlogic-gxl-hasher.c | 460 ++++++++++++++++++++
> drivers/crypto/amlogic/amlogic-gxl.h | 51 +++
> 4 files changed, 536 insertions(+), 2 deletions(-)
> create mode 100644 drivers/crypto/amlogic/amlogic-gxl-hasher.c
Where are the import/export functions?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mfd: Add ROHM BD71879
From: Krzysztof Kozlowski @ 2024-04-05 6:56 UTC (permalink / raw)
To: Andreas Kemnade, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
mazziesaccount, devicetree, linux-kernel
In-Reply-To: <20240404195423.666446-2-andreas@kemnade.info>
On 04/04/2024 21:54, Andreas Kemnade wrote:
> As this chip was seen in several devices in the wild, add it.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
> ---
> .../devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mfd: Add ROHM BD71879
From: Matti Vaittinen @ 2024-04-05 6:58 UTC (permalink / raw)
To: Krzysztof Kozlowski, Andreas Kemnade
Cc: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, devicetree,
linux-kernel
In-Reply-To: <35a9399e-819a-400c-b321-099f8bc9df90@linaro.org>
On 4/5/24 09:35, Krzysztof Kozlowski wrote:
> On 05/04/2024 08:01, Matti Vaittinen wrote:
>> On 4/4/24 15:04, Krzysztof Kozlowski wrote:
>>> On 04/04/2024 12:30, Andreas Kemnade wrote:
>>>> On Thu, 4 Apr 2024 08:59:54 +0200
>>>> Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>>> On 02/04/2024 21:35, Andreas Kemnade wrote:
>>>>>> As this chip was seen in several devices in the wild, add it.
>>>>>>
>>>>>> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
>>>>>> Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 4 +++-
>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
>>>>>> index 0b62f854bf6b..e4df09e8961c 100644
>>>>>> --- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
>>>>>> @@ -17,7 +17,9 @@ description: |
>>>>>>
...
Compatibility means that software can use fallback
> compatible as matching mechanism and everything will work fine or with
> reduced set of features, but still working.
Thanks to both of you Andreas and Krzysztof!
Then I'm fine with this.
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: omap-mcpdm: Convert to DT schema
From: Krzysztof Kozlowski @ 2024-04-05 6:58 UTC (permalink / raw)
To: Mighty
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, alsa-devel, devicetree, linux-kernel
In-Reply-To: <20240404160649.967-1-bavishimithil@gmail.com>
On 04/04/2024 18:06, Mighty wrote:
> From: Mithil Bavishi <bavishimithil@gmail.com>
>
> Convert the OMAP4+ McPDM bindings to DT schema.
>
> Signed-off-by: Mighty <bavishimithil@gmail.com>
This does not match SoB. Can you respond to comments you receive?
Subject: nothing improved.
Rest... also did not improve. so you ignored entire feedback?
This is a friendly reminder during the review process.
It seems my or other reviewer's previous comments were not fully
addressed. Maybe the feedback got lost between the quotes, maybe you
just forgot to apply it. Please go back to the previous discussion and
either implement all requested changes or keep discussing them.
Thank you.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] mfd: rohm-bd71828: Add software-compatible variant BD71879
From: Krzysztof Kozlowski @ 2024-04-05 7:00 UTC (permalink / raw)
To: Andreas Kemnade, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
mazziesaccount, devicetree, linux-kernel
In-Reply-To: <20240404195423.666446-3-andreas@kemnade.info>
On 04/04/2024 21:54, Andreas Kemnade wrote:
> Add the BD71879 PMIC which is software-compatible to the BD71828, so reuse
> the same device_type enum.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
> Acked-by: Matti Vaittinen <mazziesaccount@gmail.com>
> ---
Now you can drop this patch. The benefit of the compatibility is to drop
this code.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: arm64: marvell: add solidrun cn9130 som based boards
From: Krzysztof Kozlowski @ 2024-04-05 7:03 UTC (permalink / raw)
To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rob Herring
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20240404-cn9130-som-v2-1-3af2229c7d2d@solid-run.com>
On 04/04/2024 17:35, Josua Mayer wrote:
> Add bindings for SolidRun boards based on CN9130 SoM.
>
> Three boards are added in total:
> - Clearfog Base
> - Clearfog Pro
> - SolidWAN
> The Clearfog boards are identical to the older Armada 388 based boards,
> upgraded with a new SoM and SoC.
> However the feature set and performance characteristics are different,
> therefore compatible strings from armada 388 versions are not included.
>
> SolidWAN uses the same SoM adding a southbridge on the carrier.
>
> Since 2019 there are bindings in-tree for two boards based on cn9130 and
> 9131. These are extremely verbose by listing cn9132, cn9131, cn9130,
> ap807-quad, ap807 for the SoC alone.
> CN9130 SoC combines an application processor (ap807) and a
> communication processor (cp115) in a single package.
>
> The communication processor (short CP) is also available separately as a
> southbridge. It only functions in combination with the CN9130 SoC.
> Complete systems adding one or two southbridges are by convention called
> CN9131 and CN9132 respectively.
> Despite different naming all systems are built around the same SoC.
> Therefore marvell,cn9131 and marvell,cn9132 can be omitted. The number
> of CPs is part of a board's BoM and can be reflected in the board
> compatible string instead.
>
> Existing bindings also describe cn9130 as a specialisation of
> ap807-quad. Usually board-level compatibles stop at the SoC without
> going into silicon versions or individual dies.
> There is no programming model at this layer, and in particular not for
> parts of an SoC. Therefore the ap compatibles can also be omitted.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: arm64: marvell: add solidrun cn9132 CEX-7 evaluation board
From: Krzysztof Kozlowski @ 2024-04-05 7:04 UTC (permalink / raw)
To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rob Herring
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20240404-cn9130-som-v2-2-3af2229c7d2d@solid-run.com>
On 04/04/2024 17:35, Josua Mayer wrote:
> Add bindings for the SolidRun CN9132 COM-Express Type 7 evaluation board.
> The CEX is based on CN9130 SoC and includes two southbridges.
>
> Because CN9132 and 9131 are just names for different designs around the
> same SoC, there no soc compatibles beside marvell,cn9130 are needed.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 09/17] phy: samsung-ufs: use exynos_get_pmu_regmap_by_phandle() to obtain PMU regmap
From: André Draszik @ 2024-04-05 7:04 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, saravanak,
willmcvicker
In-Reply-To: <20240404122559.898930-10-peter.griffin@linaro.org>
On Thu, 2024-04-04 at 13:25 +0100, Peter Griffin wrote:
> This allows us to obtain a PMU regmap that is created by the exynos-pmu
> driver. Platforms such as gs101 require exynos-pmu created regmap to
> issue SMC calls for PMU register accesses. Existing platforms still get
> a MMIO regmap as before.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
> drivers/phy/samsung/phy-samsung-ufs.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/samsung/phy-samsung-ufs.c b/drivers/phy/samsung/phy-samsung-ufs.c
> index 183c88e3d1ec..c567efafc30f 100644
> --- a/drivers/phy/samsung/phy-samsung-ufs.c
> +++ b/drivers/phy/samsung/phy-samsung-ufs.c
> @@ -18,6 +18,7 @@
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> +#include <linux/soc/samsung/exynos-pmu.h>
You can now drop the include of linux/mfd/syscon.h
Once done, feel free to add
Reviewed-by: André Draszik <andre.draszik@linaro.org>
>
> #include "phy-samsung-ufs.h"
>
> @@ -255,8 +256,8 @@ static int samsung_ufs_phy_probe(struct platform_device *pdev)
> goto out;
> }
>
> - phy->reg_pmu = syscon_regmap_lookup_by_phandle(
> - dev->of_node, "samsung,pmu-syscon");
> + phy->reg_pmu = exynos_get_pmu_regmap_by_phandle(dev->of_node,
> + "samsung,pmu-syscon");
> if (IS_ERR(phy->reg_pmu)) {
> err = PTR_ERR(phy->reg_pmu);
> dev_err(dev, "failed syscon remap for pmu\n");
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: add description for solidrun cn9130 som and clearfog boards
From: Krzysztof Kozlowski @ 2024-04-05 7:05 UTC (permalink / raw)
To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rob Herring
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20240404-cn9130-som-v2-3-3af2229c7d2d@solid-run.com>
On 04/04/2024 17:35, Josua Mayer wrote:
> Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro
> reference boards.
>
> The SoM has been designed as a pin-compatible replacement for the older
> Armada 388 based SoM. Therefore it supports the same boards and a
> similar feature set.
>
> Most notable upgrades:
> - 4x Cortex-A72
> - 10Gbps SFP
> - Both eMMC and SD supported at the same time
>
> The developer first supporting this product at SolidRun decided to use
> different filenames for the DTBs: Armada 388 uses the full
> "clearfog" string while cn9130 uses the abbreviation "cf".
> This name is already hard-coded in pre-installed vendor u-boot and can
> not be changed easily.
>
> NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE:
> CN9130 SoM has a different footprint from Armada 388 SoM.
> Components on the carrier board below the SoM may collide causing
> damage, such as on Clearfog Base.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RESEND PATCH v9 2/4] dt-bindings: stm32: update DT bingding for stm32mp25
From: Krzysztof Kozlowski @ 2024-04-05 7:12 UTC (permalink / raw)
To: gabriel.fernandez, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Philipp Zabel
Cc: linux-clk, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240402125312.277052-3-gabriel.fernandez@foss.st.com>
On 02/04/2024 14:53, gabriel.fernandez@foss.st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
>
> Now RCC driver use '.index' of clk_parent_data struct to define a parent.
> The majority of parents are SCMI clocks, then dt-bindings must be fixed.
>
> Fixes: b5be49db3d47 ("dt-bindings: stm32: add clocks and reset binding for stm32mp25 platform")
And except what Rob said, this does not look as a fix. How ABI break
could be a fix and what is even to fix here? Please describe the
observable bug, how it manifests itself and what is exactly the fix for
that bug.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox