Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v6 7/7] misc: pci_endpoint_test: Document a policy about adding pci_device_id
From: Manivannan Sadhasivam @ 2024-04-10 17:54 UTC (permalink / raw)
  To: Yoshihiro Shimoda
  Cc: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
	jingoohan1, marek.vasut+renesas, linux-pci, devicetree,
	linux-renesas-soc, Frank Li
In-Reply-To: <20240410004832.3726922-8-yoshihiro.shimoda.uh@renesas.com>

On Wed, Apr 10, 2024 at 09:48:32AM +0900, Yoshihiro Shimoda wrote:
> To avoid becoming struct pci_device_id pci_endpoint_test_tbl longer
> and longer, document a policy. For example, if PCIe endpoint controller
> can configure vendor id and/or product id, you can reuse one of
> existing entries to test.
> 
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

One comment below. With that addressed,

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

> ---
> Cc: Frank Li <Frank.li@nxp.com>
> ---
>  drivers/misc/pci_endpoint_test.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
> index c38a6083f0a7..3c8a0afad91d 100644
> --- a/drivers/misc/pci_endpoint_test.c
> +++ b/drivers/misc/pci_endpoint_test.c
> @@ -980,6 +980,7 @@ static const struct pci_endpoint_test_data j721e_data = {
>  	.irq_type = IRQ_TYPE_MSI,
>  };
>  
> +/* Don't need to add a new entry if you can use existing entry to test */

'Do not add a new entry if the controller can use existing VID:PID combinations'

- Mani

>  static const struct pci_device_id pci_endpoint_test_tbl[] = {
>  	{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x),
>  	  .driver_data = (kernel_ulong_t)&default_data,
> -- 
> 2.25.1
> 
> 

-- 
மணிவண்ணன் சதாசிவம்

^ permalink raw reply

* Re: [PATCH 3/3] dt-bindings: PCI: host-bridges: switch from deprecated pci-bus.yaml
From: Rob Herring @ 2024-04-10 17:55 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Krzysztof Kozlowski, Conor Dooley, Hector Martin, Sven Peter,
	Alyssa Rosenzweig, Ray Jui, Scott Branden,
	Broadcom internal kernel review list, Jim Quinlan,
	Nicolas Saenz Julienne, Florian Fainelli, Will Deacon,
	Linus Walleij, Srikanth Thokala, Ryder Lee, Jianjun Wang,
	Sergio Paracuellos, Matthias Brugger, AngeloGioacchino Del Regno,
	Daire McNamara, Bjorn Andersson, Konrad Dybcio, Marek Vasut,
	Yoshihiro Shimoda, Shawn Lin, Heiko Stuebner, Jingoo Han,
	Gustavo Pimentel, Manivannan Sadhasivam, Bharat Kumar Gogada,
	Michal Simek, Geert Uytterhoeven, Magnus Damm, Neil Armstrong,
	Mark Kettenis, Tom Joseph, Ahmad Zainie, Jiaxun Yang,
	Kishon Vijay Abraham I, Thippeswamy Havalige, linux-pci,
	devicetree, linux-kernel, asahi, linux-arm-kernel,
	linux-rpi-kernel, linux-mediatek, linux-arm-msm,
	linux-renesas-soc, linux-rockchip
In-Reply-To: <20240407102000.37213-3-krzysztof.kozlowski@linaro.org>

On Sun, Apr 07, 2024 at 12:20:00PM +0200, Krzysztof Kozlowski wrote:
> dtschema package with core schemas deprecated pci-bus.yaml schema in
> favor of pci-host-bridge.yaml.  Update all bindings to use the latter
> one.
> 
> The difference between pci-bus.yaml and pci-host-bridge.yaml is only in
> lack of "reg" property defined by the latter, which should not have any
> effect here, because all these bindings define the "reg".
> 
> The change is therefore quite trivial, except mediatek,mt7621-pcie.yaml
> binding which have children nodes being also host bridges, apparently.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
>  Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml   | 2 +-
>  Documentation/devicetree/bindings/pci/apple,pcie.yaml         | 2 +-
>  Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml    | 2 +-
>  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml      | 2 +-
>  Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml     | 2 +-
>  Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml   | 2 +-
>  Documentation/devicetree/bindings/pci/host-generic-pci.yaml   | 2 +-
>  Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml   | 2 +-
>  Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml | 2 +-
>  Documentation/devicetree/bindings/pci/loongson.yaml           | 2 +-
>  .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml         | 4 ++--
>  Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml | 2 +-
>  .../devicetree/bindings/pci/microchip,pcie-host.yaml          | 2 +-
>  Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml   | 2 +-
>  Documentation/devicetree/bindings/pci/qcom,pcie.yaml          | 2 +-
>  Documentation/devicetree/bindings/pci/rcar-pci-host.yaml      | 2 +-
>  .../devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml        | 2 +-
>  .../devicetree/bindings/pci/rockchip,rk3399-pcie.yaml         | 2 +-
>  Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml       | 2 +-
>  Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml   | 2 +-
>  Documentation/devicetree/bindings/pci/versatile.yaml          | 2 +-
>  Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml  | 2 +-
>  Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml | 2 +-
>  Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml      | 2 +-
>  Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml     | 2 +-
>  25 files changed, 26 insertions(+), 26 deletions(-)

This implicitly bumps the minimum version for dtschema. That's fine, but 
it should be explicit since we set it explicitly.

Rob

^ permalink raw reply

* Re: [PATCH 3/3] dt-bindings: PCI: host-bridges: switch from deprecated pci-bus.yaml
From: Krzysztof Kozlowski @ 2024-04-10 17:58 UTC (permalink / raw)
  To: Rob Herring
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Krzysztof Kozlowski, Conor Dooley, Hector Martin, Sven Peter,
	Alyssa Rosenzweig, Ray Jui, Scott Branden,
	Broadcom internal kernel review list, Jim Quinlan,
	Nicolas Saenz Julienne, Florian Fainelli, Will Deacon,
	Linus Walleij, Srikanth Thokala, Ryder Lee, Jianjun Wang,
	Sergio Paracuellos, Matthias Brugger, AngeloGioacchino Del Regno,
	Daire McNamara, Bjorn Andersson, Konrad Dybcio, Marek Vasut,
	Yoshihiro Shimoda, Shawn Lin, Heiko Stuebner, Jingoo Han,
	Gustavo Pimentel, Manivannan Sadhasivam, Bharat Kumar Gogada,
	Michal Simek, Geert Uytterhoeven, Magnus Damm, Neil Armstrong,
	Mark Kettenis, Tom Joseph, Ahmad Zainie, Jiaxun Yang,
	Kishon Vijay Abraham I, Thippeswamy Havalige, linux-pci,
	devicetree, linux-kernel, asahi, linux-arm-kernel,
	linux-rpi-kernel, linux-mediatek, linux-arm-msm,
	linux-renesas-soc, linux-rockchip
In-Reply-To: <20240410175540.GA802090-robh@kernel.org>

On 10/04/2024 19:55, Rob Herring wrote:
>>  .../devicetree/bindings/pci/rockchip,rk3399-pcie.yaml         | 2 +-
>>  Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml       | 2 +-
>>  Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml   | 2 +-
>>  Documentation/devicetree/bindings/pci/versatile.yaml          | 2 +-
>>  Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml  | 2 +-
>>  Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml | 2 +-
>>  Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml      | 2 +-
>>  Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml     | 2 +-
>>  25 files changed, 26 insertions(+), 26 deletions(-)
> 
> This implicitly bumps the minimum version for dtschema. That's fine, but 
> it should be explicit since we set it explicitly.

Right, I will mention that this requires 2024.02

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH 3/3] dt-bindings: PCI: host-bridges: switch from deprecated pci-bus.yaml
From: Krzysztof Kozlowski @ 2024-04-10 18:00 UTC (permalink / raw)
  To: Rob Herring
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Krzysztof Kozlowski, Conor Dooley, Hector Martin, Sven Peter,
	Alyssa Rosenzweig, Ray Jui, Scott Branden,
	Broadcom internal kernel review list, Jim Quinlan,
	Nicolas Saenz Julienne, Florian Fainelli, Will Deacon,
	Linus Walleij, Srikanth Thokala, Ryder Lee, Jianjun Wang,
	Sergio Paracuellos, Matthias Brugger, AngeloGioacchino Del Regno,
	Daire McNamara, Bjorn Andersson, Konrad Dybcio, Marek Vasut,
	Yoshihiro Shimoda, Shawn Lin, Heiko Stuebner, Jingoo Han,
	Gustavo Pimentel, Manivannan Sadhasivam, Bharat Kumar Gogada,
	Michal Simek, Geert Uytterhoeven, Magnus Damm, Neil Armstrong,
	Mark Kettenis, Tom Joseph, Ahmad Zainie, Jiaxun Yang,
	Kishon Vijay Abraham I, Thippeswamy Havalige, linux-pci,
	devicetree, linux-kernel, asahi, linux-arm-kernel,
	linux-rpi-kernel, linux-mediatek, linux-arm-msm,
	linux-renesas-soc, linux-rockchip
In-Reply-To: <20240410174806.GA788199-robh@kernel.org>

