[PATCH 1/9] dt-bindings: gpio: add bindings for the QIXIS FPGA based GPIO controller

Krzysztof Kozlowski krzk at kernel.org
Wed Jul 9 07:11:52 PDT 2025


On 09/07/2025 15:55, Ioana Ciornei wrote:
> On Wed, Jul 09, 2025 at 02:14:47PM +0200, Krzysztof Kozlowski wrote:
>> On 09/07/2025 13:26, Ioana Ciornei wrote:
>>> Add a device tree binding for the QIXIS FPGA based GPIO controller.
>>> Depending on the board, the QIXIS FPGA exposes registers which act as a
>>> GPIO controller, each with 8 GPIO lines of fixed direction.
>>>
>>> Since each QIXIS FPGA layout has its particularities, add a separate
>>> compatible string for each board/GPIO register combination supported.
>>>
>>> Signed-off-by: Ioana Ciornei <ioana.ciornei at nxp.com>
>>
>> Your changelog explains patches, which is kind of redundant - we see
>> that - but does not explain the dependency you have here between patches.
>>
> 
> Do you mean the logical dependency between all the components like
> FPGAs, GPIOs etc? I can expand on that, sure. I will also update the
> cover letter with some of the information below.
> If this is not what you are looking for, please let me know.

I meant here cover letter, not changelog. It does not explain
dependencies between patches. You just explain what each patch is doing
- this is completely redundant cover letter.

> 
> Layerscape boards such as those that I update here have a QIXIS FPGA
> accessible through I2C. This FPGA exposes a set of registers which can
> be used to monitor the status of different components, configure muxing,
> act as GPIO controllers etc.
> 
> Since the register layout that this device exposes is different on a per
> board basis, each board has a different compatible string such as the
> one that patch 2/9 adds - fsl,lx2160ardb-fpga.
> 
> Going deeper, some of these registers are acting as GPIO controllers
> exposing status/control of different SFP cages on the board. For these
> kind of registers the new gpio-regmap driver is added.
> 
>> A nit, subject: drop second/last, redundant "bindings". The
>> "dt-bindings" prefix is already stating that these are bindings.
>> See also:
>> https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>>
> 
> Sure. Will fix.
> 
>>> ---
>>>  .../bindings/gpio/fsl,fpga-gpio.yaml          | 44 +++++++++++++++++++
>>>  1 file changed, 44 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/gpio/fsl,fpga-gpio.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpio/fsl,fpga-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl,fpga-gpio.yaml
>>> new file mode 100644
>>> index 000000000000..dc7b6c0d9b40
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpio/fsl,fpga-gpio.yaml
>>> @@ -0,0 +1,44 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/gpio/fsl,fpga-gpio.yaml
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml
>>> +
>>> +title: GPIO controller embedded in the NXP QIXIS FPGA
>>> +
>>> +maintainers:
>>> +  - Ioana Ciornei <ioana.ciornei at nxp.com>
>>> +
>>> +description: |
>>> +  This module is part of the QIXIS FPGA found on some Layerscape boards such as
>>> +  LX2160ARDB and LS1046AQDS. For more details see
>>> +  ../board/fsl,fpga-qixis-i2c.yaml.
>>
>> There are no "board" bindings, so this does not feel like correct path.
> 
> As you have seen already in patch 2/9 there is already a dt-binding in
> the board/ folder.
> 
>>
>>> +
>>> +  Each controller supports a maximum of 8 GPIO lines and each line has a fixed
>>> +  direction which cannot be changed using a direction register.
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - fsl,lx2160ardb-fpga-gpio-sfp2
>>> +      - fsl,lx2160ardb-fpga-gpio-sfp3
>>
>> What is the difference between these?
> 
> The layout of the registers backing these two GPIO controllers is the
> same but they each expose status/control of different SFP cages.

So same devices? Why do they need separate compatibles?



Best regards,
Krzysztof



More information about the linux-arm-kernel mailing list