linux-kernel - Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <77c29d8c-34b3-f508-26bf-22520ccc1f2a@linaro.org>
Date:   Tue, 13 Dec 2022 14:02:10 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Brian Masney <bmasney@...hat.com>,
        Shazad Hussain <quic_shazhuss@...cinc.com>,
        Mark Brown <broonie@...nel.org>
Cc:     andersson@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        konrad.dybcio@...aro.org, robh+dt@...nel.org,
        johan+linaro@...nel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        ahalaney@...hat.com, echanude@...hat.com,
        linux-spi@...r.kernel.org,
        Javier Martinez Canillas <fmartine@...hat.com>
Subject: Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes

On 13/12/2022 13:27, Brian Masney wrote:
> + Mark Brown and linux-spi list
> 
> On Tue, Dec 13, 2022 at 12:46:18PM +0530, Shazad Hussain wrote:
>> On 12/12/2022 11:53 PM, Brian Masney wrote:
>>> Add the missing nodes for the spi buses that's present on this SoC.
>>>
>>> This work was derived from various patches that Qualcomm delivered
>>> to Red Hat in a downstream kernel.
>>>
>>> Signed-off-by: Brian Masney <bmasney@...hat.com>
>>> ---
>>>   arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 384 +++++++++++++++++++++++++
>>>   1 file changed, 384 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> index 392a1509f0be..b50db09feae2 100644
>>> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> @@ -829,6 +829,22 @@ qup2_i2c16: i2c@...000 {
>>>   				status = "disabled";
>>>   			};
>>> +			qup2_spi16: spi@...000 {
>>> +				compatible = "qcom,geni-spi";
>>> +				reg = <0 0x00880000 0 0x4000>;
>>> +				clocks = <&gcc GCC_QUPV3_WRAP2_S0_CLK>;
>>> +				clock-names = "se";
>>> +				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
>>> +				#address-cells = <1>;
>>> +				#size-cells = <0>;
>>> +				interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
>>> +				                <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
>>> +				                <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
>>> +				interconnect-names = "qup-core", "qup-config", "qup-memory";
>>> +				spi-max-frequency = <50000000>;
>>
>> This is device property not host and same applicable for all below spi
>> nodes.
>> Also FYI let's enable below SPI for Qdrive usecases once spidev compatible
>> name is confirmed.
>> SE9  0x00A84000
>> SE22 0x00898000
> 
> I talked to Javier Martinez Canillas yesterday about the spidev driver
> and I think I now have a better understanding of what we need to do.
> Quick background for Mark. For this automotive program, Qualcomm will be
> delivering to Red Hat and our customers parts of the media stack in
> userspace. This will be closed source, proprietary code that parts of it
> will need to interface with SPI.
> 
> We can't add a generic qcom,spidev compatible to the spidev driver since
> this is just a software abstraction. Instead, each type of device will
> need to have it's own compatible that uniquely describes the type of
> device. So you might have a compatible like qcom,spi-video-codec. There
> will need to be a DT binding added that describes the hardware. I suspect
> that a SPI device can simply be added to trivial-devices.yaml. Once the
> DT binding is accepted, the compatible can be added to the spidev.c
> driver. If an in-kernel driver is written in the future, then the 
> compatible can be moved from spidev to the new driver.
> 
> Mark: Is my understanding above correct? If so, will it be a problem to
> get a compatible added to spidev.c if the corresponding userspace code is
> closed source and proprietary?

qcom,spi-video-codec is still not specific enough. You need to describe
real device behind spidev. To be clear - you do not describe userspace,
but the device.

Best regards,
Krzysztof