On 10/04/2024 19:48, Rob Herring wrote:
> On Sun, Apr 07, 2024 at 12:20:00PM +0200, Krzysztof Kozlowski wrote:
>> dtschema package with core schemas deprecated pci-bus.yaml schema in
>> favor of pci-host-bridge.yaml.  Update all bindings to use the latter
>> one.
>>
>> The difference between pci-bus.yaml and pci-host-bridge.yaml is only in
>> lack of "reg" property defined by the latter, which should not have any
>> effect here, because all these bindings define the "reg".
>>
>> The change is therefore quite trivial, except mediatek,mt7621-pcie.yaml
>> binding which have children nodes being also host bridges, apparently.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> ---
>>  Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml   | 2 +-
>>  Documentation/devicetree/bindings/pci/apple,pcie.yaml         | 2 +-
>>  Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml    | 2 +-
>>  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml      | 2 +-
>>  Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml     | 2 +-
>>  Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml   | 2 +-
>>  Documentation/devicetree/bindings/pci/host-generic-pci.yaml   | 2 +-
>>  Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml   | 2 +-
>>  Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml | 2 +-
>>  Documentation/devicetree/bindings/pci/loongson.yaml           | 2 +-
>>  .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml         | 4 ++--
>>  Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml | 2 +-
>>  .../devicetree/bindings/pci/microchip,pcie-host.yaml          | 2 +-
>>  Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml   | 2 +-
>>  Documentation/devicetree/bindings/pci/qcom,pcie.yaml          | 2 +-
>>  Documentation/devicetree/bindings/pci/rcar-pci-host.yaml      | 2 +-
>>  .../devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml        | 2 +-
>>  .../devicetree/bindings/pci/rockchip,rk3399-pcie.yaml         | 2 +-
>>  Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml       | 2 +-
>>  Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml   | 2 +-
>>  Documentation/devicetree/bindings/pci/versatile.yaml          | 2 +-
>>  Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml  | 2 +-
>>  Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml | 2 +-
>>  Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml      | 2 +-
>>  Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml     | 2 +-
>>  25 files changed, 26 insertions(+), 26 deletions(-)
> 
> 
>> diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
>> index 61d027239910..5bbb4a3f3dbd 100644
>> --- a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
>> +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
>> @@ -14,7 +14,7 @@ description: |+
>>    with 3 Root Ports. Each Root Port supports a Gen1 1-lane Link
>>  
>>  allOf:
>> -  - $ref: /schemas/pci/pci-bus.yaml#
>> +  - $ref: /schemas/pci/pci-host-bridge.yaml#
>>  
>>  properties:
>>    compatible:
>> @@ -33,7 +33,7 @@ properties:
>>  patternProperties:
>>    '^pcie@[0-2],0$':
>>      type: object
>> -    $ref: /schemas/pci/pci-bus.yaml#
>> +    $ref: /schemas/pci/pci-host-bridge.yaml#
> 
> I think this one should be pci-pci-bridge.yaml instead since it says 
> these are root ports and based on the unit-address here.

I was thinking about this as well, but pci-pci-bridge.yaml defines
compatible which is not present here at all. Since you suggest pci-pci,
I'll go with this and make it a separate patch for easier review.

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH 1/3] dt-bindings: pinctrl: mediatek: mt7622: fix array properties
From: Rob Herring @ 2024-04-10 18:01 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: Hsin-Yi Wang, linux-mediatek, Sean Wang, Krzysztof Kozlowski,
	linux-arm-kernel, Rafał Miłecki, Linus Walleij,
	linux-gpio, devicetree, AngeloGioacchino Del Regno, Conor Dooley,
	Matthias Brugger
In-Reply-To: <20240408090506.21596-1-zajec5@gmail.com>


On Mon, 08 Apr 2024 11:05:04 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> Some properties (function groups & pins) are meant to be arrays and
> should allow multiple entries out of enum sets. Use "items" for those.
> 
> Mistake was noticed during validation of in-kernel DTS files.
> 
> Fixes: b9ffc18c6388 ("dt-bindings: mediatek: convert pinctrl to yaml")
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
>  .../pinctrl/mediatek,mt7622-pinctrl.yaml      | 92 ++++++++++---------
>  1 file changed, 49 insertions(+), 43 deletions(-)
> 

Acked-by: Rob Herring <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH 2/3] dt-bindings: pinctrl: mediatek: mt7622: add "antsel" function
From: Rob Herring @ 2024-04-10 18:02 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: Krzysztof Kozlowski, Linus Walleij, AngeloGioacchino Del Regno,
	Sean Wang, Rafał Miłecki, linux-gpio, linux-arm-kernel,
	Chuanhong Guo, linux-mediatek, devicetree, Matthias Brugger,
	Hsin-Yi Wang, Conor Dooley
In-Reply-To: <20240408090506.21596-2-zajec5@gmail.com>


On Mon, 08 Apr 2024 11:05:05 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> MT7622 pinctrl has ANTSEL* pins. Linux support for those was added in
> the commit 19f599e83ac5 ("pinctrl: mediatek: mt7622: add antsel
> pins/groups"). Include them in binding.
> 
> Cc: Chuanhong Guo <gch981213@gmail.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
>  .../pinctrl/mediatek,mt7622-pinctrl.yaml       | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v8 3/3] input: pm8xxx-vibrator: add new SPMI vibrator support
From: Konrad Dybcio @ 2024-04-10 18:10 UTC (permalink / raw)
  To: quic_fenglinw, kernel, Andy Gross, Bjorn Andersson,
	Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
	Dmitry Baryshkov
  Cc: linux-arm-msm, linux-input, linux-kernel, devicetree
In-Reply-To: <20240401-pm8xxx-vibrator-new-design-v8-3-6f2b8b03b4c7@quicinc.com>



On 4/1/24 10:38, Fenglin Wu via B4 Relay wrote:
> From: Fenglin Wu <quic_fenglinw@quicinc.com>
> 
> Add support for a new SPMI vibrator module which is very similar
> to the vibrator module inside PM8916 but has a finer drive voltage
> step and different output voltage range, its drive level control
> is expanded across 2 registers. The vibrator module can be found
> in following Qualcomm PMICs: PMI632, PM7250B, PM7325B, PM7550BA.
> 
> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> ---

[...]

>   
> -#define VIB_MAX_LEVEL_mV	(3100)
> -#define VIB_MIN_LEVEL_mV	(1200)
> -#define VIB_MAX_LEVELS		(VIB_MAX_LEVEL_mV - VIB_MIN_LEVEL_mV)
> +#define VIB_MAX_LEVEL_mV(vib)	(vib->drv2_addr ? (3544) : (3100))

You shouldn't need the additional inside parentheses

Also, is this really a good discriminator for the voltage ranges? Do *all*
PMIC vibrators with a drv2_addr operate within this range? If not, consider
a struct field here


> +#define VIB_MIN_LEVEL_mV(vib)	(vib->drv2_addr ? (1504) : (1200))
> +#define VIB_MAX_LEVELS(vib)	(VIB_MAX_LEVEL_mV(vib) - VIB_MIN_LEVEL_mV(vib))

If the ranges are supposed to be inclusive, this is off-by-one. But looking
at the driver, it seems like MIN_LEVEL may be "off"? I'm not sure though.

Either way, this would be a separate fix.
[...]

> +static struct pm8xxx_regs pmi632_regs = {
> +	.enable_offset = 0x46,
> +	.enable_mask = BIT(7),
> +	.drv_offset = 0x40,
> +	.drv_mask = 0xFF,

GENMASK(7, 0)

> +	.drv_shift = 0,
> +	.drv2_offset = 0x41,
> +	.drv2_mask = 0x0F,

GENMASK(3, 0)

[...]

>   
> +	if (regs->drv2_mask) {
> +		if (on)
> +			val = (vib->level << regs->drv2_shift) & regs->drv2_mask;
> +		else
> +			val = 0;
> +		rc = regmap_write(vib->regmap, vib->drv2_addr, val);

Are you purposefuly zeroing out the other bits?

If yes, consider regmap_write_bits here
If not, consider regmap_update_bits here

> +		if (rc < 0)
> +			return rc;

Ignore regmap_r/w errors, these mean a complete failure of the API and
we don't generally assume MMIO accesses can fail

Unless SPMI is known to have issues here

> +	}
> +
>   	if (regs->enable_mask)
>   		rc = regmap_update_bits(vib->regmap, vib->enable_addr,
>   					regs->enable_mask, on ? ~0 : 0);
> @@ -114,19 +141,22 @@ static void pm8xxx_work_handler(struct work_struct *work)
>   		return;
>   
>   	/*
> -	 * pmic vibrator supports voltage ranges from 1.2 to 3.1V, so
> +	 * pmic vibrator supports voltage ranges from MIN_LEVEL to MAX_LEVEL, so
>   	 * scale the level to fit into these ranges.
>   	 */
>   	if (vib->speed) {
>   		vib->active = true;
> -		vib->level = ((VIB_MAX_LEVELS * vib->speed) / MAX_FF_SPEED) +
> -						VIB_MIN_LEVEL_mV;
> -		vib->level /= 100;
> +		vib->level = ((VIB_MAX_LEVELS(vib) * vib->speed) / MAX_FF_SPEED) +

mult_frac()

> +						VIB_MIN_LEVEL_mV(vib);

vib->level = VIB_MIN_LEVEL_mV;
vib->level += the other thing

for readability?

>   	} else {
>   		vib->active = false;
> -		vib->level = VIB_MIN_LEVEL_mV / 100;
> +		vib->level = VIB_MIN_LEVEL_mV(vib);
> +
>   	}
>   
> +	if (!vib->drv2_addr)
> +		vib->level /= 100;

Maybe this could be moved to pm8xxx_vib_set() instead

> +
>   	pm8xxx_vib_set(vib, vib->active);
>   }
>   
> @@ -202,7 +232,7 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
>   
>   	vib->enable_addr = reg_base + regs->enable_offset;
>   	vib->drv_addr = reg_base + regs->drv_offset;
> -
> +	vib->drv2_addr = reg_base + regs->drv2_offset;

