dt-bindings: qcom: geni-se: Fix '#address-cells' & '#size-cells' related dt-binding error

  Fix the following '#address-cells' & '#size-cells' related
dt-binding error:

   $ make dtbs_check

   From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
        arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
		#address-cells:0:0: 2 was expected
	From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml

Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
---
 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
  

On 13/01/2023 21:10, Bhupesh Sharma wrote:
> Fix the following '#address-cells' & '#size-cells' related
> dt-binding error:
> 
>    $ make dtbs_check
> 
>    From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>         arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
> 		#address-cells:0:0: 2 was expected
> 	From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml

Don't we want rather to unify the soc address range?

Best regards,
Krzysztof
  

On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 13/01/2023 21:10, Bhupesh Sharma wrote:
> > Fix the following '#address-cells' & '#size-cells' related
> > dt-binding error:
> >
> >    $ make dtbs_check
> >
> >    From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
> >         arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
> >               #address-cells:0:0: 2 was expected
> >       From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>
> Don't we want rather to unify the soc address range?

Well, the assumption in the original dt-bindings was that every reg
variable is 4 * u32 wide (as most new qcom SoCs set #address- and
#size-cells to <2>). However, that is not the case for all of the
SoCs.

So, ideally we shouldn't set the  "#address-cells" and  "#size-cells":
as const: 2 in the bindings.

See as an example:
https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.yaml

Thanks.
  

On 15/01/2023 22:33, Bhupesh Sharma wrote:
> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 13/01/2023 21:10, Bhupesh Sharma wrote:
>>> Fix the following '#address-cells' & '#size-cells' related
>>> dt-binding error:
>>>
>>>    $ make dtbs_check
>>>
>>>    From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>         arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
>>>               #address-cells:0:0: 2 was expected
>>>       From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>
>> Don't we want rather to unify the soc address range?
> 
> Well, the assumption in the original dt-bindings was that every reg
> variable is 4 * u32 wide (as most new qcom SoCs set #address- and
> #size-cells to <2>). However, that is not the case for all of the
> SoCs.

Hm, which device of that SoC cannot be used with address/size cells 2?
> 
> So, ideally we shouldn't set the  "#address-cells" and  "#size-cells":
> as const: 2 in the bindings.
> 
> See as an example:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.yaml


How USB device - so entirely different device, not MMIO! - is related here?

Best regards,
Krzysztof
  

On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 15/01/2023 22:33, Bhupesh Sharma wrote:
> > On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 13/01/2023 21:10, Bhupesh Sharma wrote:
> >>> Fix the following '#address-cells' & '#size-cells' related
> >>> dt-binding error:
> >>>
> >>>    $ make dtbs_check
> >>>
> >>>    From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
> >>>         arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
> >>>               #address-cells:0:0: 2 was expected
> >>>       From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
> >>
> >> Don't we want rather to unify the soc address range?
> >
> > Well, the assumption in the original dt-bindings was that every reg
> > variable is 4 * u32 wide (as most new qcom SoCs set #address- and
> > #size-cells to <2>). However, that is not the case for all of the
> > SoCs.
>
> Hm, which device of that SoC cannot be used with address/size cells 2?

As noted in the git log already the geniqup on sm6115 / sm4250 cannot
be used with address/size cells 2 (See:
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795)

> > So, ideally we shouldn't set the  "#address-cells" and  "#size-cells":
> > as const: 2 in the bindings.
> >
> > See as an example:
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.yaml
>
>
> How USB device - so entirely different device, not MMIO! - is related here?
>
> Best regards,
> Krzysztof
>
  

On 16.01.2023 16:43, Bhupesh Sharma wrote:
> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 15/01/2023 22:33, Bhupesh Sharma wrote:
>>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 13/01/2023 21:10, Bhupesh Sharma wrote:
>>>>> Fix the following '#address-cells' & '#size-cells' related
>>>>> dt-binding error:
>>>>>
>>>>>    $ make dtbs_check
>>>>>
>>>>>    From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>>>         arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
>>>>>               #address-cells:0:0: 2 was expected
>>>>>       From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>>
>>>> Don't we want rather to unify the soc address range?
>>>
>>> Well, the assumption in the original dt-bindings was that every reg
>>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and
>>> #size-cells to <2>). However, that is not the case for all of the
>>> SoCs.
>>
>> Hm, which device of that SoC cannot be used with address/size cells 2?
> 
> As noted in the git log already the geniqup on sm6115 / sm4250 cannot
> be used with address/size cells 2 (See:
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795)
SM6115 (and pretty much every other arm64 msm platform newer than 8916)
should be using addr/size-cells = 2 along with (dma-)ranges of 36 bit, as
that's what their smmus use and otherwise some addresses may get cut off
in translation, or so the story went with 845 N years ago.. We can either
pursue this patch or I can submit the 2-cell-ification if you don't plan on
adding more nodes shortly

Konrad
> 
>>> So, ideally we shouldn't set the  "#address-cells" and  "#size-cells":
>>> as const: 2 in the bindings.
>>>
>>> See as an example:
>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.yaml
>>
>>
>> How USB device - so entirely different device, not MMIO! - is related here?
>>
>> Best regards,
>> Krzysztof
>>
  

On 1/16/23 9:24 PM, Konrad Dybcio wrote:
> 
> 
> On 16.01.2023 16:43, Bhupesh Sharma wrote:
>> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski
>> <krzysztof.kozlowski@linaro.org> wrote:
>>>
>>> On 15/01/2023 22:33, Bhupesh Sharma wrote:
>>>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>>
>>>>> On 13/01/2023 21:10, Bhupesh Sharma wrote:
>>>>>> Fix the following '#address-cells' & '#size-cells' related
>>>>>> dt-binding error:
>>>>>>
>>>>>>     $ make dtbs_check
>>>>>>
>>>>>>     From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>>>>          arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
>>>>>>                #address-cells:0:0: 2 was expected
>>>>>>        From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>>>
>>>>> Don't we want rather to unify the soc address range?
>>>>
>>>> Well, the assumption in the original dt-bindings was that every reg
>>>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and
>>>> #size-cells to <2>). However, that is not the case for all of the
>>>> SoCs.
>>>
>>> Hm, which device of that SoC cannot be used with address/size cells 2?
>>
>> As noted in the git log already the geniqup on sm6115 / sm4250 cannot
>> be used with address/size cells 2 (See:
>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795)
> SM6115 (and pretty much every other arm64 msm platform newer than 8916)
> should be using addr/size-cells = 2 along with (dma-)ranges of 36 bit, as
> that's what their smmus use and otherwise some addresses may get cut off
> in translation, or so the story went with 845 N years ago.. We can either
> pursue this patch or I can submit the 2-cell-ification if you don't plan on
> adding more nodes shortly


Have you tested this combination on SM6115 like SoCs with various IPs? I 
have tried a few experiments in the past and not all IPs work well with 
36-bit DMA ranges (atleast not on the boards I have).

So, I think it might lead to more breakage (unless we are sure of a 
well-tested fix). A simpler patch to fix the dt-bindings looks more 
useful IMO.

Thanks,
Bhupesh
  

On 16.01.2023 17:02, Bhupesh Sharma wrote:
> 
> On 1/16/23 9:24 PM, Konrad Dybcio wrote:
>>
>>
>> On 16.01.2023 16:43, Bhupesh Sharma wrote:
>>> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 15/01/2023 22:33, Bhupesh Sharma wrote:
>>>>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
>>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>>>
>>>>>> On 13/01/2023 21:10, Bhupesh Sharma wrote:
>>>>>>> Fix the following '#address-cells' & '#size-cells' related
>>>>>>> dt-binding error:
>>>>>>>
>>>>>>>     $ make dtbs_check
>>>>>>>
>>>>>>>     From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>>>>>          arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
>>>>>>>                #address-cells:0:0: 2 was expected
>>>>>>>        From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>>>>
>>>>>> Don't we want rather to unify the soc address range?
>>>>>
>>>>> Well, the assumption in the original dt-bindings was that every reg
>>>>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and
>>>>> #size-cells to <2>). However, that is not the case for all of the
>>>>> SoCs.
>>>>
>>>> Hm, which device of that SoC cannot be used with address/size cells 2?
>>>
>>> As noted in the git log already the geniqup on sm6115 / sm4250 cannot
>>> be used with address/size cells 2 (See:
>>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795)
>> SM6115 (and pretty much every other arm64 msm platform newer than 8916)
>> should be using addr/size-cells = 2 along with (dma-)ranges of 36 bit, as
>> that's what their smmus use and otherwise some addresses may get cut off
>> in translation, or so the story went with 845 N years ago.. We can either
>> pursue this patch or I can submit the 2-cell-ification if you don't plan on
>> adding more nodes shortly
> 
> 
> Have you tested this combination on SM6115 like SoCs with various IPs? I have tried a few experiments in the past and not all IPs work well with 36-bit DMA ranges (atleast not on the boards I have).
Can you list any specific examples? I've been using it for
quite some time now and I see nothing wrong..

> 
> So, I think it might lead to more breakage (unless we are sure of a well-tested fix). A simpler patch to fix the dt-bindings looks more useful IMO.
I'm not saying no, you just have to convince Krzysztof :D

Konrad

> 
> Thanks,
> Bhupesh
  

On 1/16/23 9:35 PM, Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
> 
> 
> On 16.01.2023 17:02, Bhupesh Sharma wrote:
> >
> > On 1/16/23 9:24 PM, Konrad Dybcio wrote:
> >>
> >>
> >> On 16.01.2023 16:43, Bhupesh Sharma wrote:
> >>> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>
> >>>> On 15/01/2023 22:33, Bhupesh Sharma wrote:
> >>>>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
> >>>>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>>>
> >>>>>> On 13/01/2023 21:10, Bhupesh Sharma wrote:
> >>>>>>> Fix the following '#address-cells' & '#size-cells' related
> >>>>>>> dt-binding error:
> >>>>>>>
> >>>>>>>      $ make dtbs_check
> >>>>>>>
> >>>>>>>      From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
> >>>>>>>           arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
> >>>>>>>                 #address-cells:0:0: 2 was expected
> >>>>>>>         From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
> >>>>>>
> >>>>>> Don't we want rather to unify the soc address range?
> >>>>>
> >>>>> Well, the assumption in the original dt-bindings was that every reg
> >>>>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and
> >>>>> #size-cells to <2>). However, that is not the case for all of the
> >>>>> SoCs.
> >>>>
> >>>> Hm, which device of that SoC cannot be used with address/size cells 2?
> >>>
> >>> As noted in the git log already the geniqup on sm6115 / sm4250 cannot
> >>> be used with address/size cells 2 (See:
> >>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795)
> >> SM6115 (and pretty much every other arm64 msm platform newer than 8916)
> >> should be using addr/size-cells = 2 along with (dma-)ranges of 36 bit, as
> >> that's what their smmus use and otherwise some addresses may get cut off
> >> in translation, or so the story went with 845 N years ago.. We can either
> >> pursue this patch or I can submit the 2-cell-ification if you don't plan on
> >> adding more nodes shortly
> >
> >
> > Have you tested this combination on SM6115 like SoCs with various IPs? I have tried a few experiments in the past and not all IPs work well with 36-bit DMA ranges (atleast not on the boards I have).
> Can you list any specific examples? I've been using it for
> quite some time now and I see nothing wrong..

I remember seeing some issues with SDHC controller booting (uSD card use case) with sm6115, but I cannot find the appropriate dmesg right now.

> >
> > So, I think it might lead to more breakage (unless we are sure of a well-tested fix). A simpler patch to fix the dt-bindings looks more useful IMO.
> I'm not saying no, you just have to convince Krzysztof :D

:)

Thanks,
Bhupesh
  

On 16.01.2023 17:18, bhupesh.sharma@linaro.org wrote:
> 
> On 1/16/23 9:35 PM, Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>>
>>
>> On 16.01.2023 17:02, Bhupesh Sharma wrote:
>> >
>> > On 1/16/23 9:24 PM, Konrad Dybcio wrote:
>> >>
>> >>
>> >> On 16.01.2023 16:43, Bhupesh Sharma wrote:
>> >>> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski
>> >>> <krzysztof.kozlowski@linaro.org> wrote:
>> >>>>
>> >>>> On 15/01/2023 22:33, Bhupesh Sharma wrote:
>> >>>>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
>> >>>>> <krzysztof.kozlowski@linaro.org> wrote:
>> >>>>>>
>> >>>>>> On 13/01/2023 21:10, Bhupesh Sharma wrote:
>> >>>>>>> Fix the following '#address-cells' & '#size-cells' related
>> >>>>>>> dt-binding error:
>> >>>>>>>
>> >>>>>>>      $ make dtbs_check
>> >>>>>>>
>> >>>>>>>      From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>> >>>>>>>           arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
>> >>>>>>>                 #address-cells:0:0: 2 was expected
>> >>>>>>>         From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>> >>>>>>
>> >>>>>> Don't we want rather to unify the soc address range?
>> >>>>>
>> >>>>> Well, the assumption in the original dt-bindings was that every reg
>> >>>>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and
>> >>>>> #size-cells to <2>). However, that is not the case for all of the
>> >>>>> SoCs.
>> >>>>
>> >>>> Hm, which device of that SoC cannot be used with address/size cells 2?
>> >>>
>> >>> As noted in the git log already the geniqup on sm6115 / sm4250 cannot
>> >>> be used with address/size cells 2 (See:
>> >>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795)
>> >> SM6115 (and pretty much every other arm64 msm platform newer than 8916)
>> >> should be using addr/size-cells = 2 along with (dma-)ranges of 36 bit, as
>> >> that's what their smmus use and otherwise some addresses may get cut off
>> >> in translation, or so the story went with 845 N years ago.. We can either
>> >> pursue this patch or I can submit the 2-cell-ification if you don't plan on
>> >> adding more nodes shortly
>> >
>> >
>> > Have you tested this combination on SM6115 like SoCs with various IPs? I have tried a few experiments in the past and not all IPs work well with 36-bit DMA ranges (atleast not on the boards I have).
>> Can you list any specific examples? I've been using it for
>> quite some time now and I see nothing wrong..
> 
> I remember seeing some issues with SDHC controller booting (uSD card use case) with sm6115, but I cannot find the appropriate dmesg right now.
FWIW it works completely fine for me, in fact I'm booting from
uSD most of the time.

Konrad
> 
>> >
>> > So, I think it might lead to more breakage (unless we are sure of a well-tested fix). A simpler patch to fix the dt-bindings looks more useful IMO.
>> I'm not saying no, you just have to convince Krzysztof :D
> 
> :)
> 
> Thanks,
> Bhupesh
  

On 16/01/2023 16:43, Bhupesh Sharma wrote:
> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 15/01/2023 22:33, Bhupesh Sharma wrote:
>>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 13/01/2023 21:10, Bhupesh Sharma wrote:
>>>>> Fix the following '#address-cells' & '#size-cells' related
>>>>> dt-binding error:
>>>>>
>>>>>    $ make dtbs_check
>>>>>
>>>>>    From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>>>         arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
>>>>>               #address-cells:0:0: 2 was expected
>>>>>       From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>>
>>>> Don't we want rather to unify the soc address range?
>>>
>>> Well, the assumption in the original dt-bindings was that every reg
>>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and
>>> #size-cells to <2>). However, that is not the case for all of the
>>> SoCs.
>>
>> Hm, which device of that SoC cannot be used with address/size cells 2?
> 
> As noted in the git log already the geniqup on sm6115 / sm4250 cannot
> be used with address/size cells 2 (See:
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795)

That's not relevant and not answering to my question. Address/size cells
affect children, so not geniqup. address-cells 2 means you have
everywhere 64 bit addresses, so which devices cannot work with such DTS?
If you claim that geniqup and its children has some troubles - please
point what troubles. The DTS and existing address/size cells have
nothing to do with it.

Best regards,
Krzysztof
  

On Mon, Jan 16, 2023 at 08:10:40PM +0100, Krzysztof Kozlowski wrote:
> On 16/01/2023 16:43, Bhupesh Sharma wrote:
> > On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 15/01/2023 22:33, Bhupesh Sharma wrote:
> >>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>
> >>>> On 13/01/2023 21:10, Bhupesh Sharma wrote:
> >>>>> Fix the following '#address-cells' & '#size-cells' related
> >>>>> dt-binding error:
> >>>>>
> >>>>>    $ make dtbs_check
> >>>>>
> >>>>>    From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
> >>>>>         arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
> >>>>>               #address-cells:0:0: 2 was expected
> >>>>>       From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
> >>>>
> >>>> Don't we want rather to unify the soc address range?
> >>>
> >>> Well, the assumption in the original dt-bindings was that every reg
> >>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and
> >>> #size-cells to <2>). However, that is not the case for all of the
> >>> SoCs.
> >>
> >> Hm, which device of that SoC cannot be used with address/size cells 2?

If 1 cell does the job, then it should be allowed. I'd go a step farther 
and say # of cells should only be as big as needed and that's the 
address size of the children.

> > 
> > As noted in the git log already the geniqup on sm6115 / sm4250 cannot
> > be used with address/size cells 2 (See:
> > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795)

Why can't they use 2? Is it because you forgot 'dma-ranges' and you want 
to implicitly limit DMA to 32-bits?

Unfortunately 'dma-ranges' is frequently omitted so we treat missing as 
1:1 dma-ranges (i.e. empty).

> 
> That's not relevant and not answering to my question. Address/size cells
> affect children, so not geniqup. address-cells 2 means you have
> everywhere 64 bit addresses, so which devices cannot work with such DTS?
> If you claim that geniqup and its children has some troubles - please
> point what troubles. The DTS and existing address/size cells have
> nothing to do with it.
> 
> Best regards,
> Krzysztof
>
  

On Mon, Jan 16, 2023 at 09:13:12PM +0530, Bhupesh Sharma wrote:
> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 15/01/2023 22:33, Bhupesh Sharma wrote:
> > > On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
> > > <krzysztof.kozlowski@linaro.org> wrote:
> > >>
> > >> On 13/01/2023 21:10, Bhupesh Sharma wrote:
> > >>> Fix the following '#address-cells' & '#size-cells' related
> > >>> dt-binding error:
> > >>>
> > >>>    $ make dtbs_check
> > >>>
> > >>>    From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
> > >>>         arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
> > >>>               #address-cells:0:0: 2 was expected
> > >>>       From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
> > >>
> > >> Don't we want rather to unify the soc address range?
> > >
> > > Well, the assumption in the original dt-bindings was that every reg
> > > variable is 4 * u32 wide (as most new qcom SoCs set #address- and
> > > #size-cells to <2>). However, that is not the case for all of the
> > > SoCs.
> >
> > Hm, which device of that SoC cannot be used with address/size cells 2?
> 
> As noted in the git log already the geniqup on sm6115 / sm4250 cannot
> be used with address/size cells 2 (See:
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795)
> 

I'm not able to find the reasoning you're referring to. We do have cells
of 2 for these nodes on all other platforms.  If there is a specific
problem, that can be documented and you can probably use ranges to
reduce keep the cells of 1 in the geni wrappers.


The reason why we have cells = 2 on most platforms is because the SMMU
reports that it's capable of more address bits than the buses will
handle. So without cells = 2, we can't describe dma-ranges appropriately
and you get page faults due to truncated addresses on the bus when the
iommu iova has been picking addresses for you.

Regards,
Bjorn

> > > So, ideally we shouldn't set the  "#address-cells" and  "#size-cells":
> > > as const: 2 in the bindings.
> > >
> > > See as an example:
> > > https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.yaml
> >
> >
> > How USB device - so entirely different device, not MMIO! - is related here?
> >
> > Best regards,
> > Krzysztof
> >
  

Hi Bjorn,

On 1/19/23 8:53 AM, Bjorn Andersson wrote:
> On Mon, Jan 16, 2023 at 09:13:12PM +0530, Bhupesh Sharma wrote:
>> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski
>> <krzysztof.kozlowski@linaro.org> wrote:
>>>
>>> On 15/01/2023 22:33, Bhupesh Sharma wrote:
>>>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski
>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>>
>>>>> On 13/01/2023 21:10, Bhupesh Sharma wrote:
>>>>>> Fix the following '#address-cells' & '#size-cells' related
>>>>>> dt-binding error:
>>>>>>
>>>>>>     $ make dtbs_check
>>>>>>
>>>>>>     From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>>>>          arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000:
>>>>>>                #address-cells:0:0: 2 was expected
>>>>>>        From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
>>>>>
>>>>> Don't we want rather to unify the soc address range?
>>>>
>>>> Well, the assumption in the original dt-bindings was that every reg
>>>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and
>>>> #size-cells to <2>). However, that is not the case for all of the
>>>> SoCs.
>>>
>>> Hm, which device of that SoC cannot be used with address/size cells 2?
>>
>> As noted in the git log already the geniqup on sm6115 / sm4250 cannot
>> be used with address/size cells 2 (See:
>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795)
>>
> 
> I'm not able to find the reasoning you're referring to. We do have cells
> of 2 for these nodes on all other platforms.  If there is a specific
> problem, that can be documented and you can probably use ranges to
> reduce keep the cells of 1 in the geni wrappers.
> 
> 
> The reason why we have cells = 2 on most platforms is because the SMMU
> reports that it's capable of more address bits than the buses will
> handle. So without cells = 2, we can't describe dma-ranges appropriately
> and you get page faults due to truncated addresses on the bus when the
> iommu iova has been picking addresses for you.

Consolidating the replies to your, Krzysztof's and Rob's observations / 
suggestions here..

Yes, the original background to the problem was that I observed that for
the sm6115 based Qualcomm board with me, if I was using 36-bit DMA 
configuration with a few IP blocks (like SDHC), I was seeing some issues.

But, Konrad observed in [1] that it works fine for me on the sm6115 
based Lenovo tab, so I agree to his suggestions and may be he can help
send the '2-cell-ification' patch he has working, in which case I think
we can drop this patch.

@Konrad, please feel free to share the patch you were mentioning and I 
can help test it as well.

[1]. 
https://lore.kernel.org/linux-arm-msm/09fe3e93-328b-13a3-540b-4ca47224b176@linaro.org/

Thanks,
Bhupesh