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] [day] [month] [year] [list]
Message-ID: <76ce7d78-5870-41c5-9114-9d230caeb2d0@oss.nxp.com>
Date: Fri, 26 Sep 2025 12:46:46 +0300
From: Larisa Ileana Grigore <larisa.grigore@....nxp.com>
To: James Clark <james.clark@...aro.org>, Frank Li <Frank.li@....com>,
 Larisa Grigore <larisa.grigore@....com>
Cc: Mark Brown <broonie@...nel.org>, Clark Wang <xiaoning.wang@....com>,
 Fugang Duan <B38611@...escale.com>, Gao Pan <pandy.gao@....com>,
 Fugang Duan <fugang.duan@....com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
 Sascha Hauer <s.hauer@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
 Ghennadi Procopciuc <ghennadi.procopciuc@....com>,
 Ciprianmarian Costea <ciprianmarian.costea@....com>, s32@....com,
 linux-spi@...r.kernel.org, imx@...ts.linux.dev,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 12/13] dt-bindings: lpspi: Document nxp,lpspi-pincfg
 property

On 8/19/2025 12:52 PM, James Clark wrote:
> 
> 
> On 18/08/2025 4:39 pm, Frank Li wrote:
>> On Mon, Aug 18, 2025 at 03:47:45PM +0100, James Clark wrote:
>>>
>>>
>>> On 14/08/2025 7:19 pm, Frank Li wrote:
>>>> On Thu, Aug 14, 2025 at 05:06:52PM +0100, James Clark wrote:
>>>>> Document the two valid pincfg values and the defaults.
>>>>>
>>>>> Although the hardware supports two more values for half-duplex modes,
>>>>> the driver doesn't support them so don't document them.
>>>>
>>>> binding doc should be first patch before drivers.
>>>>
>>>> binding descript hardware not driver, you should add all regardless if
>>>> driver support it.
>>>>
>>>
>>> Replied to same on "[PATCH 10/13] spi: spi-fsl-lpspi: Add compatible for
>>> S32G"
>>>
>>>>>
>>>>> Signed-off-by: James Clark <james.clark@...aro.org>
>>>>> ---
>>>>>    Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml | 14 ++ 
>>>>> ++++++++++++
>>>>>    1 file changed, 14 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl- 
>>>>> lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
>>>>> index ce7bd44ee17e..3f8833911807 100644
>>>>> --- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
>>>>> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
>>>>> @@ -70,6 +70,19 @@ properties:
>>>>>      power-domains:
>>>>>        maxItems: 1
>>>>>
>>>>> +  nxp,pincfg:
>>>>> +    description:
>>>>> +      'Pin configuration value for CFGR1.PINCFG.
>>>>> +        - "sin-in-sout-out": SIN is used for input data and SOUT 
>>>>> is used for
>>>>> +                             output data
>>>>> +        - "sout-in-sin-out": SOUT is used for input data and SIN 
>>>>> is used for
>>>>> +                             output data
>>>>> +      If no value is specified then the default is "sin-in-sout- 
>>>>> out" for host
>>>>> +      mode and "sout-in-sin-out" for target mode.'
>>>>
>>>> why need this? are there varible at difference boards? look like 
>>>> default
>>>> is more make sense.
>>>>
>>>
>>> + Larissa. I think this might also be a question for the hardware 
>>> designers
>>> about why the feature to swap the pins was deemed worth including.
>>>
>>> I'm assuming the flexibility is given for routing reasons. If you have
>>> another device with the pins in one order then you can route it 
>>> without a
>>> via if they happen to be in the same order.
>>
>> DT team need reason to judge if a new property is reasonable/ 
>> neccesary. You
>> need  mention the reason why need this property. Here, some board design
>> swap sin/sout.
>>
> 
> Let's wait for Larisa to reply. If there's no board and it was only for 
> testing maybe we can drop it.
> 
Hello James,

There was no board. You can drop it.

Regards,
Larisa


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