It would be nice to preserve a newline between assignments and rw
functions here

Thanks for working on this!

Konrad

^ permalink raw reply

* Re: [PATCH 3/3] dt-bindings: PCI: host-bridges: switch from deprecated pci-bus.yaml
From: Rob Herring @ 2024-04-10 18:11 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Krzysztof Kozlowski, Conor Dooley, Hector Martin, Sven Peter,
	Alyssa Rosenzweig, Ray Jui, Scott Branden,
	Broadcom internal kernel review list, Jim Quinlan,
	Nicolas Saenz Julienne, Florian Fainelli, Will Deacon,
	Linus Walleij, Srikanth Thokala, Ryder Lee, Jianjun Wang,
	Sergio Paracuellos, Matthias Brugger, AngeloGioacchino Del Regno,
	Daire McNamara, Bjorn Andersson, Konrad Dybcio, Marek Vasut,
	Yoshihiro Shimoda, Shawn Lin, Heiko Stuebner, Jingoo Han,
	Gustavo Pimentel, Manivannan Sadhasivam, Bharat Kumar Gogada,
	Michal Simek, Geert Uytterhoeven, Magnus Damm, Neil Armstrong,
	Mark Kettenis, Tom Joseph, Ahmad Zainie, Jiaxun Yang,
	Kishon Vijay Abraham I, Thippeswamy Havalige, linux-pci,
	devicetree, linux-kernel, asahi, linux-arm-kernel,
	linux-rpi-kernel, linux-mediatek, linux-arm-msm,
	linux-renesas-soc, linux-rockchip
In-Reply-To: <57827422-1042-4ef6-a11e-cb53fd930a41@linaro.org>

On Wed, Apr 10, 2024 at 1:00 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 10/04/2024 19:48, Rob Herring wrote:
> > On Sun, Apr 07, 2024 at 12:20:00PM +0200, Krzysztof Kozlowski wrote:
> >> dtschema package with core schemas deprecated pci-bus.yaml schema in
> >> favor of pci-host-bridge.yaml.  Update all bindings to use the latter
> >> one.
> >>
> >> The difference between pci-bus.yaml and pci-host-bridge.yaml is only in
> >> lack of "reg" property defined by the latter, which should not have any
> >> effect here, because all these bindings define the "reg".
> >>
> >> The change is therefore quite trivial, except mediatek,mt7621-pcie.yaml
> >> binding which have children nodes being also host bridges, apparently.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >> ---
> >>  Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml   | 2 +-
> >>  Documentation/devicetree/bindings/pci/apple,pcie.yaml         | 2 +-
> >>  Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml    | 2 +-
> >>  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml      | 2 +-
> >>  Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml     | 2 +-
> >>  Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml   | 2 +-
> >>  Documentation/devicetree/bindings/pci/host-generic-pci.yaml   | 2 +-
> >>  Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml   | 2 +-
> >>  Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml | 2 +-
> >>  Documentation/devicetree/bindings/pci/loongson.yaml           | 2 +-
> >>  .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml         | 4 ++--
> >>  Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml | 2 +-
> >>  .../devicetree/bindings/pci/microchip,pcie-host.yaml          | 2 +-
> >>  Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml   | 2 +-
> >>  Documentation/devicetree/bindings/pci/qcom,pcie.yaml          | 2 +-
> >>  Documentation/devicetree/bindings/pci/rcar-pci-host.yaml      | 2 +-
> >>  .../devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml        | 2 +-
> >>  .../devicetree/bindings/pci/rockchip,rk3399-pcie.yaml         | 2 +-
> >>  Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml       | 2 +-
> >>  Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml   | 2 +-
> >>  Documentation/devicetree/bindings/pci/versatile.yaml          | 2 +-
> >>  Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml  | 2 +-
> >>  Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml | 2 +-
> >>  Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml      | 2 +-
> >>  Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml     | 2 +-
> >>  25 files changed, 26 insertions(+), 26 deletions(-)
> >
> >
> >> diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
> >> index 61d027239910..5bbb4a3f3dbd 100644
> >> --- a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
> >> +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
> >> @@ -14,7 +14,7 @@ description: |+
> >>    with 3 Root Ports. Each Root Port supports a Gen1 1-lane Link
> >>
> >>  allOf:
> >> -  - $ref: /schemas/pci/pci-bus.yaml#
> >> +  - $ref: /schemas/pci/pci-host-bridge.yaml#
> >>
> >>  properties:
> >>    compatible:
> >> @@ -33,7 +33,7 @@ properties:
> >>  patternProperties:
> >>    '^pcie@[0-2],0$':
> >>      type: object
> >> -    $ref: /schemas/pci/pci-bus.yaml#
> >> +    $ref: /schemas/pci/pci-host-bridge.yaml#
> >
> > I think this one should be pci-pci-bridge.yaml instead since it says
> > these are root ports and based on the unit-address here.
>
> I was thinking about this as well, but pci-pci-bridge.yaml defines
> compatible which is not present here at all. Since you suggest pci-pci,
> I'll go with this and make it a separate patch for easier review.

This was my concern at first. It does define compatible, but it
doesn't require it. So I think we are fine.

Rob

^ permalink raw reply

* Re: [PATCH 1/3] leds: qcom-lpg: Add support for PMI8950 PWM
From: Konrad Dybcio @ 2024-04-10 18:14 UTC (permalink / raw)
  To: Gianluca Boiano, Pavel Machek, Lee Jones, Bjorn Andersson,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley
  Cc: linux-leds, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20240402-pmi8950-pwm-support-v1-1-1a66899eeeb3@gmail.com>



On 4/2/24 14:35, Gianluca Boiano wrote:
> The PMI8950 PMIC contains 1 PWM channel
> 
> Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>

Oddly enough, there's also 1 LPG channel on the PM(not I)8950 @ 0xbc00

Konrad

^ permalink raw reply

* Re: [PATCH 2/3] arm64: dts: qcom: pmi8950: add pwm node
From: Konrad Dybcio @ 2024-04-10 18:14 UTC (permalink / raw)
  To: Gianluca Boiano, Pavel Machek, Lee Jones, Bjorn Andersson,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley
  Cc: linux-leds, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20240402-pmi8950-pwm-support-v1-2-1a66899eeeb3@gmail.com>



On 4/2/24 14:35, Gianluca Boiano wrote:
> This node is actually found on some msm8953 devices (xiaomi-mido) and
> allows irled enablement
> 
> Signed-off-by: Gianluca Boiano <morf3089@gmail.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>

Konrad

^ permalink raw reply

* [PATCH v2 1/4] dt-bindings: PCI: cdns,cdns-pcie-host: drop redundant msi-parent and pci-bus.yaml
From: Krzysztof Kozlowski @ 2024-04-10 18:15 UTC (permalink / raw)
  To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Hector Martin,
	Sven Peter, Alyssa Rosenzweig, Ray Jui, Scott Branden,
	Broadcom internal kernel review list, Florian Fainelli,
	Jim Quinlan, Nicolas Saenz Julienne, Will Deacon, Linus Walleij,
	Srikanth Thokala, Ryder Lee, Jianjun Wang, Sergio Paracuellos,
	Matthias Brugger, AngeloGioacchino Del Regno, Daire McNamara,
	Bjorn Andersson, Konrad Dybcio, Marek Vasut, Yoshihiro Shimoda,
	Shawn Lin, Heiko Stuebner, Jingoo Han, Gustavo Pimentel,
	Manivannan Sadhasivam, Bharat Kumar Gogada, Michal Simek,
	Geert Uytterhoeven, Magnus Damm, Neil Armstrong, Mark Kettenis,
	Tom Joseph, Ahmad Zainie, Jiaxun Yang, Kishon Vijay Abraham I,
	Thippeswamy Havalige, linux-pci, devicetree, linux-kernel, asahi,
	linux-arm-kernel, linux-rpi-kernel, linux-mediatek, linux-arm-msm,
	linux-renesas-soc, linux-rockchip
  Cc: Krzysztof Kozlowski

The binding reference common cdns-pcie-host.yaml, which already defines
msi-parent and has a reference to pci-bus.yaml schema.  Drop redundant
pieces here to make it a bit smaller.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

---

Changes in v2:
1. Add tags.
---
 Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml
index bc3c48f60fff..a8190d9b100f 100644
--- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml
+++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml
@@ -10,7 +10,6 @@ maintainers:
   - Tom Joseph <tjoseph@cadence.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
   - $ref: cdns-pcie-host.yaml#
 
 properties:
@@ -25,8 +24,6 @@ properties:
       - const: reg
       - const: cfg
 
-  msi-parent: true
-
 required:
   - reg
   - reg-names
-- 
2.34.1


^ permalink raw reply related

* [PATCH v2 2/4] dt-bindings: PCI: mediatek,mt7621: add missing child node reg
From: Krzysztof Kozlowski @ 2024-04-10 18:15 UTC (permalink / raw)
  To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Hector Martin,
	Sven Peter, Alyssa Rosenzweig, Ray Jui, Scott Branden,
	Broadcom internal kernel review list, Florian Fainelli,
	Jim Quinlan, Nicolas Saenz Julienne, Will Deacon, Linus Walleij,
	Srikanth Thokala, Ryder Lee, Jianjun Wang, Sergio Paracuellos,
	Matthias Brugger, AngeloGioacchino Del Regno, Daire McNamara,
	Bjorn Andersson, Konrad Dybcio, Marek Vasut, Yoshihiro Shimoda,
	Shawn Lin, Heiko Stuebner, Jingoo Han, Gustavo Pimentel,
	Manivannan Sadhasivam, Bharat Kumar Gogada, Michal Simek,
	Geert Uytterhoeven, Magnus Damm, Neil Armstrong, Mark Kettenis,
	Tom Joseph, Ahmad Zainie, Jiaxun Yang, Kishon Vijay Abraham I,
	Thippeswamy Havalige, linux-pci, devicetree, linux-kernel, asahi,
	linux-arm-kernel, linux-rpi-kernel, linux-mediatek, linux-arm-msm,
	linux-renesas-soc, linux-rockchip
  Cc: Krzysztof Kozlowski
In-Reply-To: <20240410181521.269431-1-krzysztof.kozlowski@linaro.org>

MT7621 PCI host bridge has children which apparently are also PCI host
bridges, at least that's what the binding suggest.  The children have
"reg" property, but do not explicitly define it.  Instead they rely on
pci-bus.yaml schema, but that one has "reg" without any constraints.

Define the "reg" for the children, so the binding will be more specific
and later will allow dropping reference to deprecated pci-bus.yaml
schema.

Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

---

Changes in v2:
1. Add tags.
---
 .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml          | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
index e63e6458cea8..61d027239910 100644
--- a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
@@ -36,6 +36,9 @@ patternProperties:
     $ref: /schemas/pci/pci-bus.yaml#
 
     properties:
+      reg:
+        maxItems: 1
+
       resets:
         maxItems: 1
 
-- 
2.34.1


^ permalink raw reply related

* [PATCH v2 3/4] dt-bindings: PCI: host-bridges: switch from deprecated pci-bus.yaml
From: Krzysztof Kozlowski @ 2024-04-10 18:15 UTC (permalink / raw)
  To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Hector Martin,
	Sven Peter, Alyssa Rosenzweig, Ray Jui, Scott Branden,
	Broadcom internal kernel review list, Florian Fainelli,
	Jim Quinlan, Nicolas Saenz Julienne, Will Deacon, Linus Walleij,
	Srikanth Thokala, Ryder Lee, Jianjun Wang, Sergio Paracuellos,
	Matthias Brugger, AngeloGioacchino Del Regno, Daire McNamara,
	Bjorn Andersson, Konrad Dybcio, Marek Vasut, Yoshihiro Shimoda,
	Shawn Lin, Heiko Stuebner, Jingoo Han, Gustavo Pimentel,
	Manivannan Sadhasivam, Bharat Kumar Gogada, Michal Simek,
	Geert Uytterhoeven, Magnus Damm, Neil Armstrong, Mark Kettenis,
	Tom Joseph, Ahmad Zainie, Jiaxun Yang, Kishon Vijay Abraham I,
	Thippeswamy Havalige, linux-pci, devicetree, linux-kernel, asahi,
	linux-arm-kernel, linux-rpi-kernel, linux-mediatek, linux-arm-msm,
	linux-renesas-soc, linux-rockchip
  Cc: Krzysztof Kozlowski
In-Reply-To: <20240410181521.269431-1-krzysztof.kozlowski@linaro.org>

dtschema package with core schemas deprecated pci-bus.yaml schema in
favor of pci-host-bridge.yaml.  Update all bindings to use the latter
one.

The difference between pci-bus.yaml and pci-host-bridge.yaml is only in
lack of "reg" property defined by the latter, which should not have any
effect here, because all these bindings define the "reg".

The change is therefore quite trivial, however it requires dtschema
package v2024.02 or newer.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> # Renesas
Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

---

Changes in v2:
1. Add tags.
2. Split mediatek,mt7621-pcie to separate patch as it uses
   pci-pci-bridge schema.
---
 Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml     | 2 +-
 Documentation/devicetree/bindings/pci/apple,pcie.yaml           | 2 +-
 Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml      | 2 +-
 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml        | 2 +-
 Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml       | 2 +-
 Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml     | 2 +-
 Documentation/devicetree/bindings/pci/host-generic-pci.yaml     | 2 +-
 Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml     | 2 +-
 Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml   | 2 +-
 Documentation/devicetree/bindings/pci/loongson.yaml             | 2 +-
 Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml   | 2 +-
 Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml  | 2 +-
 Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml     | 2 +-
 Documentation/devicetree/bindings/pci/qcom,pcie.yaml            | 2 +-
 Documentation/devicetree/bindings/pci/rcar-pci-host.yaml        | 2 +-
 .../devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml          | 2 +-
 Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml | 2 +-
 Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml         | 2 +-
 Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml     | 2 +-
 Documentation/devicetree/bindings/pci/versatile.yaml            | 2 +-
 Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml    | 2 +-
 Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml   | 2 +-
 Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml        | 2 +-
 Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml       | 2 +-
 24 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml b/Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml
index a5bd90bc0712..79a21ba0f9fd 100644
--- a/Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml
@@ -13,7 +13,7 @@ description:
   Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI core.
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - $ref: /schemas/pci/snps,dw-pcie-common.yaml#
 
 # We need a select here so we don't match all nodes with 'snps,dw-pcie'
diff --git a/Documentation/devicetree/bindings/pci/apple,pcie.yaml b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
index 215ff9a9c835..c8775f9cb071 100644
--- a/Documentation/devicetree/bindings/pci/apple,pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
@@ -85,7 +85,7 @@ required:
 unevaluatedProperties: false
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - $ref: /schemas/interrupt-controller/msi-controller.yaml#
   - if:
       properties:
diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml
index 0e07ab61a48d..5434c144d2ec 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml
@@ -11,7 +11,7 @@ maintainers:
   - Scott Branden <scott.branden@broadcom.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 22491f7f8852..11f8ea33240c 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -108,7 +108,7 @@ required:
   - msi-controller
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - $ref: /schemas/interrupt-controller/msi-controller.yaml#
   - if:
       properties:
diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml
index a6b494401ebb..f4eb82e684bd 100644
--- a/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml
+++ b/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Tom Joseph <tjoseph@cadence.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - $ref: cdns-pcie.yaml#
 
 properties:
diff --git a/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml b/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml
index 92efbf0f1297..378dd1c8e2ee 100644
--- a/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml
+++ b/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml
@@ -51,7 +51,7 @@ description: |
         <0x6000 0 0 4 &pci_intc 2>;
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
index d25423aa7167..3484e0b4b412 100644
--- a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
+++ b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
@@ -116,7 +116,7 @@ required:
   - ranges
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - if:
       properties:
         compatible:
diff --git a/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml b/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml
index debfb54a8042..3cae2e0f7f5e 100644
--- a/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml
+++ b/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml
@@ -12,7 +12,7 @@ maintainers:
 description: PCI host controller found in the Intel IXP4xx SoC series.
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml b/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml
index 505acc4f3efc..1fd557504b10 100644
--- a/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml
@@ -11,7 +11,7 @@ maintainers:
   - Srikanth Thokala <srikanth.thokala@intel.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/pci/loongson.yaml b/Documentation/devicetree/bindings/pci/loongson.yaml
index a8324a9bd002..1988465e73a1 100644
--- a/Documentation/devicetree/bindings/pci/loongson.yaml
+++ b/Documentation/devicetree/bindings/pci/loongson.yaml
@@ -13,7 +13,7 @@ description: |+
   PCI host controller found on Loongson PCHs and SoCs.
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
index 7e8c7a2a5f9b..76d742051f73 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
@@ -140,7 +140,7 @@ required:
   - interrupt-controller
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - if:
       properties:
         compatible:
diff --git a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
index f7a3c2636355..a3c4ddc094aa 100644
--- a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
+++ b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Daire McNamara <daire.mcnamara@microchip.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - $ref: /schemas/interrupt-controller/msi-controller.yaml#
 
 properties:
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml
index 0d1b23523f62..0a39bbfcb28b 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml
@@ -95,6 +95,6 @@ anyOf:
       - msi-map
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 additionalProperties: true
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
index cf9a6910b542..f867746b1ae5 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
@@ -130,7 +130,7 @@ anyOf:
       - msi-map
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - if:
       properties:
         compatible:
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
index b6a7cb32f61e..210c3f2bf94c 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
@@ -12,7 +12,7 @@ maintainers:
   - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
 
 allOf:
-  - $ref: pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml b/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml
index 5a0d64d3ae6b..b288cdb1ec70 100644
--- a/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml
+++ b/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml
@@ -110,7 +110,7 @@ required:
   - "#interrupt-cells"
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
   - if:
       properties:
diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml
index 002b728cbc71..720a5f945a4e 100644
--- a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Shawn Lin <shawn.lin@rock-chips.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - $ref: rockchip,rk3399-pcie-common.yaml#
 
 properties:
diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
index 022055edbf9e..548f59d76ef2 100644
--- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
@@ -23,7 +23,7 @@ select:
     - compatible
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - $ref: /schemas/pci/snps,dw-pcie-common.yaml#
   - if:
       not:
diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
index a20dccbafd94..695e491b7b3b 100644
--- a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
@@ -11,7 +11,7 @@ maintainers:
   - Kishon Vijay Abraham I <kishon@ti.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/pci/versatile.yaml b/Documentation/devicetree/bindings/pci/versatile.yaml
index 09748ef6b94f..294c7cd84b37 100644
--- a/Documentation/devicetree/bindings/pci/versatile.yaml
+++ b/Documentation/devicetree/bindings/pci/versatile.yaml
@@ -13,7 +13,7 @@ description: |+
   PCI host controller found on the ARM Versatile PB board's FPGA.
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml
index 4734be456bde..b75ceefa6f93 100644
--- a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml
+++ b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Bharat Kumar Gogada <bharat.kumar.gogada@amd.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml b/Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml
index 69b7decabd45..fb87b960a250 100644
--- a/Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml
+++ b/Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Thippeswamy Havalige <thippeswamy.havalige@amd.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml b/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml
index 426f90a47f35..b0d07c71c1c0 100644
--- a/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Thippeswamy Havalige <thippeswamy.havalige@amd.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
   - $ref: /schemas/interrupt-controller/msi-controller.yaml#
 
 properties:
diff --git a/Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml b/Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml
index 0aa00b8e49b3..2f59b3a73dd2 100644
--- a/Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml
+++ b/Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Thippeswamy Havalige <thippeswamy.havalige@amd.com>
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
-- 
2.34.1


^ permalink raw reply related

* [PATCH v2 4/4] dt-bindings: PCI: mediatek,mt7621-pcie: switch from deprecated pci-bus.yaml
From: Krzysztof Kozlowski @ 2024-04-10 18:15 UTC (permalink / raw)
  To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Hector Martin,
	Sven Peter, Alyssa Rosenzweig, Ray Jui, Scott Branden,
	Broadcom internal kernel review list, Florian Fainelli,
	Jim Quinlan, Nicolas Saenz Julienne, Will Deacon, Linus Walleij,
	Srikanth Thokala, Ryder Lee, Jianjun Wang, Sergio Paracuellos,
	Matthias Brugger, AngeloGioacchino Del Regno, Daire McNamara,
	Bjorn Andersson, Konrad Dybcio, Marek Vasut, Yoshihiro Shimoda,
	Shawn Lin, Heiko Stuebner, Jingoo Han, Gustavo Pimentel,
	Manivannan Sadhasivam, Bharat Kumar Gogada, Michal Simek,
	Geert Uytterhoeven, Magnus Damm, Neil Armstrong, Mark Kettenis,
	Tom Joseph, Ahmad Zainie, Jiaxun Yang, Kishon Vijay Abraham I,
	Thippeswamy Havalige, linux-pci, devicetree, linux-kernel, asahi,
	linux-arm-kernel, linux-rpi-kernel, linux-mediatek, linux-arm-msm,
	linux-renesas-soc, linux-rockchip
  Cc: Krzysztof Kozlowski
In-Reply-To: <20240410181521.269431-1-krzysztof.kozlowski@linaro.org>

dtschema package with core schemas deprecated pci-bus.yaml schema in
favor of individual schemas per host, device and pci-pci.

Switch Mediatek MT7621 PCIe host bridge binding to this new schema.

This requires dtschema package newer than v2024.02 to work fully.
v2024.02 will partially work: with a warning.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

---

Important: v2024.03 (said dtschema newer than v2024.02) was not yet
released, therefore this patch probably should wait a bit. Previous
patches do not depend anyhow on future release, so they can be taken as
is.

Changes in v2:
1. New patch
2. Split mediatek,mt7621-pcie to separate patch as it uses
   pci-pci-bridge schema.
---
 .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml         | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
index 61d027239910..6fba42156db6 100644
--- a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
@@ -14,7 +14,7 @@ description: |+
   with 3 Root Ports. Each Root Port supports a Gen1 1-lane Link
 
 allOf:
-  - $ref: /schemas/pci/pci-bus.yaml#
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
 
 properties:
   compatible:
@@ -33,7 +33,7 @@ properties:
 patternProperties:
   '^pcie@[0-2],0$':
     type: object
-    $ref: /schemas/pci/pci-bus.yaml#
+    $ref: /schemas/pci/pci-pci-bridge.yaml#
 
     properties:
       reg:
-- 
2.34.1


^ permalink raw reply related

* Re: [PATCH v4 2/5] soc: qcom: llcc: Add regmap for Broadcast_AND region
From: Konrad Dybcio @ 2024-04-10 18:24 UTC (permalink / raw)
  To: Unnathi Chalicheemala, Krzysztof Kozlowski, Bjorn Andersson,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Johan Hovold
  Cc: linux-arm-msm, devicetree, linux-kernel, kernel
In-Reply-To: <13ccc36a-c3cc-469a-ae0b-71fd0d24bf63@quicinc.com>



On 4/2/24 21:34, Unnathi Chalicheemala wrote:
> On 3/30/2024 4:46 AM, Krzysztof Kozlowski wrote:
>> On 29/03/2024 22:53, Unnathi Chalicheemala wrote:
>>> Define new regmap structure for Broadcast_AND region and initialize
>>> this regmap when HW block version is greater than 4.1, otherwise
>>> initialize as a NULL pointer for backwards compatibility.
>>>
>>
>>> +	struct regmap *regmap;
>>>   	u32 act_ctrl_reg;
>>>   	u32 act_clear_reg;
>>>   	u32 status_reg;
>>> @@ -849,7 +850,8 @@ static int llcc_update_act_ctrl(u32 sid,
>>>   		return ret;
>>>   
>>>   	if (drv_data->version >= LLCC_VERSION_4_1_0_0) {
>>> -		ret = regmap_read_poll_timeout(drv_data->bcast_regmap, status_reg,
>>> +		regmap = drv_data->bcast_and_regmap ?: drv_data->bcast_regmap;
>>> +		ret = regmap_read_poll_timeout(regmap, status_reg,
>>>   				      slice_status, (slice_status & ACT_COMPLETE),
>>>   				      0, LLCC_STATUS_READ_DELAY);
>>>   		if (ret)
>>> @@ -1284,6 +1286,16 @@ static int qcom_llcc_probe(struct platform_device *pdev)
>>>   
>>>   	drv_data->version = version;
>>>   
>>> +	/* Applicable only when drv_data->version >= 4.1 */
>>> +	drv_data->bcast_and_regmap = qcom_llcc_init_mmio(pdev, i + 1, "llcc_broadcast_and_base");
>>> +	if (IS_ERR(drv_data->bcast_and_regmap)) {
>>
>> I am pretty sure this breaks all users. Can you please explain how do
>> you maintain ABI and that IS_ERR() is applied only for version >= 4.1?
>>
>> Best regards,
>> Krzysztof
>>
> IS_ERR() check is done for all versions.
> If new register isn't defined in DT(for version < 4.1) it simply sets bcast_and_regmap to NULL.
> Otherwise, for version >= 4.1, it goes to err(in the case bcast_and_regmap isn't set properly).

b4 shazam <this series>

booting on 8250, I get:

[    2.794850] qcom-llcc 9200000.system-cache-controller: invalid resource (null)

which comes from lib/devres.c : __devm_ioremap_resource()

Now, this is gonna get you an angry Johan(+CC) response when he sees this land in
the next release. Perhaps, this warning could either be removed from libdevres,
or some sort of an _optional variant that doesn't print it could be introduced.

Konrad

^ permalink raw reply

* Re: [PATCH 1/3] phy: rockchip: emmc: Enable pulldown for strobe line
From: Alban Browaeys @ 2024-04-10 18:28 UTC (permalink / raw)
  To: Conor Dooley
  Cc: dev, Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner,
	Chris Ruehl, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Christopher Obbard, Doug Anderson, Brian Norris, Jensen Huang,
	linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
	devicetree
In-Reply-To: <20240328-unnatural-unsorted-e53a13f5e87e@spud>

Le jeudi 28 mars 2024 à 18:01 +0000, Conor Dooley a écrit :
> On Thu, Mar 28, 2024 at 06:00:03PM +0100, Alban Browaeys wrote:
> > Le mardi 26 mars 2024 à 19:46 +0000, Conor Dooley a écrit :
> > > On Tue, Mar 26, 2024 at 07:54:35PM +0100, Folker Schwesinger via
> > > B4
> > > Relay wrote:
> > > > From: Folker Schwesinger <dev@folker-schwesinger.de>
> > > > -	if (of_property_read_bool(dev->of_node,
> > > > "rockchip,enable-
> > > > strobe-pulldown"))
> > > > -		rk_phy->enable_strobe_pulldown =
> > > > PHYCTRL_REN_STRB_ENABLE;
> > > > +	if (of_property_read_bool(dev->of_node,
> > > > "rockchip,disable-
> > > > strobe-pulldown"))
> > > > +		rk_phy->enable_strobe_pulldown =
> > > > PHYCTRL_REN_STRB_DISABLE;
> > > 
> > > Unfortunately you cannot do this.
> > > Previously no property at all meant disabled and a property was
> > > required
> > > to enable it. With this change the absence of a property means
> > > that
> > > it
> > > will be enabled.
> > > An old devicetree is that wanted this to be disabled would have
> > > no
> > > property and will now end up with it enabled. This is an ABI
> > > break
> > > and is
> > > clearly not backwards compatible, that's a NAK unless it is
> > > demonstrable
> > > that noone actually wants to disable it at all.
> > 
> > 
> > But the patch that introduced the new default to disable the
> > pulldown
> > explicitely introduced a regression for at least 4 boards.
> > It took time to sort out that the default to disable pulldown was
> > the
> > culprit but still.
> > Will we carry this new behavor that breaks the default design for
> > rk3399 because since the regression was introduced new board
> > definition
> > might have expceted this new behavior.
> > 
> > Could the best option be to revert to énot set a default
> > enable/disable
> > pulldown" (as before the commit that introduced the regression) and
> > allow one to force the pulldown via the enable/disable pulldown
> > property?
> > I mean the commit that introduced a default value for the pulldown
> > did
> > not seem to be about fixing anything. But it broke a lot. ANd it
> > was
> > really really hard to find the description of this commit to
> > understand
> > that one had to enable pulldown to restore hs400.
> > 
> > In more than 3 years, only one board maintainer noticed that this
> > property was required to get back HS400  and thanks to a user
> > telling
> > me that this board was working I found from this board that this
> > property was "missing" from most board definitions (while it was
> > not
> > required before).
> > 
> > 
> > I am all for not breaking ABI. But what about not reverting a patch
> > that already broke ABI because this patch introduced a new ABI that
> > we
> > don't want to break?
> > I mean shouldn't a new commit with a new ABI that regressed the
> > kernel
> > be reverted?
> 
> I think I said it after OP replied to me yesterday, but this is a
> pretty
> shitty situation in that the original default picked for the property
> was actually incorrect. Given it's been like this for four years
> before
> anyone noticed, and others probably depend on the current behaviour,
> that's hard to justify.
> 

A lot of people noticed fast that HS400 was broken in the 5.10 branch
but due to another commit (more later, ie double regulator init that
messed up emmc) this second breakage was not detected. But mostly
downstream. And most if not all rk3399 boards in Armbian had HS400
disabled.


It took 3 years to detect that HS400 was broken on a few boards like
Rock Pi4 in the upstream kernel. Any might still be broken.
I would not count on the fact that keeping the current behavior equals
no more broken boards.

From the previous exchanges the boards that requires the pulldown to be
disabled seems well known.

Though I am fine with adding a property to set enable pulldown to any
board definition file where that is required.

Only I do not believe keeping the statu quo equal everything works
because it has been 3 years.
In fact this commit reached the downstream kernels way later. Any
stayed with the 5.10 branch for years.

But on the other side the disable pulldown by default is alraedy in
stable/linux-rolling-lts .



> > Mind fixing the initial regression 8b5c2b45b8f0 "phy: rockchip: set
> > pulldown for strobe line in dts" does not necessarily mean changing
> > the
> > default to the opposite value but could also be reverting to not
> > setting a default.
> 
> That's also problematic, as the only way to do this is make setting
> one of the enabled or disabled properties required, which is also an
> ABI
> break, since you'd then be rejecting probe if one is not present.


I don't understand.
How reverting to not set either pulldown enabled or disabled by default
force all board to set either enabled or disabled.
I was telling about making the pulldown set by kernel optional be it
enabled or disabled to revert to the previous behavior. 

I mean before the patch to set a default pulldown value (to disabled)
there were no forced value.



> > Though I don't know if there are pros to setting a default.
> 
> What you probably have to weigh up is the cons of each side. If what
> you
> lose is HS400 mode with what's in the kernel right now but switching
> to
> what's been proposed would entirely break some boards, I know which
> I think the lesser of two evils is.

More boards (even if not the most wide spread it seems) are broken by
the current behavior.

I agree that only HS400 is broken by keeping the status quo. But as far
as I understand only HS400 will be broken either way.
Be that by keeping the current disable pulldown which break the boards
based on the rockchip default design or the boards that are non-
standard or have a broken design.
Both case this lead to data corruption on boot to eMMC.

The only pro of keeping the current value the default is that most
board broken by the new default introduced in 2020 "might" already be
fixed (but that is just a guess).



> It's probably up to the platform maintainer to weigh in at this
> point.

I am not knowledged into the delegation scope. You mean that from now
on it is up to the rockchip maintainer?
I am fine with it either way.

I just wanted to point out that maybe we don't have to set a pulldown
value after all. And that then all boards will be fine as before
setting the pulldown explicitly was introduced.


In fact I am more eager to get this fixed be it by adding a enable-
pulldown property to the board definitions, than to change the current
behavior.
Just wanted to sort out if that was not the wrong way to fix this
issue. (ie if adding a setting on most boards was wrong).


> Hope that helps?
> Conor.


During more than 2 years, I tried various patches and discussed on
forums about the HS400 breakage. I had bisected the regulator init
issue in the 5.10 branch. Sadly it took so much time for this issue to
be understood that when the force pulldown to disable commit was
introduced downstream before the first issue go fixed.
This only made the matter worse because when one fixed the double
regulator init issue HS400 was still broken, this time because the
pulldown was forced to disable. But nobody noticed this commit that
forced a default pulldown state (that was older than the regulator
commit from 5.13 backported to the 5.10 stable branch commit, but that
reached downstream later due to not having been backported to 5.10 from
5.11).
Otherwise we would have emailed immeditaly.
Bisecting was only able to catch the first breakage (as it was only
fixed after the second breakage was introduced).

Maybe the problem is that me and others did not complained to the
kernel upstream ML because we were using heavily patched downstream
kernels (like most if not all downstream ARM kernels). So sadly, the
forums from back then are filled with complaints but nothing seemed to
have reached the Linux ML.



About the regulator double init, stable downstream branches were hit by
a bug in the 5.10 stable branch in May 2021 before they switched to
5.11 were this default pulldown was introduced. Thus they could not
detect that this pulldown broke HS400 because HS400 was already broken
by a double regulator init, backported in 5.10 from 5.13:
"
commit 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu May 20 01:12:23 2021 +0300

	regulator: core: resolve supply for boot-on/always-on
regulators
   
	commit 98e48cd9283dbac0e1445ee780889f10b3d1db6a upstream.
   
	For the boot-on/always-on regulators the
set_machine_constrainst() is
	called before resolving rdev->supply. Thus the code would try
to enable
	rdev before enabling supplying regulator. Enforce resolving
supply
	regulator before enabling rdev.
   
	Fixes: aea6cb99703e ("regulator: resolve supply after creating
regulator")
	Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
	Link:
https://lore.kernel.org/r/20210519221224.2868496-1-dmitry.baryshkov@linaro.org
	Signed-off-by: Mark Brown <broonie@kernel.org>
	Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
"
and which to my knowledge was only fixed in v6.1-rc1 "
commit 8a866d527ac0441c0eb14a991fa11358b476b11d
Author: Christian Kohlschütter <christian@kohlschutter.com>
Date:   Thu Aug 18 12:46:47 2022 +0000

    regulator: core: Resolve supply name earlier to prevent double-init
    
    Previously, an unresolved regulator supply reference upon calling
    regulator_register on an always-on or boot-on regulator caused
    set_machine_constraints to be called twice.
    
    This in turn may initialize the regulator twice, leading to voltage
    glitches that are timing-dependent. A simple, unrelated
configuration
    change may be enough to hide this problem, only to be surfaced by
    chance.
    
    One such example is the SD-Card voltage regulator in a NanoPI R4S
that
    would not initialize reliably unless the registration flow was just
    complex enough to allow the regulator to properly reset between
calls.
    
    Fix this by re-arranging regulator_register, trying resolve the
    regulator's supply early enough that set_machine_constraints does
not
    need to be called twice.
    
    Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
    Link:
https://lore.kernel.org/r/20220818124646.6005-1-christian@kohlschutter.com
    Signed-off-by: Mark Brown <broonie@kernel.org>

"

So most boards were already broken when the commit to force a pulldown
value was introduced.




Regards
Alban

^ permalink raw reply

* Re: [PATCH] arm64: dts: qcom: sa8155p-adp: use correct gpio for SDHC2 CD
From: Konrad Dybcio @ 2024-04-10 18:33 UTC (permalink / raw)
  To: Volodymyr Babchuk
  Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <20240410134022.732767-1-volodymyr_babchuk@epam.com>



On 4/10/24 15:41, Volodymyr Babchuk wrote:
> Card Detect pin for SHDC2 on SA8155P-ADP is connected to GPIO4 of
> PMM8155AU_1, not to internal TLMM. This change fixes two issues at
> once: not working ethernet (because GPIO4 is used for MAC TX) and SD
> detection.

Oh wow..

Konrad

^ permalink raw reply

* [PATCH net-next 1/1] dt-bindings: ptp: Add device tree binding for IDT FemtoClock
From: Min Li @ 2024-04-10 18:41 UTC (permalink / raw)
  To: richardcochran, robh+dt, krzysztof.kozlowski+dt, conor+dt
  Cc: devicetree, linux-kernel, netdev, Min Li

From: Min Li <min.li.xe@renesas.com>

Add device tree binding doc for the IDT FemtoClock Frequency
Clock Synthesizers.

Signed-off-by: Min Li <min.li.xe@renesas.com>
---
 .../devicetree/bindings/ptp/ptp-idtfc3.yaml   | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml

diff --git a/Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml b/Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml
new file mode 100644
index 000000000000..3e1c3135df5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/ptp-idtfc3.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ptp/ptp-idtfc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RENESAS FemtoClock (TM) Frequency Clock Synthesizers
+
+maintainers:
+  - Min Li <min.li.xe@renesas.com>
+
+properties:
+  compatible:
+    enum:
+      # For System Synchronizer
+      - idt,rc38xxx0
+      - idt,rc38xxx1
+      - idt,rc38xxx2
+      - idt,rc38xxx3
+      - idt,rc38xxx4
+      - idt,rc38xxx5
+      - idt,rc38xxx6
+      - idt,rc38xxx7
+      - idt,rc38xxx8
+      - idt,rc38xxx9
+
+  reg:
+    maxItems: 1
+    description:
+      I2C slave address of the device.
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+	phc@9 { /* FemtoClock3 */
+		compatible = "idt,rc38xxx0";
+		reg = <0x9>;
+	};
+    };
-- 
2.39.2


^ permalink raw reply related

* Re: [PATCH v2 1/1] ASoC: dt-bindings: fsl-esai: Convert fsl,esai.txt to yaml
From: Frank Li @ 2024-04-10 18:43 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Rob Herring, Liam Girdwood, Mark Brown, Krzysztof Kozlowski,
	Conor Dooley, Shengjiu Wang,
	open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	open list, imx
In-Reply-To: <CAOMZO5C=AQOBkOwMBjkgn9TbQ8242Wj0AEHRJ0j_1=N8WfWYRw@mail.gmail.com>

On Tue, Apr 09, 2024 at 04:02:26PM -0300, Fabio Estevam wrote:
> On Tue, Apr 9, 2024 at 3:59 PM Frank Li <Frank.li@nxp.com> wrote:
> 
> > Yes, I run dtb_check for one platform. Which dtb report this warning?
> 
> Try imx_v6_v7_defconfig.

It is because imx6dl.dtsi use a undocumented clock-name 'mem'. According
to driver code,  clock-names 'mem' never be used. but I need double check
with driver owner before send out fix patch.

Frank 

^ permalink raw reply

* Re: [PATCH 01/11] dt-bindings: soc: mobileye: add EyeQ5 OLB system controller
From: Rob Herring @ 2024-04-10 18:52 UTC (permalink / raw)
  To: Théo Lebrun
  Cc: Tawfik Bayouk, Philipp Zabel, Vladimir Kondratiev, linux-gpio,
	Michael Turquette, linux-clk, Gregory CLEMENT, Thomas Petazzoni,
	Krzysztof Kozlowski, Stephen Boyd, Conor Dooley, linux-mips,
	linux-kernel, devicetree, Linus Walleij
In-Reply-To: <20240410-mbly-olb-v1-1-335e496d7be3@bootlin.com>


On Wed, 10 Apr 2024 19:12:30 +0200, Théo Lebrun wrote:
> Add documentation to describe the "Other Logic Block" syscon.
> 
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
>  .../bindings/soc/mobileye/mobileye,eyeq5-olb.yaml  | 125 +++++++++++++++++++++
>  MAINTAINERS                                        |   1 +
>  2 files changed, 126 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.example.dtb: system-controller@d2003000: clock-controller@d2003040:compatible:0: 'mobileye,eyeq5-clk' was expected
	from schema $id: http://devicetree.org/schemas/soc/mobileye/mobileye,eyeq5-olb.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.example.dtb: system-controller@d2003000: clock-controller@d2003040:reg: [[64, 56]] is too short
	from schema $id: http://devicetree.org/schemas/soc/mobileye/mobileye,eyeq5-olb.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.example.dtb: system-controller@d2003000: clock-controller@d2003040: 'reg-names' is a required property
	from schema $id: http://devicetree.org/schemas/soc/mobileye/mobileye,eyeq5-olb.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.example.dtb: system-controller@d2003000: reset-controller@d2003000:compatible:0: 'mobileye,eyeq5-reset' was expected
	from schema $id: http://devicetree.org/schemas/soc/mobileye/mobileye,eyeq5-olb.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.example.dtb: system-controller@d2003000: reset-controller@d2003000:reg: [[0, 60]] is too short
	from schema $id: http://devicetree.org/schemas/soc/mobileye/mobileye,eyeq5-olb.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.example.dtb: system-controller@d2003000: reset-controller@d2003000:#reset-cells:0:0: 2 was expected
	from schema $id: http://devicetree.org/schemas/soc/mobileye/mobileye,eyeq5-olb.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.example.dtb: system-controller@d2003000: reset-controller@d2003000: 'reg-names' is a required property
	from schema $id: http://devicetree.org/schemas/soc/mobileye/mobileye,eyeq5-olb.yaml#
Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.example.dtb: /example-1/soc/system-controller@d2003000/reset-controller@d2003000: failed to match any schema with compatible: ['mobileye,eyeq6h-acc-reset']
Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.example.dtb: /example-1/soc/system-controller@d2003000/clock-controller@d2003040: failed to match any schema with compatible: ['mobileye,eyeq6h-acc-clk']

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240410-mbly-olb-v1-1-335e496d7be3@bootlin.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.


^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: panel-simple-dsi: add New Khadas TS050 panel bindings
From: Rob Herring @ 2024-04-10 18:57 UTC (permalink / raw)
  To: Christian Hewitt
  Cc: Jacobe Zang, Neil Armstrong, Neil Armstrong, David Airlie,
	Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Krzysztof Kozlowski, Conor Dooley,
	quic_jesszhan, sam, nick, thierry.reding, dri-devel, devicetree,
	LKML, AML
In-Reply-To: <3CCAF214-09FE-4580-99CD-AB95E78FFB8F@gmail.com>

On Wed, Apr 10, 2024 at 08:22:25AM +0400, Christian Hewitt wrote:
> > On 9 Apr 2024, at 12:26 PM, Jacobe Zang <jacobe.zang@wesion.com> wrote:
> > 
> > This add the bindings for the New Khadas TS050 1080x1920 5" LCD DSI panel
> > designed to work with the Khadas VIM3 and VIM3L Single Board Computers.
> > 
> > Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com>
> > ---
> > .../devicetree/bindings/display/panel/panel-simple-dsi.yaml     | 2 ++
> > 1 file changed, 2 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> > index f9160d7bac3ca..e194309f31b72 100644
> > --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> > @@ -36,6 +36,8 @@ properties:
> >       - jdi,fhd-r63452
> >         # Khadas TS050 5" 1080x1920 LCD panel
> >       - khadas,ts050
> > +        # Khadas NEW TS050 5" 1080x1920 LCD panel
> > +      - khadas,newts050
> 
> Products are only new until they are old. At some future point there will
> inevitably be a third iteration requiring a ‘new new’ name. IMHO it would
> be better to use something like khadas,ts050v2.

I only see patch 1, so the threading is messed up...

In any case, The commit message should say something about how they are 
different? Is the new one not compatible with the old? That's what this 
change tells me. Otherwise, it should have a fallback. 

Rob

^ permalink raw reply

* Re: [PATCH net-next v2 1/5] dt-bindings: net: renesas,rzn1-gmac: Document RZ/N1 GMAC support
From: Rob Herring @ 2024-04-10 18:58 UTC (permalink / raw)
  To: Romain Gantois
  Cc: Magnus Damm, Alexandre Torgue, Jakub Kicinski, linux-stm32,
	Jose Abreu, Eric Dumazet, Krzysztof Kozlowski, Conor Dooley,
	Thomas Petazzoni, linux-arm-kernel, devicetree,
	Clément Léger, linux-kernel, Geert Uytterhoeven,
	Paolo Abeni, David S. Miller, linux-renesas-soc, Russell King,
	netdev, Maxime Coquelin
In-Reply-To: <20240409-rzn1-gmac1-v2-1-79ca45f2fc79@bootlin.com>


On Tue, 09 Apr 2024 11:21:44 +0200, Romain Gantois wrote:
> From: Clément Léger <clement.leger@bootlin.com>
> 
> The RZ/N1 series of MPUs feature up to two Gigabit Ethernet controllers.
> These controllers are based on Synopsys IPs. They can be connected to
> RZ/N1 RGMII/RMII converters.
> 
> Add a binding that describes these GMAC devices.
> 
> Signed-off-by: "Clément Léger" <clement.leger@bootlin.com>
> [rgantois: commit log]
> Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
> ---
>  .../devicetree/bindings/net/renesas,rzn1-gmac.yaml | 66 ++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
From: Rob Herring @ 2024-04-10 19:03 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno
  Cc: chunkuang.hu, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied,
	daniel, maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
	shawn.sung, yu-chang.lee, ck.hu, jitao.shi, devicetree,
	linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, wenst,
	kernel
In-Reply-To: <20240409120211.321153-2-angelogioacchino.delregno@collabora.com>

On Tue, Apr 09, 2024 at 02:02:09PM +0200, AngeloGioacchino Del Regno wrote:
> The display IPs in MediaTek SoCs support being interconnected with
> different instances of DDP IPs (for example, merge0 or merge1) and/or
> with different DDP IPs (for example, rdma can be connected with either
> color, dpi, dsi, merge, etc), forming a full Display Data Path that
> ends with an actual display.
> 
> The final display pipeline is effectively board specific, as it does
> depend on the display that is attached to it, and eventually on the
> sensors supported by the board (for example, Adaptive Ambient Light
> would need an Ambient Light Sensor, otherwise it's pointless!), other
> than the output type.
> 
> Add support for OF graphs to most of the MediaTek DDP (display) bindings
> to add flexibility to build custom hardware paths, hence enabling board
> specific configuration of the display pipeline and allowing to finally
> migrate away from using hardcoded paths.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  .../display/mediatek/mediatek,aal.yaml        | 40 +++++++++++++++++++
>  .../display/mediatek/mediatek,ccorr.yaml      | 21 ++++++++++
>  .../display/mediatek/mediatek,color.yaml      | 22 ++++++++++
>  .../display/mediatek/mediatek,dither.yaml     | 22 ++++++++++
>  .../display/mediatek/mediatek,dpi.yaml        | 25 +++++++++++-
>  .../display/mediatek/mediatek,dsc.yaml        | 24 +++++++++++
>  .../display/mediatek/mediatek,dsi.yaml        | 27 ++++++++++++-
>  .../display/mediatek/mediatek,ethdr.yaml      | 22 ++++++++++
>  .../display/mediatek/mediatek,gamma.yaml      | 19 +++++++++
>  .../display/mediatek/mediatek,merge.yaml      | 23 +++++++++++
>  .../display/mediatek/mediatek,od.yaml         | 22 ++++++++++
>  .../display/mediatek/mediatek,ovl-2l.yaml     | 22 ++++++++++
>  .../display/mediatek/mediatek,ovl.yaml        | 22 ++++++++++
>  .../display/mediatek/mediatek,postmask.yaml   | 21 ++++++++++
>  .../display/mediatek/mediatek,rdma.yaml       | 22 ++++++++++
>  .../display/mediatek/mediatek,ufoe.yaml       | 21 ++++++++++
>  16 files changed, 372 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> index b4c28e96dd55..623cf7e37fe3 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> @@ -61,6 +61,27 @@ properties:
>      $ref: /schemas/types.yaml#/definitions/phandle-array
>      maxItems: 1
>  
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +    description:
> +      Input and output ports can have multiple endpoints, each of those
> +      connects to either the primary, secondary, etc, display pipeline.
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: AAL input port
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description:
> +          AAL output to the next component's input, for example could be one
> +          of many gamma, overdrive or other blocks.
> +
> +    required:
> +      - port@0
> +      - port@1
> +
>  required:
>    - compatible
>    - reg
> @@ -88,5 +109,24 @@ examples:
>             power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
>             clocks = <&mmsys CLK_MM_DISP_AAL>;
>             mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>;
> +
> +           ports {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               port@0 {
> +                   reg = <0>;
> +                   aal0_in: endpoint {
> +                       remote-endpoint = <&ccorr0_out>;
> +                   };
> +               };
> +
> +               port@1 {
> +                   reg = <1>;
> +                   aal0_out: endpoint {
> +                       remote-endpoint = <&gamma0_in>;
> +                   };
> +               };
> +           };
>         };
>      };
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> index 8c2a737237f2..71ea277a5d8e 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> @@ -54,6 +54,27 @@ properties:
>      $ref: /schemas/types.yaml#/definitions/phandle-array
>      maxItems: 1
>  
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +    description:
> +      Input and output ports can have multiple endpoints, each of those
> +      connects to either the primary, secondary, etc, display pipeline.
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: CCORR input port
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description:
> +          CCORR output to the input of the next desired component in the
> +          display pipeline, usually only one of the available AAL blocks.
> +
> +    required:
> +      - port@0
> +      - port@1
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
> index b886ca0d89ea..61d040a10c08 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
> @@ -64,6 +64,28 @@ properties:
>      $ref: /schemas/types.yaml#/definitions/phandle-array
>      maxItems: 1
>  
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +    description:
> +      Input and output ports can have multiple endpoints, each of those
> +      connects to either the primary, secondary, etc, display pipeline.
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: COLOR input port
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description:
> +          COLOR output to the input of the next desired component in the
> +          display pipeline, for example one of the available CCORR or AAL
> +          blocks.
> +
> +    required:
> +      - port@0
> +      - port@1
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> index 1588b3f7cec7..3d4ab3f86294 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
> @@ -55,6 +55,28 @@ properties:
>      $ref: /schemas/types.yaml#/definitions/phandle-array
>      maxItems: 1
>  
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +    description:
> +      Input and output ports can have multiple endpoints, each of those
> +      connects to either the primary, secondary, etc, display pipeline.
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: DITHER input, usually from a POSTMASK or GAMMA block.
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description:
> +          DITHER output to the input of the next desired component in the
> +          display pipeline, for example one of the available DSC compressors,
> +          DP_INTF, DSI, LVDS or others.
> +
> +    required:
> +      - port@0
> +      - port@1
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> index 803c00f26206..6607cb1c6e0a 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> @@ -64,13 +64,34 @@ properties:
>        Output port node. This port should be connected to the input port of an
>        attached HDMI, LVDS or DisplayPort encoder chip.
>  
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: DPI input port

Strictly speaking, 'port' is equivalent to 'port@0', so it is already 
defined to be the output path. It is a little odd for the input to be 
port@1, but that is why we define the numbering.

Same comment applies to DSI.

Rob

^ permalink raw reply

* [PATCH v4 0/2] Meson: R/W support for pages used by boot ROM
From: Arseniy Krasnov @ 2024-04-10 18:54 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: linux-mtd, devicetree, linux-arm-kernel, linux-amlogic,
	linux-kernel, oxffffaa, kernel, Arseniy Krasnov

Amlogic's boot ROM code needs that some pages on NAND must be written
in special "short" ECC mode with scrambling enabled. Such pages:
1) Contain some metadata about hardware.
2) Located with some interval starting from 0 offset, until some
   specified offset. Interval and second offset are set in the
   device tree.

This patchset adds R/W support for such pages. To enable it we can setup
it in dts:

    nand-is-boot-medium;
    amlogic,boot-page-last = <1024>;
    amlogic,boot-page-step = <128>;

It means that each 128th page in range 0 to 1024 pages will be accessed
in special mode ("short" ECC + scrambling). In practice this feature is
needed when we want to update first block of NAND - driver will enable
required mode by itself using value from device tree.

Changelog:
 v1 -> v2:
  * Rename 'meson,boot-page-XXX' -> 'amlogic,boot-page-XXX'.
  * Add words that 'amlogic,boot-page-step' is measured in pages.
  * Remove words that 'amlogic,boot-page-XXX' depends on 'nand-is-boot-medium'.
  * Make both 'amlogic,boot-page-XXX' depend on each other also, in
    addition to 'nand-is-boot-medium' dependency.
 v2 -> v3:
  * Add quotes to 0001 in dependencies. This fixes 'make dt_binding_check'
    warning.
 v3 -> v4:
  * Rename 'amlogic,boot-page-last' to 'amlogic,boot-pages'.

Arseniy Krasnov (2):
  dt-bindings: mtd: amlogic,meson-nand: support fields for boot ROM code
  mtd: rawnand: meson: support R/W mode for boot ROM

 .../bindings/mtd/amlogic,meson-nand.yaml      | 14 +++
 drivers/mtd/nand/raw/meson_nand.c             | 88 +++++++++++++------
 2 files changed, 73 insertions(+), 29 deletions(-)

-- 
2.35.0


^ permalink raw reply

* [PATCH v4 1/2] dt-bindings: mtd: amlogic,meson-nand: support fields for boot ROM code
From: Arseniy Krasnov @ 2024-04-10 18:54 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
	Kevin Hilman, Jerome Brunet, Martin Blumenstingl
  Cc: linux-mtd, devicetree, linux-arm-kernel, linux-amlogic,
	linux-kernel, oxffffaa, kernel, Arseniy Krasnov
In-Reply-To: <20240410185409.2635622-1-avkrasnov@salutedevices.com>

Boot ROM code on Meson requires that some pages on NAND must be written
in special mode: "short" ECC mode where each block is 384 bytes and
scrambling mode is on. Such pages located with the specified interval
within specified offset. Both interval and offset are located in the
device tree and used by driver if 'nand-is-boot-medium' is set for
NAND chip.

Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
---
 .../bindings/mtd/amlogic,meson-nand.yaml           | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
index 57b6957c8415..838ae1847ef0 100644
--- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
@@ -64,11 +64,25 @@ patternProperties:
         items:
           maximum: 0
 
+      amlogic,boot-pages:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        description:
+          The NFC driver needs this information to select ECC
+          algorithms supported by the boot ROM.
+
+      amlogic,boot-page-step:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        description:
+          The NFC driver needs this information to select ECC
+          algorithms supported by the boot ROM (in pages).
+
     unevaluatedProperties: false
 
     dependencies:
       nand-ecc-strength: [nand-ecc-step-size]
       nand-ecc-step-size: [nand-ecc-strength]
+      amlogic,boot-pages: [nand-is-boot-medium, "amlogic,boot-page-step"]
+      amlogic,boot-page-step: [nand-is-boot-medium, "amlogic,boot-pages"]
 
 
 required:
-- 
2.35.0


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox